3 ms·

Sorry, but the idea that implementing "clean logs" is: a) Tractable b) Simple or straightforward compared to client side hashing is absurd. Client side hash

Sorry, but the idea that implementing "clean logs" is: a) Tractable b) Simple or straightforward compared to client side hashing is absurd. Client side hashing is a one time solution forever that exists in one place, requiring no 'cooperation' from other code to be safe. "Cleaning logs", which you still haven't defined at all, is going to be a constant maintenance burden that can break in any place where you log ie: absolutely fucking everywhere by absolutely fucking everyone.

gjsman-1000 5y ago
How complex and unusual is the authentication system you are working on? If it was a consumer-facing web app, it's not like your password is logged in a million different places. It's possibly logged by your web server software (nginx in my case), and it's possibly logged by your web app framework's requests handler. It's not terribly hard to ensure that these points where the password passes through do not have passwords in their logs, or to ensure that said passwords are not logged to begin with. If it was a massive enterprise system, 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. And then, just ensure that said passwords are not stored in logs. 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? And yes, maybe client-side hashing does resolve some attacks, but I remain convinced that it is overkill and less protective than it initially seems. And in the future we would move to Zero-Knowledge Proofs but we aren't there yet for general users.
- staticassertion 5y ago
  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.
  - huntertwo 5y ago
    If the hash is used to authenticate, how is leaking the hash less bad than leaking the password? If I have the hash I can already impersonate you.
    - staticassertion 5y ago
      There are like a dozen other posts where I answer this question so I'd recommend just going to my comment history.
    - PuercoPop 5y ago
      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.
    - gsich 5y ago
      Because pass the hash only works for the current server. People reuse passwords, so without brute-forcing you are out of luck.
    - Too 5y ago
      The hash is not constant. 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.
      - staticassertion 5y ago
        Yeah, once you get to the ZKP approach, which is what you're describing, the benefits are more significant.
      - u801e 5y ago
        > With public key crypto you can implement a challenge response. Or just use a client side TLS certificate to authenticate instead of or in addition to the username and password.
gitgrump 5y ago
peanut-walrus 5y ago
And how exactly would having the hash in the log versus having the password in the log be an improvement? If someone gets that hash it's exactly the same as having the password, as it is the hash that gets sent to your server in the http request. Edit: alright, I saw that you mentioned password reuse in another reply, fair enough, it does help against that.
- lolc 5y ago
  Proper client-side hashing uses a nonce generated by the server. The transmitted hash is only valid in that session. Even if the nonce and the hashed product are logged, you can't reuse it, because the nonce will be different for your login attempt.

gjsman-1000 5y ago

How complex and unusual is the authentication system you are working on? If it was a consumer-facing web app, it's not like your password is logged in a million different places. It's possibly logged by your web server software (nginx in my case), and it's possibly logged by your web app framework's requests handler. It's not terribly hard to ensure that these points where the password passes through do not have passwords in their logs, or to ensure that said passwords are not logged to begin with. If it was a massive enterprise system, 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. And then, just ensure that said passwords are not stored in logs. 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? And yes, maybe client-side hashing does resolve some attacks, but I remain convinced that it is overkill and less protective than it initially seems. And in the future we would move to Zero-Knowledge Proofs but we aren't there yet for general users.

staticassertion 5y ago
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.
- huntertwo 5y ago
  If the hash is used to authenticate, how is leaking the hash less bad than leaking the password? If I have the hash I can already impersonate you.
  - staticassertion 5y ago
    There are like a dozen other posts where I answer this question so I'd recommend just going to my comment history.
  - PuercoPop 5y ago
    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.
  - gsich 5y ago
    Because pass the hash only works for the current server. People reuse passwords, so without brute-forcing you are out of luck.
  - Too 5y ago
    The hash is not constant. 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.
    - staticassertion 5y ago
      Yeah, once you get to the ZKP approach, which is what you're describing, the benefits are more significant.
    - u801e 5y ago
      > With public key crypto you can implement a challenge response. Or just use a client side TLS certificate to authenticate instead of or in addition to the username and password.

gitgrump 5y ago

peanut-walrus 5y ago

And how exactly would having the hash in the log versus having the password in the log be an improvement? If someone gets that hash it's exactly the same as having the password, as it is the hash that gets sent to your server in the http request. Edit: alright, I saw that you mentioned password reuse in another reply, fair enough, it does help against that.

lolc 5y ago
Proper client-side hashing uses a nonce generated by the server. The transmitted hash is only valid in that session. Even if the nonce and the hashed product are logged, you can't reuse it, because the nonce will be different for your login attempt.