Is BASIC-Auth secure if done over HTTPS?

  • I'm making a REST-API and it's straight forward to do BASIC auth login. Then let HTTPS secure the connection so the password is protected when the api is used.

    Can this be considered secure?

    Yes, the http user/pass will be OK as it goes over SSL, but the password has to be strong.

    Well, i could put some logic in my server that bans a client that attempts too many passwords. Would that prevent DoS and password guessing?

  • AviD

    AviD Correct answer

    10 years ago

    There are a few issues with HTTP Basic Auth:

    • The password is sent over the wire in base64 encoding (which can be easily converted to plaintext).
    • The password is sent repeatedly, for each request. (Larger attack window)
    • The password is cached by the webbrowser, at a minimum for the length of the window / process. (Can be silently reused by any other request to the server, e.g. CSRF).
    • The password may be stored permanently in the browser, if the user requests. (Same as previous point, in addition might be stolen by another user on a shared machine).

    Of those, using SSL only solves the first. And even with that, SSL only protects until the webserver - any internal routing, server logging, etc, will see the plaintext password.

    So, as with anything it's important to look at the whole picture.

    Does HTTPS protect the password in transit? Yes.

    Is that enough? Usually, no. (I want to say, always no - but it really depends on what your site is and how secure it needs to be.)

    actually, even with HTTP Digest, you may be able to a hash of the password (`md5(username:realm:password)`, sometimes called HA1).

    @AviD♦ Imho your points 3) and 4) are rarely valid for REST APIs.

    In case of basic auth, the password "has to be" stored in the browser, which can only be done via a cookie, which can never be considered safe. I posted a similar question here: My conclusion was that Basic Auth is NOT safe, that it should NOT be used as such, and that storing sensitive data at the client (such as a user password) should not even be considered.

    @KimGysen for Basic Auth, the password is NOT transmitted or stored in a cookie, it is sent in the `Authorization:` request header, and stored in a special (protected) part of the browser's memory. Not that I disagree with you, in the general case Basic Auth should not be used, however there are certain situations where the tradeoff might be viable.

    The second point is not an issue. Sending credentials with every request keeps your backend stateless.

    In addition to the "larger attack window," there's no built-in mechanism like account lock out to protect against brute forcing.

    @Artjom: Sending Basic credentials on every request is an issue, not because you have to keep sending the credentials, but rather because the same string is sent on every request. There are other authentication mechanisms, like HMAC, where the Authorization header cannot be decrypted back to the user's secret, and the server can authenticate the request without actually knowing the user's secret. In this mechanism, the string sent on the Authorization header changes based on the hash of the request.

    @LieRyan I honestly don't get it :-\. What's the problem with sending the same string? Is it because variety is the spice of life?

    @DavidS: replay attack. Also, if you pass your traffic through a proxy or CDN service, you have some assurance that an attacker cannot attack the proxy/CDN to alter the user's requests.

    @Bruno, HTTP Digest is *worse* because it requires the server to store the user passwords in plain text!

    @Jacco In principle, the server could only store `md5(username:realm:password)` and not need the password in clear (you can check the content of a file generated with `htdigest` for example). This is implementation dependent. That said, it's still not great (also with the downside of being easily vulnerable to downgrade attacks to Basic).

    "Larger attach window" So normal session token that sends as cookie also have the similar problem right?

    @JithinJose that wouldn't include the user's password, nor is it static + valid for a very long time.

    @LieRyan HMAC isn’t one of the standard HTTP authentication mechanism, unlike Basic and Digest. Were you talking about the one implemented by AWS?

    @LieRyan: Both replay and the proxy/CDN scenario are not possible with TLS, unless TLS has a flaw.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM