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.

Solution 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 is 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.

Solution 2

The short answer is that without SSL endpoint to endpoint encryption, it's impossible to do it securely...

One of the primary reasons for this is that you can't do secure crypto in a browser. See this reference - Javascript Cryptography Considered Harmful.

Additionally, there's no way that you can be sure that the source of the credentials are indeed who you're talking to. Meaning that there's absolutely no way without SSL to be sure that there's not a Man-In-The-Middle Attack going on.

So no, you can't do it.

Additionally, don't even try. Get SSL. You can get free certificates. Hosts will usually give you a dedicated IP for a few $$$ per month. And if you really care about security, you'd be using at least a VM with a dedicated IP address anyway.

To even attempt this would be Security Through Obscurity at best, and nothing at worst. SSL is a solved problem. Why not use that solution. Security is not something to guess at. Use the proper techniques. Don't try to invent your own. It won't work...

Solution 3

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.

---

Edit: (about risks)

While using a 3rd-party secure authentication service (that uses HTTPS itself) can mitigate the problem doing authentication itself without using HTTPS (on your server), it does not entirely eliminate the possibility of attacks.

The most common two attacks would be replay attacks, and session-hijacking where the attacker is able to either re-uses a genuine login session token later, or use a valid session token for their own malicious purpose.

The replay attack can be mitigated by having the session token expiry, and preferably by using a nonce to prevent session replay and to reduces the risk of session hijacking. With a nonce, a legitimate session generates an error if successfully hijacked, because the nonce has expired (been used), so their own session is no longer valid.

If you cannot use HTTPS to encrypt the session token while being transmitted to and from your server, you cannot entirely prevent active attacks such as session-hijacking or man-in-the-middle attack. This may be acceptable in some cases, such as websites with a small user base for non-commercial usage.

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[mctylr]

How secure? How high are the stakes (ballpark dollar figure can be handy guide)? How powerful are potential attackers? I wouldn't trade stocks, or share my darkest secrets on a website that lacked SSL. :)

[sibidiba]

@mctylr This sort of security is obviously not military, financial nor government grade. But still better than plain text login, which is unfortunately common for small sites or sites that must work behind heavy firewalls filtering out HTTPS, or for cheap hosting sites not providing HTTPS (not even a self signed one for a differnt URL). The question is interested in any possible way to increase any aspect of security.

[sibidiba]

@Michael: Why are you trying to make a point in that HTTPS is required. I know that HTTPS can't be fully mimiced on HTTP with JS/cookies and such. There is still no HTTPS available (See desciption. "If you don't like the the situation, consider it a theoretical question.") But also, most shared hostings are like this. Go to any community forum or self hosted blog or most of the sites with less then 10.000 visitors a day, and you will not see a trusted certificate on port 443. And they are still secure enough! Why not add some more to their security? Btw., HTTPS is also no silver bullet.

[rook]

Using JavaScript to obscure your password is still violation of (A3 Broken Authentication and Session Management)owasp.org/images/0/0f/OWASP_T10_-_2010_rc1.pdf It is a short read and it is very informative, and this is my final point in this argument.

[rook]

@sibidiba I hope the fact that nearly everyone on SO disagrees with you answers your question.

[sibidiba]

@The Rook: facts and scenarios, just like requirements, aren't democratic

[rook]

how does your application defend against attacks like firesheep or deal with OWASP A9?

[sibidiba]

I don't know. Maybe my application does not defend against FooBarMagicHack9000. But the question is nevertheless about not having HTTPS available and what you do in that particular scenario to make things more difficult to crack. SSL is no silver bullet either.

[rook]

@sibidiba github is now fully https because of firesheep, facebook and twitter are soon to follow suit. Firesheep is nothing new, but its brining attention to OWASP A9. The most recent problem with https came to light with sslstrip, but thats easy to defend against, just enable the STS flag. Also your answer has a -4 because it do anything.

[Sherbrow]

What about JS-implemented SSL ? just found out this : www-cs-students.stanford.edu/~tjw/jsbn

[L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳]

