How to secure passwords over HTTP?

Question

Say my password is abc. I want to send it to the server over HTTP.

I could send it in plaintext and let the server hash it and compare it to the entries in its database, but then anyone that can see traffic over that connection would see the password in plain text.

So then I could hash it client-side and let the server just compare it without hashing since it's already hashed (or the server could even double hash, but no difference in this situation). But then again anyone that can see the traffic would see the password hashed, and then send the hashed password to the server and the server would accept it.

How do I send passwords over HTTP? Do I need to implement some encryption algorithm like RSA public key encryption? Or is this impossible?

The method should be usable in any browser.

Why can't you just use TLS? There's really no other way to do it securely. — AndrolGenhald, Nov 09 '18 at 13:58
@AndrolGenhald I could, this is just a proof of concept. If there's no other way to do it securely then that's the answer I was looking for. You should post it as an answer — FireCubez, Nov 09 '18 at 13:59
You don't need native TLS - you could, theoretically, implement TLS over HTTP - but it would be nowhere near practical. — Reinstate Monica, Nov 09 '18 at 17:54
@AndrolGenhald There is no good reason to not use TLS, but I believe there are lots of other ways to do it securely. For example, one could tunnel http through ssh. — emory, Nov 10 '18 at 15:02
@emory The poster clarified that the context is Web browser to HTTP server communication, not custom application to custom server. — curiousguy, Nov 11 '18 at 02:01
Is this a real problem you are facing or just a thought expirement? — whatsisname, Nov 11 '18 at 03:29
@whatsisname I stated that in a previous comment, it's just an experiment — FireCubez, Nov 11 '18 at 12:04
While I hate it when you ask A and people reply "just use B", I'll have to agree with the many "just use TLS" answers since that's the most straightforward way for a practical problem. Now you stated that it's _not_ about a practical problem but "just for experiment", so you may want to read up on [zero knowledge protocols](https://en.wikipedia.org/wiki/Zero-knowledge_proof) which do what you want. — Damon, Nov 11 '18 at 15:51
The original MSN Messenger password implementation catered for this scenario. The server sent you a "salt" and you hashed your password using that and sent the hash back to the server. As the server knew your password, it could perform the same calculation. The server was responsible for making sure that it didn't re-use salts — Matthew Steeples, Nov 12 '18 at 11:30
FWIW, even if you manage to transfer the passwords securely, you will have accomplished nothing. The rest of the session is unencrypted, it can easily be stolen or modified. Even if you can securely prove "You're Bob", the moment this happens, Alice can steal your session and "be Bob" for as long as she wants. — PushfPopf, Nov 12 '18 at 15:12
@curiousguy If OP ran `ssh -L 127.0.0.1:8080:intra.example.com:80 gw.example.com` then browsed to http://127.0.0.1:8080, then the connection will be encrypted and passwords secured. (1) This assumes that OP can ssh into gw.example.com and (2) maybe the web server does not respond to local requests. This example may/may not work for OP, but the contention that TLS is the only way is wrong. — emory, Nov 12 '18 at 19:11
@emory Isn't that _in effect_ using TLS, but just having `ssh` do it rather than implement it directly in the client? And wouldn't the connection from `gw.example.com` to the real webserver still be vulnerable to eavesdropping? — TripeHound, Feb 24 '20 at 14:35
@TripeHound I would recommend justing using TLS and not worrying about these issues. But if it is in effect using TLS but having ssh do it rather than implement it directly in the client, then the connection to the real webserver would not be vulnerable to eavesdropping. — emory, Feb 24 '20 at 15:10

score 115 · Accepted Answer · edited Nov 09 '18 at 20:27

115

You can't.

To securely send information over an unsecure channel, you need encryption.

Symmetric encryption is out, because you would first need to transport the key, which you can't do securely over an unsecure channel[*].

That leaves you with public key cryptography. You could of course roll your own, but you don't want to be a Dave, so that's out, which leaves you with HTTPS.

_{[*] You can of course try to use a secure channel to exchange the key, for example physical exchange of a key. Then you can use secret key crypto, like Kerberos.}

edited Nov 09 '18 at 20:27

luttje

163
4

