I have been reading about SSL/TLS for the last few days and looks like it has never been practically cracked.

Given SSL/TLS is used for all communications between client application and the server, and given the password/API key is random and strong and securely stored on the server-side (bcryted, salted), do you think Basic Auth is secure enough, even for banking services?

I see a lot of people disliking the idea of username/password getting sent on the wire with every request. Is this a real weak point of Basic Auth (even with SSL/TLS used), or is it just out of irrational fear?

  • Theoritically SSL is strong enough but one small implementation failure can break your system.. And there has been implementation failures!
    – EralpB
    Commented Mar 23, 2017 at 9:49

3 Answers 3


HTTP Basic Authentication is not much used in browser-server connections because it involves, on the browser side, a browser-controlled login popup which is invariably ugly. This of course does not apply to server-server connections, where there is no human user to observe any ugliness, but it contributes to a general climate of mistrust and disuse for Basic Authentication.

Also, in the 1990s, before the days of SSL, sending plaintext passwords over the wire was considered a shooting offence, and, in their folly, people considered that challenge-response protocols like HTTP Digest were sufficient to ensure security. We now know that it is not so; regardless of the authentication method, the complete traffic must be at least cryptographically linked to the authentication to avoid hijack by active attackers. So SSL is required. But when SSL is in force, sending the password "as is" in the SSL tunnel is fine. So, to sum up, Basic Authentication in SSL is strong enough for serious purposes, including nuclear launch codes, and even money-related matters.

One should still point out that security relies on the impossibility of Man-in-the-Middle attacks which, in the case of SSL (as is commonly used) relies on the server's certificate. The SSL client (another server in your case) MUST validate the SSL server's certificate with great care, including checking revocation status by downloading appropriate CRL. Otherwise, if the client is redirected to a fake server, the fake server owner will learn the password... In that sense, using something like HTTP Digest adds some extra layer of mitigation in case the situation got already quite rotten, because even with HTTP Digest, a fake server doing a MitM can still hijack the connection at any point.

If we go a bit further, we may note that when using password-based authentication, we actually want password-based mutual authentication. Ideally, the SSL client and the SSL server should authenticate each other based on their knowledge of the shared password. Certificates are there an unneeded complication; theoretically, SSL client and server should use TLS-PSK or TLS-SRP in that situation, and avoid all the X.509 certificate business altogether.

In particular, in SRP, what the server stores is not the password itself but a derivative thereof (a hash with some extra mathematical structure). One shall note an important point: in the case of a Web API, both the client and the server are machines with no human involved. Therefore, the "password" does not need to be weak enough to be remembered by the meat bags. That password could be, say, a sequence of 25 random characters, with an entropy gone through the roof. This makes the usual password hashing methods (slow hashing, salts) kind of useless. We still want to avoid storing in the server's database (thus as a prey to potential SQL injections) the passwords "as is", but, in that case, a simple hash would be enough.

This points to the following: ideally, for a RESTful API to be used by one server to talk to another, with authentication based on a shared (fat) secret, the communication shall use TLS with SRP. No certificate, only hashes stored on the server. No need for HTTP Basic Auth or any other HTTP-based authentication, because all the work would have already occurred on the SSL/TLS level.

Unfortunately, the current state of deployment of SRP-able SSL/TLS implementations usually means that you cannot use SRP yet. Instead, you will have to use a more mundane SSL/TLS with an X.509 certificate on the server side, that the client dutifully validates. As long as the validation is done properly, there is no problem in sending the password "as is", e.g. as part of HTTP Basic Authentication.

  • Thanks for the detail explanation. Yes it would be nice to have TLS-PSK or TLS-SRP, they sounds really good, but for now it looks like Basic Auth via HTTPS is fine. I still have one concern: do I need to worry about the password being stored as-is in client program's memory (because it needs to be sent with every request), thus more prone to hacking?
    – dnang
    Commented Nov 9, 2013 at 4:03
  • 1
    This is a good answer but I disagree with the conclusion that HTTP Basic authentication over TLS is secure enough. See security.stackexchange.com/questions/988/…. Also, we are looking for user authentication vs. device authentication. Do the TLS modes you mention support that?
    – Ed Greaves
    Commented Mar 12, 2015 at 17:16
  • "The SSL client MUST validate the SSL server's certificate with great care". Could you elaborate what the server should do with "care"? Would putting a simple nginx proxy to handle the ssl work well?
    – lucaswxp
    Commented Jan 23, 2017 at 1:20

A primary problem with HTTP authentication is that there's no way to log out, other than to close your browser. And since the password goes with each request, the authentication is stateless. You can't log users out after 20 minutes of inactivity, for example.

High-security sites like banks will typically (always?) provide not only a means for a user to log out manually, but will also log user out after a period of inactivity. This helps prevent a number of opportunistic attacks.

  • 2
    No, that's not an issue because I'm asking about authenticating against a Web-Service (server-server communication).
    – dnang
    Commented Nov 3, 2013 at 1:58

Actually I have seen these requests being sent by my bank. However they do still use session identifiers instead of sending the username and password every single time (this is not really restful, I know). The reason why they do not use just username and password but a session is because they require a second factor of authentication. This means that you would need to re-enter your challenge response for every page reload.

If your bank is just using username and password, then honestly I wouldn't care about it. But in my opinion, any self respecting bank application should use a form of two-factor authentication: either through SMS, card readers, tokens,...

  • OK, so that means the SSL/TLS itself is secure enough. It is the human risk (expose password to 3rd party) that needs to be addressed? And given that human risk is addressed, then SSL/TLS and Basic Auth alone can be considered secure? Do you think HMAC, nonce, etc are for pre-HTTPS era only?
    – dnang
    Commented Nov 2, 2013 at 14:08

You must log in to answer this question.

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