1. 34

  2. 4

    It’s 2021 and so I don’t need to tell you that having your API pass a username and password through HTTP basic authentication is a bad idea.


    OK user generated passwords are bad (in most cases), but bundling an auth protocol in your API is ihmo worse. HTTP basic auth have some benefits:

    • The website don’t get the password -> xss is no problem, phishing can be avoided with a proper password manager in your browser.
    • You can separate the password on the server side by your httpd -> your huge (maybe broken) back-end don’t get the password

    From a developer/provider view it might look better, but for me from the user view I get a huge black box and a some uglified js where I supposed to put my password in. I get told is everything secure and done with some proper libraries, but I have no way the validate this claim. I can’t check if you keep your implementation (server and client) up to date. So we have a protocol with supports authentication in two ways (HTTP basic auth and TLS client auth), but everyone build a protocol on top which does authentication on there own. Everyone says don’t implement your own crypto, but on the web everyone defines a protocol/API with authentication. Yes with HTTP basic auth I still can validate if your server may leak the password somewhere it shouldn’t be, but at least I can verify the client (or use one I trust) .

    What are the problems passwords have?

    • Bad entropy, because humans are lazy
    • Leak through (maybe another) a provider, because some provider still don’t hash the passwords on the DB

    To solve this we would need an authentication method where the secret is generated by some software we trust and we would need a way to keep this secret away from the provider. Sounds like a job for TLS client auth. Maybe with an high level API with allows to generate CSR without letting the website access the private key, but putting the key in your key-store. So a website could create a CSR on registration. The signed cert (if registration is somehow validated then is imported in the browser. With this TLS cliet auth could be done. If I remember correct there was such an API, but it’s now deprecated.

    1. 2

      I’m not the author, but if we agree that passwords should be in password managers only, then you don’t want to use your password for API requests, because your password is now in a script (or the config of a script). An independent token can be revoked independently, and even renewed periodically. It also may have far fewer privileges than your user account.

      I assumed the article was referring to that, not the actual basic-auth header, which you could totally use for the token if you want.

    2. 2

      There are nice things about authenticated requests. No bearer tokens, no bears. The biggest problem is logistical: it’s a pain to build request authenticating code, so, unless your app gets huge, the only way to talk to it will be with your official SDK that does all the request signing work.

      Shouldn’t there be some standard based around HMAC based auth by now?

      1. 6

        There’s one in the works, but it supports

        • RSA
        • ECDSA
        • HMAC
        • JWS, which in turn supports
          • RSA
          • ECDSA
          • HMAC

        The latter one (JWS) has historically been very error-prone, especially with using asymmetric public keys (e.g. RSA public keys) to validate tokens that advertise themselves as HMAC.

        Naturally, I fully anticipate the IETF to christen this with an RFC number. It appears sufficiently complex and designed-by-committee to get a rubber stamp.