Login without HTTPS, how to secure?

Question

For a webapplication, when HTTPS is not available as a security measure, is it possible to still make the login somewhat secure? E.g.:

• Tokenize logins, to make repeat attacks difficult?
• Somehow encrypt the sent password from a HTML password field?

In particular I'm using CakePHP and an AJAX POST call to trigger authentication (includes provided username and password).

Update on the problem:

• HTTPS is not available. Period. If you don't like the the situation, consider it a theoretical question.
• There are no explicit requirements, you have whatever HTTP, PHP and a browser (cookies, JavaScript etc.) offers in real life (no magic RSA binaries, PGP plugins).
• Question is, what is the best, you can make out of this situation, that is better than sending the passwords plaintext. Knowing the drawbacks of each such solutions is a plus.

Answer 1

You can encrypt the password using Javascript and decrypt it on the server.

I would recommend generating an RSA keypair on the server, send the public key along with a timed salt to the browser, then encrypting the password, combined with the salt, using the public key in Javascript.

You can find an RSA implementation in Javascript here

You should include both the IP address and the entire X-FORWARDED-FOR hedaer in the authentication cookies to prevent cookie theft behind proxies.

If you're dealing with sensitive data, you could generate a random AES key in Javascript, then send it to the server along with the password encrypted with RSA.
You could then make the entire application use encrypted AJAX requests from a single page and not use an auth cookie at all.

Note that it is not possible to protect against an active man-in-the-middle attack without SSL. An active attacker can completely replace your site with his own proxy, and there isn't any way to defend against that. (Since there cannot be any known good code)

Answer 2

The short answer is that HTTPS does a lot more than just encrypting passwords. Another important role is that it should prevent you from giving your password to a malicious server in a MITM attack. Using JavaScript to obscure your password is still violation of the OWASP A3 Broken Authentication and Session Management.

1) Tokenize logins: This doesn't matter, if an attacker is sniffing the traffic they'll have the plain text username/password and then they can just login normally.

2) Somehow encrypt the sent password: After the person has logged in an attacker can sniff the traffic to get the valid session id (cookie) and then just use this instead of logging in. If the entire session was protected with SSL then this is not a problem.

There are other more compelx attacks that affect both this system and our current SSL infrastructure. The SSLStrip attack goes into greater detail. I highly recommend watching Moxie Marlinspike's Blackhat 2009 talk.

Answer 3

As you suggested, you may be able to generate a unique token each time the page is created. That same token would need to be sent back with the form data and could not be reused. You could also keep the password safe by using JavaScript to hash it, if you can rely on it being enabled by your users.

This scheme is still not secure, however. An attacker could still see everything going across the wire. They could intercept the token and send a response back to you before the user does. Or they could just wait for someone to login, steal that person's credentials (as they are sent over the wire), and just make their own login request later on.

Bottom Line - you need to use HTTPS to guarantee the site is secure.

Answer 4

You can use HTTP Digest authentication, which is supported by most browsers and does not send the password in clear over the wire.

The downside is the ugly log in box displayed by broswer. If you preffer to stick with forms, then you can implement exactly the same protocol as HTTP Digest in your forms authnetication: send hidden fields containing the realm and the challenge, and have the client add in JavaScript the nonce and compute the digest. This way you'll use a well known and proven exhange protocol, rather than roll your own.

HTTP Digest requires only hash operations.

Answer 5

What about HTTP Digest Authentication? It provides security by MD5-hashing username, password and a nonce (among other things) before sending it to the server. MD5 isn't really secure, but it's a good way for simple security with HTTP.

Of course this doesn't prevent hackers from changing the message... but it secures your password.

Answer 6

The best solution I have seen for somewhat secure HTTP connections is to use a Javascript implementation of md5sum (or some other hash) to avoid transmitting the password in plaintext. You can create a form onsubmit handler in Javascript that replaces the password field with a hash of the original value. This adds a modest amount of security to an unsecure connection, but relies on Javascript running in the browser to work properly.

Answer 7

You don't need SSL.

You don't need asymmetric encryption.

You don't need symeetric encryption.

See http://groups.google.co.uk/group/comp.lang.php/browse_frm/thread/c5960aa0afac2621?hl=en&tvc=1&q=Proposal+for+Lite+Encryption+for+Login+Form+without+SSL

For a discussion of a secure login system.

Note that without SSL you still run the risk of session hijacking.

C.

Answer 8

This is not practically a easy thing to do.

But you could play with other crypto system that is designed for unencrypted connection, maybe sign all your data with pgp or something like that.

But you still may have a problem with "man in the middle" attacks, if you only encrypt the login data. (someone could just resend that data and also get access).

So I can't see this becoming simpler (or safer) that https.

Answer 9

Since you cannot do SSL at the web server, and you are not a security expert, look for an existing secure authentication service that you can utilize, and let them handle both the SSL and the complexities of handling credentials for you.

In particular, I would suggest that you use a free third-party authentication service, such as OpenID. They have libraries for PHP including one for CakePHP.