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.
• Any improvement better than plain passwords is welcome. We do not aim for a 100% l33tG0Dhx0r-proff solution. Difficult to crack is better than complicated to hack which is better than a trivial sniffing revealing the password.

Answer 1

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.

If your host doesn't support HTTPS then a service like Cloudflare Universal SSL can be used to ensure all browsers connect to your site using HTTPS, even if your server doesn't support SSL/TLS. The connection between Cloudflare and your website will still be unprotected, but this Cloudflare service is intended to protect users against threats found on public wifi networks. From the perspective of a penetration tester, not providing HTTPS is highly suspect, if you aren't providing a basic security requirement as delivering traffic, then what other security requirements are you missing? HTTPS certificates can be obtained for free using Let's Encrypt or Start SSL, there is no legitimate reason not to support HTTPS.

HTTPS vital because it does lot more than just "encrypt passwords". Another important role is that it should prevent the user from giving logging into a malicious server that is impersonating a real server. Using a system to protect the password alone is still a violation of OWASP A9 - Insufficient Transport Layer Protection because you would still be transmitting session credentials in plain text which is all the attacker needs (Firesheep).

1. JavaScript-based cryptography cannot be used to construct a secure transport layer.

2. "Tokenize logins": If an attacker is sniffing the traffic, they'll have the plain text username/password and then they can just login with these new credentials. (Replay attack)

3. "Somehow encrypt the transmitted 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/TLS then this is not a problem.

There are other more complex 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, which lead to the HTTP-Strict-Transport-Security standard.