1

My web application is receiving increased attention and I need to provide additional security to protect my customers.

The biggest problem as I see it is that the user login data is sent as plain text. My goal with this question is to discern if the following approach is an improvement or not.

In extension I will need to get dedicated servers for my service. This proposed solution is temporary until then.

I am currently running my web application on a shared hosting web server which only provides SSL through their own domain.

http://mydomain.com

is equivalent to

https://mydomain-com.secureserver.com

My thought is to have:

http://mydomain.com/login.php

...in which an iframe opens a page from the secure server, something like this:

<iframe src="http://mydomain-com.secureserver.com/ssllogin.php"></iframe>
  • I authenticate the user in ssllogin.php with the (hashed+(per user based-randomly salted)) passwords from the database.
  • After proper session regeneration set a session verifying the authentication.
  • This session is then somehow transferred and verified on http://mydomain.com

Is this approach even possible to achieve? Would this be an improvement of my login security or just move the "point of interception of password" for the attacker to another instance?

All feedback is appreciated.

Mattis
  • 5,026
  • 3
  • 34
  • 51

1 Answers1

3

You don't need an iframe. Just make the action of the login form to point to https://yourdomain.com/login.php . In there you may check if user & password are correct, and then redirect again to plain http.

BUT this is not 100% secure. The fact that you are sending the user & password via https may prevent an attacker or sniffer to get that. But if you later revert to plain http, it is possible to this attacker/sniffer to hijack the session of any logged in user sniffing the session cookies of this user.

If you want more security (not 100%, but more than this previous option), stay always in https, for all resources (css, js, images too, not just your php/html files), and even serve the login page via https.

For some reasoning of these points, see firesheep (for the hijacking session problems) or the recent tunisian gov't attack on tunisian facebook/yahoo/gmail users (for serving even the login page via https).

edit: sorry, I misread your question. If the SSL domain is different than the not-ssl domain, you may have problems, as the session cookie only will work against the same domain or subdomains. So, if you do the login and send the session cookie from https://yourdomain.secure-server.com, it will only be sent back by the browser to yourdomain.secure-server.com (or *.secure-server.com if you will), but not to yourdomain.com. I think it's possible to make a wildcard cookie valid for all *.com subdomains, but it's better not to do this (do you want your users' session cookie be sent to evil.com ?)

Carlos Campderrós
  • 22,354
  • 11
  • 51
  • 57
  • Well written. Switching back to HTTP you can protect the password, but not the session data you want to protect with the password. – martinstoeckli May 10 '11 at 14:45
  • Thank you Carlos. I was planning on trying to make stealing the sessions harder according to this post: http://stackoverflow.com/questions/5081025/php-session-fixation-hijacking . However, I was also planning to send the session cookie to both evil.com and mischief.net. – Mattis May 10 '11 at 14:56
  • "...and even serve the login page via https"? If you want any security at all, you *must* serve the login form over https. It is trivial to intercept the login form and interpose an MITM attack. Rendering a login page over http just gives you a false sense of having accomplished something secure. See: http://www.thoughtcrime.org/software/sslstrip/ – T.Rob May 13 '11 at 19:57