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.
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.
With public key crypto you can implement a challenge response. Server generates random garbage, send to client, client signs the garbage using priv key, sends it back as a hash that the server can verify using pub key.
Another version of this is with shared secrets instead of public/private, by replacing the signature with simply HMAC(secret, garbage) and keep rest of flow same as above.
Because many inputs map to that hash (the hashing function is surjective instead of bijective). People re-use passwords all the time. If the hash leaks it will only affect the particular service.
> 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.