If you're running code over an insecure channel, this can't be secured, period. Even if you could send code that establishes a secure channel, it wouldn't matter, because the interceptor can simply replace that code with his own. You should instead be asking how to obscure what's happening to delay the attacker from owning you.

[rook]

I strongly recommend changing the answer to this question to anyone else, or leave it unanswered. The current answer is terrifying.

[Sentinel]

I think the question needs clarification. Or the answerers need to re-read the question. The OP only wants to secure the login, not the whole protocol. Perhaps there is no need for a session token. Perhaps the OP only wants to POST data in association with a login as a one-step process, etc.

[rook]

@sibidiba I have updated my answer to provide a real solution. Please change the answer to this post to anyone else. Security is my profession, and this is a serious question that needs a serious answer.

[Peter]

You cannot simulate HTTPS using PHP. There are lot's of options to make your login more secure but if HTTPS is not available, you are out of luck.

[Scott Arciszewski]

The short answer: You need HTTPS to have secure authentication. It's free, why not use it?

[Sven Slootweg]

Why do you believe HTTPS is not an option? Shared hosts provide TLS just fine nowadays.

[Jeremy]

I appreciate your frustration with the answers that don't fit your criteria. For a non-HTTPS solution, please accept SLaks' answer instead. The currently-accepted answer encourages direct password hashing using MD5, which is very broken, and much less secure (against passive observers in the style of Firesheep) that SLaks' suggestion of using RSA or AES. It's a much better way to make the best of the situation. :)

[Scott Arciszewski]

@sibidiba Could you please reconsider the acceptance of ESL's answer? It's vapid and has bad security advice. You cannot get security through MD5 hashing, and "it's better than nothing" is incorrect: a MitM can alter the JS to append the plaintext to the HTTP requests and capture passwords that way.

[Dan Bechard]

@sibidiba Your question is worded as follows: For a webapplication, when HTTPS is not available as a security measure, is it possible to still make the login somewhat secure?. The answer is "No." Whether your like that fact or not, is irrelevant. rook's answer is the only correct answer to your question, as asked.

[rook]

This is a valid use of RSA, but its a moot point. Its not going to stop anyone from getting hacked.

[sibidiba]

Is RSA possible in JavaScript today?. A few years ago I was looking at them, and they did not scale to current key lengths.

[rook]

This doesn't stop anything, the attacker will just hijack the session after it has been authenticated.

[rook]

X-FORWARDED-FOR is not set by all proxies. Also it is trivial for an attacker to spoof X-FORWARDED-FOR.

[mctylr]

The author knows what he is doing regarding cryptography and security, but I don't know if he considers the implementation a secure alternative to SSL. In particular the PRNG looks potentially weak which would undermine the entire thing anyway. There are also attacks on PKCS #1 that this may be vulnerable to. iacr.org/archive/eurocrypt2000/1807/18070374-new.pdf

[mctylr]

Actually, I don't see how this approach prevents a man-in-the-middle attack.

[SLaks]

@Michael: AFAIK, if you use the entire XFF string plus the physical IP address, you aren't vulnerable to spoofing. (Except for proxies that don't set it)

[SLaks]

@mctylr#2: It doesn't. Read my last paragraph

[mar]

Whatever Michael said. If you do go with md5, at least have server send unique challenge, client should send md5(challenge+pass). Sending md5(password) for most users is same as pass in clear. More than replay, the bigger concern would be passive attacker can crack most of your users password. Also if you are over http and you have active attacker, apart form replay and hijacking, it has been demonstrated that attacker can inject script to modify the login form so that they get a copy of entered username, password. use https unless you are supporting some weird mobile device.

[mctylr]

Okay, I did not notice your additional two paragraphs that you added after your initial answer. No problem, glad we can agree.

[sibidiba]

I'm (somewhat) aware of what S offers in HTTPS. But HTTPS is not available in this case. My question is still open, what is the best, what is worth doing, when it is not available?

[sibidiba]

Is logging out possible by now? How can I detect from the server side that the login was a success?

[rook]

@sibidiba https should always be available, even if it is a free self-signed certificate. If it is not then another encrypted tunnel such as a VPN can be used.

[Remus Rusanu]