answered Nov 09 '18 at 14:08

tim

29,018
7
95
119

Couldn't you hash it twice? Once on the client side, once on the server? – Nathan Merrill Nov 10 '18 at 22:33
23

@NathanMerrill - [Hashing the password on the client side just makes the hash the password](https://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side) (absent some scheme to include extra information). However, only securing the password is worthless - you have to at least authenticate the **channel**, or an attacker can impersonate both ends of the conversation, even without knowing the password. – Clockwork-Muse Nov 11 '18 at 04:55
2

This is misleading. Yes, you can. This question asks for how to secure passwords when you can't use HTTP. A bad company policy, a misconfigured firewall can all force HTTP to be used. In situations like this, exchanging certificates (IPsec TLS SCRAM etc) through a side-channel is possible and should be the answer. Answer the question instead of giving advice that was not sought after. – noɥʇʎԀʎzɐɹƆ Nov 12 '18 at 01:17
5

@noɥʇʎԀʎzɐɹƆ I did mention that there are alternatives when a secure side-channel can be used (which is required for the alternatives mentioned in other answers). But that's not really what the question is about ("The method should be usable in any browser"). There are definitely use-cases for these alternatives, but "we can't use HTTPS because our infrastructure is too broken" shouldn't be one of them. – tim Nov 12 '18 at 10:40
I agree with the main poin - it can't be done. But I'd add that even if you are Dave and roll your own crypto, it would not help. The code that does the crypto is delivered over HTTP, and can therefore be tampered with. – Anders Nov 13 '18 at 14:44

score 45 · Answer 2 · answered Nov 09 '18 at 14:09

TLS is really the only way to do it.

But what if I encrypt it with JavaScript?

The attacker can change the JavaScript you send to the client, or simply inject their own JavaScript that logs all information entered.

Then I'll use CSP and SRI to prevent the addition of scripts and the modification of my own scripts.

Glad you're using modern tools to help protect your site, but SRI in a non-secure context really only protects against the compromise of an external resource. An attacker can simply modify the CSP headers and SRI tags.

There's really no way to do this without using encryption from the beginning, and the only standard way to do that is to use TLS.

score 25 · Answer 3 · edited Oct 07 '21 at 08:14

25

While I agree that you should use HTTPS, you can make it even more secure by using the Salted Challenge Response Authentication Mechanism (SCRAM, see RFC 5802) for the actual authentication exchange.

It's not trivial to implement, but the gist of it is that, rather than send the password to the server, you send proof to the server that you know the password. Since deriving the proof uses a nonce from the client and server, it's not something that can be reused by an attacker (like sending the hash itself would be).

This has a few added benefits to using HTTPS with the basic authentication you describe:

The server never actually sees your password as you log in. If someone has managed to insert malicious code onto the server, they still won't know what your password is.
If there is a bug in the HTTPS implementation (think Heartbleed), attackers still won't be able to acquire your password. Because, even once TLS is bypassed, the password isn't available.
If, for some reason, you can't use HTTPS, this is better than sending the password in the clear. An attacker will not be able to guess your password based on the exchange. That said, you should still use HTTPS, because defense in depth is better.

Please note that this is only secure if the client is able to perform the SCRAM computations without downloading code from the server. You could provide a fat client, or users may be able to write their own code that they control. Downloading the SCRAM code over HTTP would give an attacker an opportunity to modify the SCRAM code to send the password in cleartext, or otherwise expose it.

edited Oct 07 '21 at 08:14

Community

1

answered Nov 09 '18 at 18:01

Melanie

351
2
4

10

You can safely do this with a fat client (a desktop or mobile application) that is distributed in a safe manner. However, with an in-browser thin client, the client code itself is delivered over HTTP as well, and as @AndrolGenhald pointed out, attackers in the middle can intercept and change it to send the password to them. – Zoltan Nov 09 '18 at 19:07
2

@Zoltan That's very true, thank you for the clarification. The original question doesn't specify whether they need a thin or fat client, so my answer wouldn't apply in all cases. But even over HTTP, I think this provides some additional security. The attack has gone from just snooping traffic to modifying code. Nothing insurmountable, so it wouldn't be secure, but maybe less bad? And I think having both HTTPS and SCRAM is very beneficial. – Melanie Nov 09 '18 at 19:17
If you agree, you may consider mentioning this restriction in your answer. Otherwise I really like your answer as challange-response was my first thought too and none of the other answers mentioned it. – Zoltan Nov 09 '18 at 19:29
Thank you, I've updated my answer. Let me know if you think it could use further clarifications! – Melanie Nov 09 '18 at 19:50
Looks good to me, thanks, upvoted. You should remove the "Thanks to Zoltan" part though, as politeness phrases like greetings, signature and saying thanks are discouradged in questions and answers on Stack Exchange sites in order to focus on the content. Oh, and welcome to Stack Exchange by the way! :) – Zoltan Nov 09 '18 at 20:05
1

