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?

  • 3
    By HTTP authentication you probably mean Basic AUTH? It's OK to use only if you use HTTPS connection to transmit your credentials. Commented Sep 15, 2014 at 13:13
  • 5
    You should clarify what you mean by "HTTP authentication" (and what other methods you have in mind).
    – Bruno
    Commented Sep 15, 2014 at 17:02
  • @Bruno HTTP authentication is defined. There are specifications for it. See RFC 2617.
    – Xander
    Commented Sep 15, 2014 at 19:51
  • 10
    @Xander I know, but the title of RFC 2617 is not just "HTTP authentication", but "HTTP Authentication: Basic and Digest Access Authentication". There could be (and there are) other forms of authentication when using HTTP. That's why I was asking for clarification.
    – Bruno
    Commented Sep 15, 2014 at 20:00
  • 4
    On StackExchange sites, we expect you to do research on your own before asking, and to show us what research you've done in the question. In this case, it looks like you haven't done even a modest level of research. For instance, Wikipedia has an article on the topic, which already mentions some dangers. So, please do more research before asking. Only ask questions that you really care about; and if you care about it enough others for help, spend some effort on your own first.
    – D.W.
    Commented Sep 15, 2014 at 23:09

3 Answers 3


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.

  • 6
    From a security point of view, having the client provide the authentication UX is a good thing, as it gives the user a consistent interface across all sites, disrupts the site's user experience, creating attention and also implicitly informs the browser that the information returned is part of another authentication realm, so script access to protected resources from outside the realm can be inhibited. Commented Sep 16, 2014 at 5:43
  • @SimonRichter That is generally true, and there certainly are positives to the client handling the auth UX. However, in this specific case, there are significant limitations, and these limitations are trade-offs.
    – Xander
    Commented Sep 16, 2014 at 13:03

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

  • You can Although I agree you have to go through some quirks for logging out.
    – Ángel
    Commented Sep 17, 2014 at 14:16

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.

  • 2
    It's worthwhile to explicitly note that any authentication data (user creds, digest, session cookie, or any any other form of auth data) should be delivered over HTTPS. No mechanism is remotely safe when delivered over HTTP in the clear.
    – Xander
    Commented Sep 15, 2014 at 15:10
  • 2
    A secure system should not be relying on a salt being secret. A salt's job is purely to defend against rainbow tables, and it does this whether it is secret or not. Commented Sep 15, 2014 at 15:58
  • 3
    @Xander The problem with digest auth is that even when combined with SSL it still forces you to tore insecure passwords. Commented Sep 15, 2014 at 16:00
  • 2
    @ChrisMurray Proper salting prevents multi-target attacks in general, not just rainbow tables. In most situations other multi-target attacks are preferable over rainbow tables from the attacker's PoV. Commented Sep 15, 2014 at 16:03
  • @CodesInChaos Yes, that is a good point I didn't mention.
    – Xander
    Commented Sep 15, 2014 at 16:10

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