You are still in control of the authentication process, it happens on the server php scripts. You authenticate the response form against a user database where you have the user name and the HA1 part of the http digest ie. md5(user:realm:password). From the response you reconstruct the Digest hash, starting from the HA1 stored in the database and compare it with the response in the form submit, if they match it means the user had the correct password.

[Remus Rusanu]

The big advantage over other schemes is that it allows for a unified authentication model for browser/user sessions (using forms and cookies, but not transmitting the password over the wire) and REST services, using HTTP Digest.

[Remus Rusanu]

Logging out is handled the usual way, by resetting the auth cookie. It is true though that if the user hits in the browser a part that challenges him to do HTTP digest (eg. enters an REST URL from the site) and if the user enters the correct password in the browser log in dialog, is much harder to log out: the user has to manually clear the password from the browser setting. But that should not happen normally, as the UI part of the site is usually separated from the REST part.

[sibidiba]

HTTPS is not available. Existing problems most of the time can not be solved by requiring the situation to change into one where the problem does not exit. Assume you are stranded on the South Pole after a plane crash. / Survivor: How do we get out of this? There is no mobile network coverage to call help. / You: We must call help on phone! / Survivor: There is no network coverage on this continent. / You: Network coverage should always be available.

[stevenf]

My thinking exactly. If you can't have SSL on your server, let a third party do the SSL for you.

[Jason]

The Rook has listed many of the myriad caveats about the ways you're gonna shoot yourself (mitm is particularly bad here). The only other suggestion I have is to look at Digest Authentication, which is not particularly swell. It's still susceptible to MITM because without an SSL login page, I don't even know if the HTML for the login prompt came from you, so I DA could get turned off on me. Basically you're making a joke of your password system. I'm not saying that to be mean or in-your-face. Figure out how to break the 'no-SSL' problem, or pray nobody gets interested in your site.

[oneAday]

@sibidiba: The point is that without SSL, you can't make it secure. Yes, the scheme you linked to is "better than plaintext passwords." But it's still not even "somewhat secure." Sometimes there just isn't a good solution to a problem, other than changing the scenario. If you want security, your hosting choice (or whatever the limitation is) is wrong.

[sibidiba]

@Andrew: so because WEP encryption is easy to crack, you use no encryption at all when only WEP is available? Crackable does not mean that the attacker you aim for is also on the level.

[oneAday]

@sibidiba: You must've missed the part where I said "Yes, it's better." That doesn't mean you would call WEP "secure", because it isn't. Yes, it's a question of semantics, but it's an important distinction whether you call something "secure."

[alexanderpas]

@sibidiba Network coverage is always availble! Every webserver supports the equivalent of sattelite phones, by default.

[Nick Johnson]

There's absolutely no point in using RSA here - a digest-based authentication scheme would provide the same security with much less complexity.

[Nick Johnson]

@Rook Your criticism applies to any plausible solution that doesn't use SSL, as you've already amply indicated. Let's take it as a given that they're all vulnerable to this.

[ircmaxell]

This is a very bad idea. The problem is that authentication is the least of your worries. You need to protect the entire session. The weakest part of your system is the strength of the entire system. And since you brought up OpenID, This article on the broken StackExchange auth is pertinent...

[ircmaxell]

Except that RSA can't be done securely on the client side. So all of that work for nothing...

[SLaks]

@ircmaxell: Yes. That's what I said in my last paragraph.

[mctylr]

@ircmaxell Except the article you cite, fails to clarify that his demonstration doesn't not identify the potential solution to the weakness discussed, that may be already in place, of server-side session management, where a session is keyed to IP address, perhaps a nonce or salt, and has an expiry time. I.e. An attacker would need an active attack doing IP spoofing, rather than merely passively listening (sniffing) to TCP/IP or WiFi traffic, while the legitimate user is actively logged in.

[mctylr]

need to protect the entire session: This gets back to the fact that you for a comprehensive answer, you need to do a risk assessment of the particular situation and weight the risk/reward of attacks vs. security. If TLS/SSL is not available, then any solution will be subject to the lack of secrecy (or excess of availability in the CIA sense), but that doesn't necessarily mean that integrity, authentication, or non-repudiation is entirely impossible depending on the level of confidence required.

