If you are using SSL already, it appears Basic auth is the way to go since you can perform bcrypt with the password when you store it in the database, where as Digest auth only allows md5. As we know, in case of database theft, md5 can be "cracked" faster than bcrypt.

My question now is, given SSL is present, and the fact you can't bcrypt Digest auth passwords, why would I still want to use it over Basic auth? Or is Basic auth the way ago if there is SSL.

BTW this is for a REST API server

  • I see no web-browser tag...?
    – curiousguy
    Commented Aug 13, 2012 at 20:58
  • 2
    When did you last see a customer facing site which used either digest or basic HTTP authentication?
    – symcbean
    Commented Aug 13, 2012 at 22:27
  • 1
    @symcbean Should have cleared it this is for REST API server. BTW, Cpanel uses HTTP auth.
    – IMB
    Commented Aug 14, 2012 at 8:26
  • 3
    Why can't you use bcrypt with digest auth? Can't we apply bcrypt to the value sent by the client (over SSL) and then compare it to the database value (which also had bcrypt applied to it)? From your question I guess there's a good reason, but I can't see it.
    – tibbe
    Commented Oct 2, 2013 at 0:02

4 Answers 4


Your assumption is correct. Basic auth is the way to go, as long as you're using HTTPS properly. It allows you to implement all of your crypto and access policies in the webapp, instead of being tied to the security model of your HTTPD.

  • 1
    Your message isn't clear (at least to me): "access policies in the webapp" = HTML form?
    – curiousguy
    Commented Aug 13, 2012 at 20:56
  • @curiousguy No, what I meant was that the basic auth dialog could be backed by a script, which does the hashing and other authentication and limitation. Jimbob's answer is much more detailed than mine, as I neglected to consider webforms as an alternative.
    – Polynomial
    Commented Aug 13, 2012 at 21:02

The choice isn't just between basic auth and digest auth if you are using SSL. Digest auth is preferable to basic auth if you have no SSL, though still leaves you a bit vulnerable to man in the middle attacks; though it makes it them more complicated than basic auth.

However, I'd avoid basic auth for several reasons:

  • an ugly interface to login (a barely configurable pop-up alert when you first go to a protected page) versus an optional login form somewhere on the page.
  • on a bad login attempt, 401 - Unauthorized messages are worse than a customizable wrong password screen; where maybe you add a CAPTCHA, or have links that could remind username based on email address, or reset a lost password, or create a new account.
  • You generally can't log out of Basic Auth login without closing the browser.

For this reason, I'd recommend using cookie-based sessions (over SSL) for those reasons, where again you use a strong hash (e.g., bcrypt) to store the password.

  • Good points. I assumed OP had to use standard HTTP auth, and neglected to consider the better alternative.
    – Polynomial
    Commented Aug 13, 2012 at 16:34
  • 3
    Thanks for the pointers. So I guess if you don't need the "ugly" interface (i.e., you are using HTTP auth for REST API server, and client's don't see/use the screen because they hard-code the login process), then I guess basic auth is still pretty good on SSL.
    – IMB
    Commented Aug 13, 2012 at 16:53
  • @IMB - I agree with that. I assumed http was being used in the browser, versus in a RESTful API. In that case, while session cookies could still be used as well as other schemes, I see no real difference in security/user experience. However, be careful not to persistently store passwords in plaintext at the client end that implements the API. A token based alternative, e.g., where you authenticate with a password once, get back a random token that expires and only is good from one client (e.g., based on IP), and then use the token to do authorized actions in the future may be preferred.
    – dr jimbob
    Commented Aug 13, 2012 at 17:49
  • 1
    @drjimbob "based on IP" legitimate clients might use many different IP addresses
    – curiousguy
    Commented Aug 13, 2012 at 20:57
  • @curiousguy - The nice thing about IP addr (only an example) is that it often is static for long periods and not easy to fake due to TCP handshake. Yes, this won't work if it has to be convenient on a mobile device where your IP changes very frequently. But even for a laptop used in a handful of places, the system could require a new authorization for each new IP used (keeping track of last 10 IPs) and require new authorization every time adding a new IP. This step obviously depends on the specific application and its security requirements vs usability/hassle of repeated logins.
    – dr jimbob
    Commented Aug 13, 2012 at 21:19

