Dfyjkt

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.

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.

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.