[L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳]

"but relies on Javascript running in the browser to work properly." ...and the attacker can just replace the js with something that sends him the password.

[martinstoeckli]

While your answer is not wrong, it doesn't answer the question. The problem here is about how to transfer the password securely to the server.

[ESL]

A strong - 1, this post contains multiple problems. First and foremost, it's not what ask @sibidiba: HTTPS sometimes is not an option (when you don't have power to decide). Additionally, there is not absolut security as you talk, always there are less or more secure options. This post should be modified or removed

[rook]

@ESL nothing in your post is "secure" or a "solution"

[Ravindra HV]

My answer was to make the login secure. So the user is already expected to know the password.

[Sentinel]

@martinstoeckli : Not necessarily. A one-use only password could be sent by email or sms. This could actually be used for each request.

[martinstoeckli]

@Sentinel - Password hashing is done server side, so an attacker cannot get the real passwords if he gets the stored hashes. If you send a one time token per sms to the user, there is no advantage in calculating a hash client side. A ManInTheMiddle could simply use the hash, and even when he knows the original token he could not reuse it.

[rook]

What about protecting other authentication credentials, such as session IDs? Are you familiar with the OWASP Top 10?

[rook]

This post should be changed, it is Cargo-Cult security. matasano.com/articles/javascript-cryptography

[rook]

The digest can be sniffed and replied. HTTP digest authentication requires HTTPS to protect the credentials transmitted as the "Authorization" http header.

[rook]

JavaScript cannot be used as a security system in this context: matasano.com/articles/javascript-cryptography

[rook]

JavaScript cannot be used as a secuirty system in this context: matasano.com/articles/javascript-cryptography

[rook]

The user-agent is attacker controlled. If an attacker is on an open wifi network, they can sniff traffic, obtain the full session id, as well as the current user-agent. Have you heard of the OWASP top 10?

[comeGetSome]

lol, author is asking about a way to securely login without https, of course there are huge other points to consider, but who asked about session ids? are you sure author wants to maintain sessions?

[Dave]

Nothing but HTTPS will prevent MITM attacks, the question has asked what measures can be taken to improve security, not stop a dedicated attack. Pattern matching a users behaviour represents an extra layer of security. A casual hacker would need to guess the UA string of the legitimate user in order to spoof it, or be faced with a security question.

[Dave]

I think using a timestamp hashed with the password is an interesting idea provided the server and browser are in time sync. Not sure why this was voted down.

[rook]

Why only protect one type of authentication credential? This post strike me as cargo-cult security.

[rook]

What this post is describing is cargo-cult security, and the only person it is fooling is the programmer.

[comeGetSome]

the whole post is against owasp. that does not mean there is no answer.

[Dave]

@Rook can you add any explanation as to why you think this is cargo-cult? Steam place a lot of reliance on this mechanism and as I have explained, it has solved a very real problem of login sharing within my company.

[rook]

The user agent is an attacker controlled string, it is not a secret value, as adversary with access to the Session ID will also have the user-agent. This security check serves no purpose, except to have the appearance of "security". Which makes this cargo-cult programming. None of these suggestions mitigate the impact of plaintext transmission.

[rook]

JavaScript cannot be used to create a secure transport layer: matasano.com/articles/javascript-cryptography

[Wissam El-Kik]

I totally agree that it's not 100% secure, but jCryption relies on OpenSSL and one several handshake methods. All the data sent through a HTTP Request is encrypted: the keys and the values are completely modified/merged etc. It uses RSA and AES for the encryption and you need to generate a Public and a Private Key to use jCryption. Click here to check how it works

[Dave]

But you are only considering MITM attacks, where an attacker has access and the necessary knowledge to compromise the users session. My solution is mitigating password loss to a third party other than the legitimate user. This is a far more common form of security breach, and your comment is about another security issue than the one Im trying to prevent.

[ESL]

@rook 1) There is no "secure" method, HTTPS it's not secure, it's just more secure.[1][2][3] (and a long etc.). If you said so, you lie. [1]: en.wikipedia.org/wiki/Certificate_authority [2]: en.wikipedia.org/wiki/Heartbleed [3]: en.wikipedia.org/wiki/POODLE

