I am looking at a system where you are able to choose if you are going to connect to the web application via HTTP and/or HTTPS. You have to authenticate on either one. I know that the best option is to use basic authentication with HTTPS, since then you can choose whatever hashing algorithm you like.

But since both of these are going to be supported, are there any other options than to use digest authentication as a "suitable for both" type of solution?

  • 1
    Some sites would use HTTPS for their login pages, and anywhere sensitive data is submit (i.e. credit card number at checkout), and then allow HTTP for the rest of their site, as a compromise. This isn't effective against MITM however. Jul 8, 2016 at 13:04
  • Yes that seems reasonable, but this webapp does the login with both, hence the digest authentication method is used in both cases. I was trying to think of a way to make the downside of digest a little more secure, like trying to hash the "HA1" again and store this on the DB instead.
    – kung
    Jul 8, 2016 at 13:59
  • You have some good answers here, but this begs the question, if the system supports HTTPS, why must it continue to support HTTP? (which is always vulnerable to MITM) Jul 8, 2016 at 14:32

2 Answers 2


If you really need to use authentication with plain text (HTTP) then you should make sure that sniffing the credentials will not compromise these. While sniffing is easy with basic authentication, a properly done digest authentication (i.e. with nonce to defend against replay attacks) is much better. Unfortunately with digest authentication you need to save the passwords at the server in clear text or an equivalent.

But the best option is of course to not transfer any sensitive data with plain HTTP and this includes authentication credentials.


In theory you could use AJAX with a JavaScript implementation of RSA encryption, essentially recreating what the HTTPS/TLS connection would normally do for you from an encryption and key exchange standpoint.

It gives you an alternative to storing the password in plain-text server-side as HTTP Digest Authentication (using nonce) would require. Also a JavaScript implementation gives you the flexibility to encrypt other information besides the password.

In your JavaScript RSA implementation, be sure to use native Web Cryptography where available, as this will allow you to use a faster & stronger key size.

Once developed, your RSA implementation could be secured against replay attacks, and effectively protect any data that was encrypted. However on an HTTP connection you are always vulnerable to MITM which could serve an altered JavaScript file to bypass your encryption.

You must log in to answer this question.

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