The Digest protocol specification dates from 1999, which was a time when SSL was still viewed as a tool too expensive to be employed generically. The RFC begins with this paragraph, which gives the context:

"HTTP/1.0", includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL 5), as the user name and password are passed over the network as cleartext.

This is the only reference to SSL in the whole document. This makes things clear: Digest was designed to try to cope with the glaring issue of sending passwords in the clear, as Basic does when not used with SSL. We know, however, that not using SSL is a big problem anyway, because attackers have advanced a bit since last century: they no longer content themselves with passive eavesdropping, they actually hijack connections and implement man-in-the-middle attacks. No amount of Digest will save you in that case.

Note that one possible advantage of Digest over Basic is that you do not reveal the password even to the server itself, in case that server is hostile -- by which I mean that you are talking to a fake server, controlled by the attacker. Digest will not protect against a MitM, so in that situation you are already doomed, but only locally doomed: the attacker can see your data, and alter your requests, but he does not learn your password so he will not be able to come back later by himself. Several points make this advantage very small:

  • Even though Digest with a fake server does not reveal the raw password to the attacker, it still give enough to run a dictionary attack, and a very efficient one since it is only a couple of MD5 hashes (nothing even remotely comparable to bcrypt).

  • The inherent MitM attack is serious enough to mandate proper data integrity checks, which means SSL (with full server certificate validation, please !). If MitM is defeated, then the advantage of Digest over Basic evaporates as dew in the morning sun.

On the other hand, as you have noted, using Digest implies that the server must store the passwords themselves (possibly encrypted, but in a reversible way), and that is a big drawback of Digest authentication.

For the best of all worlds, use TLS with SRP which is SSL/TLS with a kick-ass password-based key exchange, where:

  • the server needs not store the password, only a verification token (a kind of hash);
  • there is no certificate at all;
  • the authentication is mutual and relative to the password;
  • even an attacker impersonating the server, the client, or both, cannot learn enough data to run an offline dictionary attack.

The only, "minor" trouble is that TLS+SRP is not widely supported (yet). GnuTLS can do it. We can hope for more extensive support in the future. Meanwhile, use Basic authentication within SSL, do not forget to thoroughly validate the server's certificate, and use bcrypt to store a password hash server-side.

  • 2
    As I understand it, Digest does not imply storing the passwords on the server. The server can store hashes (non-reversible). Commented Aug 27, 2014 at 13:09
  • The RFC is incorrect in its first paragraph. In the Basic auth, the username and password are not transmitted in clear text. They are transmitted in an encoded string. Commented Aug 28, 2014 at 9:52
  • 4
    Everything is "encoded" in a protocol, since a password is a sequence of characters, while a wire conveys bits. "Cleartext" means "whatever can be decoded into the actual source data without knowledge of any secret value"; this is the case for Basic authentication, in which the encoding conventions (Base64, then ASCII) can be reversed by anybody. Commented Aug 28, 2014 at 13:03
  • If the server could have, after receiving the user name, indicated that that the password should be hashed N1 times with nonce V1, then N2 times with nonce V2, etc. would that have allowed for reasonable security (albeit for the login process only) if the server stored the results of the first hash (and V1 was the salt), and V2 was a time-dependent nonce?
    – supercat
    Commented Feb 25, 2015 at 22:06
  • 1
    "No amount of Digest will save you in that case." -> Actually, from what I understand: Some amount of Digest will save you in this case (protect against MITM attacks): talks.codegram.com/http-authentication-methods#/step-14
    – Magne
    Commented Apr 28, 2015 at 11:50

The password storage for digest auth is actually worse than you suggest. If an attacker captures the password hash, they can use this to perform a digest authentication themselves. No cracking is needed. As others have mentioned, digest auth had its place before SSL was widespread.

Basic auth over SSL is basically fine. However, you might want to consider a session based solution. Rather than send the password with every request, send it once to setup a session, then send the session id with each request. Given that the password is the most secret thing, this minimises how much it is sent around.

Another poster mentioned SRP, and while SRP has various security advantages, it is not widely implemented, so it's a non-starter for most web apps.

You must log in to answer this question.

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