What are the disadvantages of implementing HTTP authentication in a web application?

Question

I know that there are different types of authentication mechanisms available. One among them is the HTTP authentication. What is the danger in using this method compared to other methods?

Answer 1

Basic authentication has a number of drawbacks, one of which is that the username and password are passed in the clear with every request. This is clearly unsafe under HTTP, but is somewhat less vulnerable under HTTPS. However, because the credentials are submitted with every request, it's still worse than any other method (including digest) that does not have this limitation. The primary reason is that now every single request can be a target for cleartext credential theft, not just an initial login request. In most systems, after login, the most an attacker can hope to retrieve is a session or authentication token. With basic auth, any request is an opportunity to steal the user's password. This is not ideal.

Digest auth is somewhat better in that it sends an MD5 digest of some various bits including the username, password, and a nonce (among other values) and not the cleartext credentials...A password cannot be extracted from a captured digest.

With HTTP authentication (in any form) you're also dependent on the client to provide the authentication user experience, which can have its own issues and so needs to be well tested with the clients you expect to be using your application. IN the past, for instance, I've seen specific browsers fail to authenticate because of certain special characters in a password, for instance. With application based authentication UX, you have control over this. With HTTP auth, you do not.

Another attack (and its a very minor one) is that if you display user-generated, externally hosted content on your site, you open yourself up to very subtle 401 phishing attacks. Since your users are used to the client's chrome for HTTP authentication, they won't necessarily notice if they get an authentication prompt on your site for a slightly different domain. Depending on your application, this may not be a valid threat at all, but it's certainly something to consider if you go down the HTTP auth route.

Answer 2

In addition to the other points mentioned, another significant drawback to HTTP Basic Authentication (vs, say, forms-based login) is that it has no concept of "logging out". Once the user inputs their credentials, the browser stores them internally to send with every subsequent request. This means that you can't have a timeout or "Log out" button/link to end the session. If the user wants to avoid the possibility of someone else using their session (e.g. in the case of a shared computer), they must remember to quit the browser.

For more reading: https://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication

Answer 3

Basic access authentication over HTTPS has clear advantages over Digest access authentication over HTTP.

Even with digest access authentication, you can actually store your passwords hashed with an unique salt (realm + username), but first this salt is guessable (this makes attacks against single users and small groups easier), and second you can't use bcrypt, scrypt or PBKDF2 to make hash computation harder. Also, if you chose to store the hashes in a non-recoverable format (which you should do!), you can't change the realm without requiring the clear user password.

In SASL, digest access authentication even has been marked as historic by IETF. For SASL, they had an alternative (SCRAM, clearly demanding SASLPrep for character normalisation for example) they could recommend to use instead. SCRAM for HTTP has unfortunately never passed the draft status (Note that with SCRAM, user's salts aren't secret, too. The attacker can abuse the login mechanism to get salts for every user they want).

Digest access authentication can give a false sense of security. If the attacker can capture a successful login, he can mount a brute-force attack against the password. username, realm and nonce are all known values for the attacker.

Using unencrypted HTTP is, with or without Digest access authentication, not immune from MITM. The attacker may not be abled to catch the password, but they can capture session cookies, and modify content or impersonate the user.

With digest access authentication is only specified for login but not for account setup. You have to do the account setup the "usual way". Even if your code is smart and it only sends the inner hash to prevent the password to be transported in clear text, it can be modified by the attacker to also relay it to them. However, this severe problem exists only one time, at the registration. Assuming the user logs in from only a small amount of machines, you can achieve similar security using TACK for HTTPS. This allows the user's browser to only authorize the certificate it got at the first connection to the site. So only the first connection remains exposed to possible MITM, just like with digest access authentication.