Using HTTP Basic Auth in 2022

Plenty of very simple web apps terminate TLS at the edge ie: at something like API Gateway. So if you then turn on request logging... voila. Hardly a complex scenario, happens all the time. Or at the application layer:

    @path("/login")
    def login(request):
        print("I have a bug, I'll just log the whole request real quick to see wtf is up!", request)

It's actually very hard to ensure that the password doesn't get logged. It requires constant discipline and maintenance. Any bug or change could expose it.

> I would hope that you would use a single-sign-on system with a centralized login page rather than exposing passwords to every web app within it

Implementing SSO is a great idea. Not everyone wants to use SSO though. If I were hosting a porn site I wouldn't expect my users to happily "sign in with Facebook". It's also much more work than a basic client hash.

> This is what I meant by clean logs - anywhere the password is used, ensure there is no record. How much code and how many layers does a password need to go through?

You underestimate the places logs can be generated or passwords can be accidentally persisted.

1. Your proxy

2. Crashes, stack traces, segfaults, core dumps, thread dumps, VM snapshots, free'd memory

3. Firewalls, both network and host

4. Audit logs for security, such as via ebpf or other auditing frameworks

5. The application, at any layer. In Python, did you know I can get a reference to the calling function? I've done this for logging purposes before, in fact. So even if your caller is super careful not to pass the password in, saving me from accidentally logging it, I can crawl back up the stack and get it anyway.

6. Your database logs

7. Services/ RPCs that sit between your auth API and your database

And as your business grows and your code changes you'll have to track all of that.

Orrrrrrrrr, you can just hash your password on the client side and significantly reduce the damage of a leak. Or put the extra work in to implement OPAQUE. Or use webauthn, that's cool too.

I used to use Basic Auth for small personal/internal services, but these days I prefer a proxy like Traefik/NGINX with a simple authentication service like Authelia or Traefik Forward Auth.

It’s a little more work to setup but not much and there are a bunch of benefits: SSO across multiple services, control over session expiration, works better with password managers, 2FA, etc.

I don’t think he understands salts or really hashing at all and this is messing up the logic in his posts.

I don't know why people are assuming the attacker:

A) Controls the code running the auth API

B) Controls the javascript

As if that's the common attack.

The common attack is that the attacker has a read on the hash, either through injection vulnerabilities or other leaks.

Your attacker, as described, has remote code execution on a server that hosts the auth API and the Javascript in one place. That is a very specific, powerful attacker!

> but I just can't think of a threat model where this makes sense

1. An attacker has CSRF and can trick your code into sending the hash to them. This significantly reduces the harm of that attack.

2. An attacker has an injection vulnerability giving them read access to hashes ie: sql injection, perhaps the most significant and relevant attack to discuss with passwords.

3. An attacker takes advantage of a timing attack, bruteforcing the server and measuring response times to leak its value. They can now only leak the hashed value, which is going to take way longer to leak and doesn't expose their password.

And more!

This defense tackles what are very very arguably the major threats to consider with regards to password security (they're the big ones in OWASP top 10).

> It can make stealing passwords more difficult for criminals if every website uses their own bespoke password processing script, but that'll also add a huge attack surface to your code and it'll be a burden to maintain.

You can significantly reduce harm and attack surface with all of 3 lines in your frontend code.

    salt = hash(username + static_salt)
    password_hash = pbkdf2(plaintext_password, salt)

it's trivial to implement this.

I'll grant you that PAKEs may be more complex to implement today, but even if we talk about a very basic implementation of client side hashing I think there's obvious value.