5 ms·

> Accidental logging? Yes, it happens all the time that passwords get logged. > I mean, I guess, but then just set up your logs correctly instead of breaking

> Accidental logging? Yes, it happens all the time that passwords get logged. > I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript. I have no idea what "set up your logs correctly" is supposed to mean but clearly no one's doing it. What is a "clean log" ? > If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I could change the login form to stop hashing them client-side and instead send them over to the server for hashing and inspection. This assumes you have full control over the client page. But that's not necessarily (or often? most people don't serve JS from the same code that serves their auth API) the case. 1. The JS could be loaded from a CDN, not the same service that has access to the password. You may have absolutely no control over the JS on the page. 2. Every point between the browser and the password DB is a point where the password is in cleartext. So a compromise of any of those, including any logging paths, is a compromise of the password. 3. I don't think anyone cares about breaking login for users who don't use JS, nor should they. What's more, ZKP means that if your password database is owned the impact is far less. If you're doing things right for password storage on top of ZKP you can practically make your password db public. Even if we're talking about a basic client side hashing approach you're significantly improving security, but to be clear, the parent poster is talking about ZKPs, which involve more than that.

gjsman-1000 5y ago
> "I have no idea what "set up your logs correctly" is supposed to mean but clearly no one's doing it. What is a "clean log"?" As you admitted, passwords get logged "all the time." So the reasonable solution in most cases would be to ensure all applicable logs were clean and not logging passwords, not over-engineer a JavaScript-powered client-side-hashing algorithm. That's like taking a sledgehammer to a nail.
- staticassertion 5y ago
  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.
- gsich 5y ago
  >As you admitted, passwords get logged "all the time." So the reasonable solution in most cases would be to ensure all applicable logs were clean and not logging passwords, not over-engineer a JavaScript-powered client-side-hashing algorithm. That's like taking a sledgehammer to a nail. Maybe, but as a client I can't verify that this happens. So never sending the cleartext password is the only solution.
5e92cb50239222b 5y ago
> 1. The JS could be loaded from a CDN, not the same service that has access to the password. You may have absolutely no control over the JS on the page. You have full control over it, as long as you don't embed any third-party maps or crap like ads. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

gjsman-1000 5y ago

> "I have no idea what "set up your logs correctly" is supposed to mean but clearly no one's doing it. What is a "clean log"?" As you admitted, passwords get logged "all the time." So the reasonable solution in most cases would be to ensure all applicable logs were clean and not logging passwords, not over-engineer a JavaScript-powered client-side-hashing algorithm. That's like taking a sledgehammer to a nail.

staticassertion 5y ago
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.
gsich 5y ago
>As you admitted, passwords get logged "all the time." So the reasonable solution in most cases would be to ensure all applicable logs were clean and not logging passwords, not over-engineer a JavaScript-powered client-side-hashing algorithm. That's like taking a sledgehammer to a nail. Maybe, but as a client I can't verify that this happens. So never sending the cleartext password is the only solution.

5e92cb50239222b 5y ago

> 1. The JS could be loaded from a CDN, not the same service that has access to the password. You may have absolutely no control over the JS on the page. You have full control over it, as long as you don't embed any third-party maps or crap like ads. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...