[ESL]

rook 2) Your answer it's not a solution, it's not even an answer to the @sibidiba question. You made up your own question and answer it.

[Scott Arciszewski]

Any in-house encryption can trivially be stripped.

[Scott Arciszewski]

I'd just like to add: If anyone is reading this thinking that they found a way to develop a secure protocol better than TLS, they ought to send it to the IETF for consideration for a new internet standard. :)

[Jeremy]

@rook Does this not protect the specific password value from a passive observer on the network? It certainly isn't very secure (since the encrypted passwords or session cookies could still be stolen and used to authenticate to the site), but it should provide nonzero value for the many users who reuse passwords. It should at least be better than the answers suggesting standard HTTP Digest authentication. (However, I'm not a security expert. I'd be very interesting in learning if my understanding is wrong in some way.)

[rook]

@Jeremy Banks good question. In SLacks' scenario, an attacker can obtain the plaintext password by modifying the HTTP response, and backdooring the encryption process. Two other resources on this topic: owasp.org/index.php/Session_Management_Cheat_Sheet and owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet . In short, if a malicious user can obtain an admin account, then who cares what the password is, it's game over.

[Jeremy]

@rook Thanks, but if they're modifying the http traffic then that's not a passive observer. And my comment already explained why you care what the password is: password reuse. I'm not suggesting that it's ever excusable practice from a company, just that it could provide marginal value.

[rook]

@Jeremy Banks It will not benefit your application to assume that the attacker is def and blind.

[a.costa]

dear @rook, what part of "HTTPS is not available" you did not understand?

[Ravindra HV]

@MaartenBodewes - Until the point where javascript has access to the browser's truststore, allowing one to implement https at the application layer, the only option left is to provide an independent interface on https to reset the password.

[Maarten Bodewes]

I've now voted this down, because it simply indicates that you need to encrypt something without explaining how the shared secret is communicated or computed. This is not a protocol, this is a bunch of interesting ideas. Maybe it is useful in the long run, but it doesn't answer the question.

[Maarten Bodewes]

@sibidiba If you crash on the south pole and you cannot contact anybody then you die. There doesn't *need to be a positive answer. Rook just gave you a negative one. And sorry, there is always the possibility to get TLS, even if it means switching to another provider.

[Maarten Bodewes]

This "answer" doesn't state anything that can be used. It says "So is it possible?" but it doesn't even state what is possible. Some handwaving about it being expensive, without even indicating what it is. Probably "setting up your own security protocol". Then it finishes up with some pitfalls from creating your own protocol. Just basic security advice, but no solution (which indeed, may not exist). Nothing about how to prevent MitM attacks or sidestep the problem with missing trusted CA certs in JavaScript.

[Maarten Bodewes]

SRP is a great protocol and often overlooked. At least it won't send any password in the clear before establishing a shared secret (which can be used to authenticate). However, I agree with rook that it doesn't solve the issues with JS crypto.

[rook]

@Maarten Bodewes But there is a great answer - just tunnel out over HTTPS. This isn't a plane crash, no one has to be stuck here.

[Maarten Bodewes]

This answer rings kind of true, but I think any self respecting authentication provider will require you to have at least the same security requirements as that a TLS session will provide. So it remains to be seen if it is a practical solution. And yes, you would still not protect the data being send to the browser - but that's less bad than leaking the authentication details or allowing replay.

[Maarten Bodewes]

Unfortunately, a lot of times that the connection is vulnerable against eavesdropping, it is also vulnerable against active attacks. Just protecting against passive attacks is therefore kind of a moot point. E.g. public WiFi is almost always vulnerable to active / MitM attacks. Using a VPN tunnel would be required if you choose to use this kind of scheme, and even then you would be unprotected where the tunnel ends.

[Maarten Bodewes]

MD5 is secure for key derivation. It is however not secure as a password hash, and therefore the password may still leak.

[Hedzer]

I suppose this is how to secure the connection, but doing login through that afterwards should be trivial. This is like a rudimentary version of HTTPS done manually.