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.

  • 85
    Why can't you just use TLS? There's really no other way to do it securely. Commented Nov 9, 2018 at 13:58
  • 4
    @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
    – kepe
    Commented Nov 9, 2018 at 13:59
  • 1
    You don't need native TLS - you could, theoretically, implement TLS over HTTP - but it would be nowhere near practical. Commented Nov 9, 2018 at 17:54
  • 3
    Is this a real problem you are facing or just a thought expirement? Commented Nov 11, 2018 at 3:29
  • 1
    @whatsisname I stated that in a previous comment, it's just an experiment
    – kepe
    Commented Nov 11, 2018 at 12:04

9 Answers 9


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.

  • Couldn't you hash it twice? Once on the client side, once on the server? Commented Nov 10, 2018 at 22:33
  • 24
    @NathanMerrill - Hashing the password on the client side just makes the hash the password (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. Commented Nov 11, 2018 at 4: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. Commented Nov 12, 2018 at 1: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
    Commented Nov 12, 2018 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
    Commented Nov 13, 2018 at 14:44

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.


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:

  1. 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.
  2. 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.
  3. 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.

  • 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
    Commented Nov 9, 2018 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
    Commented Nov 9, 2018 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
    Commented Nov 9, 2018 at 19:29
  • 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. Commented Nov 10, 2018 at 4:30
  • 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, 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
    Commented Nov 12, 2018 at 5:59

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.


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.


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:

  1. 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).
  2. 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).
  3. 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.


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);

  1. The client starts by requesting a nonce to the server, the server returns the Key and the Nonce;
  2. Client calculates: HMAC( HMAC( Password, Key ), Nonce) and sends it to the server;
  3. 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.

  • 6
    Then some attacker can inject some code to get the password directly from the <input>. 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 and paste the result HMAC were." (of course disable copy pasting to prevent pastejacking in the long run). Commented Nov 10, 2018 at 10:34

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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .