0

I wondering how to serve login page in secured way. By some reasons I can't serve all page by https, so I want to do something like that: My page url is http://www.example.com, but login and register subdomain is https://ssl.example.com

Of course I have ssl certificate, I only don't know how to make this login mechanism.

Example page which work in that way is ebay.com, check out url in homepage and login page.

kubut
  • 315
  • 5
  • 16
  • 1
    Why are you unable to serve all pages over https? If you have a certificate for the main domain it should work just fine. – Crecket Oct 05 '15 at 09:47
  • I suppose he cannot serve all pages with HTTPS because his ads dont work anymore in this case ^^. This is a problem... but noone likes to tell his guests about this. – Nibbels Oct 05 '15 at 09:55
  • Check answers to [this](http://stackoverflow.com/questions/5106313/redirecting-from-http-to-https-with-php) question. Also you could do it in your webserver config. For example in [.htaccess if you use Apache](http://stackoverflow.com/questions/16152914/redirect-single-page-http-to-https). – Alexander Obersht Oct 05 '15 at 10:06

2 Answers2

3

Your question has already been answered here.

HTTPS is absolutely vital in maintaining a secure connection between a website and a browser. Public wifi networks put users at risk, and when used correctly, HTTPS is the only tool that can protect user accounts from this vulnerability.

Even if you establish a secure login with Server B and the user browses on Server A, through something like OAuth, all an attacker needs to do is intercept their OAuth token and impersonate the end user.

Just use HTTPS. If your web hosting is preventing you from doing so, get a cheap VPS and take control of your website. If your advertising network is preventing you from doing so, put pressure on them to support HTTPS. Adsense already does.

Community
  • 1
  • 1
Scott Arciszewski
  • 33,610
  • 16
  • 89
  • 206
0

This is not easy and not standard but possible. Your problem is, that you have in fact 2 websites with different session-ids/cookies.

I suppose you want to get authentication and you probably do not want to transfer any password in cleartext.

Thatwhy I would invent some token which might unlock your user on the non-https-website with help of some https-website.

What I would do: I would invent some token that I generate on a hash over his session-id, some text and some construction containing the actual date or year. Or just some random number as Token. You save this token to your database and the users non-https-session. Then send the user to the HTTPS-Site with your login-procedure. https://ssl.example.com/?token=234987239427839428347

If the user can verify his account with his password, you unlock the row with this token in your database. Then you send the user back to your non-https-site.

Whenever some user visits your non-https-site (with generated token and not logged in) you should look for an unlocked token which the session knows. In case that this token is unlocked and correct just log the user in.

This is a solution, it is sure possible but you might think about your initial intentions to do it. Non-HTTPS is nothing that I would personally suggest. But as a webmaster I know the thing with ads and other things that would prevent me to force my users to surf on https. Thatwhy I just gave them a choice. And they dont really care for HTTPS. But some love it.

Nibbels
  • 156
  • 10
  • "This is not easy and not standard but possible. Your problem is, that you have in fact 2 websites with different session-ids/cookies." This still isn't secure though. Traffic to/from the first website can still be intercepted. – Scott Arciszewski Oct 05 '15 at 12:53
  • How would this Login-Process itself be unsecure? This works like paypals authentication where the merchant cannot see the login credentials of their customers. All a third person can see here is this token, which is worthless and sessionspecific, because all is set internally. – Nibbels Oct 05 '15 at 14:09
  • If you can see the token, you can impersonate the user. That's hardy "useless". – Scott Arciszewski Oct 05 '15 at 14:18
  • Only one time you/the visitor/the thief can see a token. And that is when the user is sent to the other site. There you kind of activate and destroy the token with the username and the password of a valid useraccount. After the newly logged in person put in his credentials this token is useless and the rest of the communication happens in some internal database. – Nibbels Oct 05 '15 at 16:06
  • Contrast that with deploying HTTPS on your endpoint. Which solution has less complexity, less moving parts, and a reduced attack surface? What you outlined can only be "secure" if you severly cripple how the insecure endpoint operates. – Scott Arciszewski Oct 05 '15 at 16:29
  • Well yes. It is totally clear that using HTTPS would be the very best. But I think such an solution would be the better choice than transferring passwords with some plaintext POST. – Nibbels Oct 05 '15 at 17:25