@Melanie You are absolutely correct that even with just HTTP it's better. There are attackers only capable of passive attacks. That being said, there's no reason not to use HTTPS nowadays when it's free. – Dessa Simpson Nov 10 '18 at 04:30
Does SCRAM require the password to be stored in a retrievable way on the server? Or can it still be salted+hashed – IanF1 Nov 12 '18 at 05:38
2

@IanF1 The server only needs to know a Hash of the password. Also, all Browsers I know implement a similar mechanism: [HTTP Digest Authentication](https://en.wikipedia.org/wiki/Digest_access_authentication), so even with a thin client one can use this method. On the other hand, HTTP digest is based on the obsolete MD5 hashes, but I am not sure how insecure it is due to this (MD5 is not broken for every application). – Jost Nov 12 '18 at 05:59
@Zoltan, I've removed the thank you. Although I don't like not giving credit where it's due, I suppose it's here in the comments. Thanks again! – Melanie Nov 12 '18 at 18:26
@Jost Using MD5 (or some function based on iterating MD5, or composition with a salt, or a nounce) to store or check passwords is **no more broken today than it ever was**: computing MD5 or any iteration of MD5 can't be simplified and MD5^1000 still needs 1000 iterations of the computation, and there is no better way to find which x satisfies MD5^1000(x) = y than trying different values of x, or methods based on precomputed lists, which is also the best method for SHA1 or more modern hash functions. No theoretical or practical advance was made here. – curiousguy Nov 13 '18 at 00:44

score 7 · Answer 4 · answered Nov 09 '18 at 18:31

You should definitely deploy TLS in this case.

If you decide to try to invent a transport security system over HTTP, ultimately you're going to end up implementing a susbset of the TLS functionality anyway. There are many pitfalls to be aware of when designing and implementing such a system, which are further amplified when you choose to try to implement the system with a language that doesn't offer many safety features.

Even if you did implement a correct implementation of a cryptographic protocol in JavaScript (which is already a big challenge) you can't rely upon that implementation being resistant to timing attacks, and the whole thing breaks if someone has scripts disabled (e.g. with NoScript).

As a general rule you should choose the implementation that consists of the most simple, well-understood, trusted components that require you to write the least amount of security-critical code. To quote Andrew Tannenbaum:

A substantial number of the problems (in application security) are caused by buggy software, which occurs because vendors keep adding more and more features to their programs, which inevitably means more code and thus more bugs.

score 6 · Answer 5 · answered Nov 09 '18 at 16:03

Do I need to implement some encryption algorithm like RSA public key encryption?

If you're considering trying that, you may as well just go the full mile and use HTTPS. Since you don't seem to be an expert, "rolling your own" encryption will undoubtedly have misimplementations that render it insecure.

score 2 · Answer 6 · edited Nov 10 '18 at 15:29

It is actually quite possible.

Password has to be hashed on the client side, but not with a static function. The following method uses two steps, and is inspired by the Digest access authentication:

NOTE: The server keeps a HMAC of the Password and the corresponding Key (Digest);

The client starts by requesting a nonce to the server, the server returns the Key and the Nonce;
Client calculates: HMAC( HMAC( Password, Key ), Nonce) and sends it to the server;
Server calculates: HMAC( Digest, Nonce ) and compares it to the received value.

This protects you against replay.

The main interest I see is not a protection against eavesdropping, but to be completely sure that the plaintext password will not be store on the server, not even in a system log (see Twitter or GitHub).

Note: HMAC can be replaced by PBKDF2.

Then some attacker can inject some code to get the password directly from the ``. A crazy idea: "Sadly it's *just a little bit* hard to support HTTPS on Reserved IP addresses. Please [run this code on your terminal](https://stackoverflow.com/a/7285256) and paste the result HMAC were." (of course disable copy pasting to prevent pastejacking in the long run). — Gustavo Rodrigues, Nov 10 '18 at 10:34

score 2 · Answer 7 · answered Nov 10 '18 at 10:42

There is actually a way to authenticate a user over an insecure connection: Secure Remote Password (SRP) protocol. SRP is specifically designed to allow a client to authenticate itself to a server without a Man-in-the-Middle attacker being able to capture the client's password, or even replay the authentication to later impersonate the client, whether the authentication succeeded or not. Furthermore, successful authentication with SRP creates a shared secret key that both the client and the server know, but a MitM does not. This secret key could be used for symmetric encryption and/or HMACs.

However, there are a number of limitations of SRP:

The user must have registered in some secure fashion, as the registration process does require transmitting password-equivalent material (though the server does not need to store it).
Although it is safe to attempt an SRP login with an untrusted server (that is, it won't expose your password to that server, and you'll be able to tell that the server didn't have your password in its database), It's not safe to load a login web page from an untrusted server (it could send down a page that captures your every keystroke and sends it off somewhere).
Although successful authentication via SRP generates a secure shared secret key, the code to actually use this key in a web app would need to be loaded from a server, and an attacker could tamper with that code to steal the symmetric key and make changes to the requests and responses.

In other words, while SRP can be useful in situations where you have a trusted client that doesn't need to download its code over the insecure connection and also you have some other secure way to register the user(s), SRP is not suitable for a web application. Web apps always download their code from the server, so if the connection to the server isn't secure, a MitM (or other network attacker, for example somebody spoofing DNS) can inject malicious code into the web app and there's nothing that you, the victim, can do about it. Once that code is there, it can capture any password or other data you enter, steal any key that is generated, and tamper with any requests you send or responses you receive without you even knowing.

score 2 · Answer 8 · answered Nov 10 '18 at 22:51

It is certainly possible to send a password securely using HTTP. There is even a standard for it. It's called HTTP-Digest and it's defined in RFC 7616. It's been a part of the HTTP spec for quite a while. It was originally designed to use only the MD5 message-digest ("hashing") algorithm, but later revisions of the standard allow the client and server to negotiate which algorithm to use.

Unfortunately, there are many problems with HTTP-digest and the most glaring of them is that the server needs to have the password in cleartext. So while it's possible to communicate passwords securely using HTTP, it's not possible to securely-store passwords on the server while using it. So basically, it's not useful.

As others have said, it would be better to implement TLS because it solves multiple problems all at the same time, and it's fairly forward-compatible.

score 1 · Answer 9 · answered Nov 12 '18 at 21:55

As others have said TLS! TLS! TLS! (and with decent key length too)

But if you have to to use HTTP and any server to implement, is this for programmatic use or human use? If for human use, are you looking at basic authentication or form-based? And are your uses able to apply a little logic E.g. not for joe public to use. Does anything else need to be protected, or just the password itself?

If so you may be able to look at:

Use a one-time password pad/generator (RSA fobs ain't cheap, and if you've got that sort of money to spend then you can afford TLS)
Some other 2-factor auth like SMS (not without it's own issues).
A simple challenge/response mechanism to obfuscate the password, for example the page displays two numbers on it in the text (not blatantly labelled either), user has to start password with a simple calculation such as difference between the two numbers added to each digit of a PIN, maybe with random stuff before and/or and after, eg 98634572dkkgdld. Changing the challenge numbers should stop replay attacks that aren't tried instantly, but if an attacker can capture enough attempts they may be able to work it out. You can't put any obfuscation logic in user-facing script either 'cos that'll be seen and if the scheme is too complex your users will hate you even more.

I'd still so with TLS though, certificates are cheap (even free) these days so convoluted obfuscation schemes really have no reason to exist any more.

How to secure passwords over HTTP?

9 Answers9