10 ms·

No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows th

No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.m.wikipedia.org/wiki/Password-authenticated_key_a...

thrashh 5y ago
But most login forms don’t do that anyway so it wouldn’t be any worse than how things are already done.
gjsman-1000 5y ago
> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? 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. It's theoretically more secure... but against what? Accidental logging? I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript. In my opinion, client-side hashing is security theater. It sounds impressive, but it doesn't really stop any real-world attacks, and the attacks it does prevent can be prevented using simpler methods. Ironically, the other methods (i.e. making sure your logs are clean) are so much simpler to implement it's probably more secure than trying to build a secure client-hashing implementation in the first place.
- almost 5y ago
  Credential stuffing is a thing. So it’s pretty good if a compromised website just cannot leak your password. But as the other comment pointed out the current situation with web form login is that password is sent to server so it wouldn’t be worse than the the status quo.
  - gjsman-1000 5y ago
    I hope you are kidding. A compromised website that was well designed should not leak your password any more than a client-side hashing implementation. This is because the passwords are hashed in the database. Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that. And credential stuffing? Client-side hashing does absolutely nothing to prevent credential stuffing other than that you may need a GPU to do a lot of hashes quickly. Client-side hashing doesn't make a server handle more or less authentication requests.
    - masklinn 5y ago
      > A compromised website that was well designed Ah yes, "if nobody makes any mistake there's no problem", that's worked so well forever hasn't it? > Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that. That makes quite literally no sense, did you miss the entire thing and go off with whatever? The request here is to make the browser's support for HTTP authentication better. The entire point is that there is no "quick code edit" without owning the entire browser at which point you're quite thoroughly owned anyway.
      - garbagecoder 5y ago
        I don’t think he understands salts or really hashing at all and this is messing up the logic in his posts.
    - garbagecoder 5y ago
      If “should” were a word that meant what people thinks it means, we wouldn’t need security at all.
- weaksauce 5y ago
  I could be missing something but they are not suggesting to use a javascript version but the version where the zero knowledge algorithm is used at the browser level. the password would never be outside the secure context of the browser and nothing other than the algorithm bits would be sent.
  - masklinn 5y ago
    You're not missing anything, GP is.
- fivelessminutes 5y ago
  If someone gets a copy of the encrypted traffic - and we know that 'full take' is being done routinely for some parts of the internet - the credential in the plaintext means that if they are ever able to decrypt it even weeks later, they can make fresh connections using the valid credential afterwards. If the server issues a different challenge each time, decrypting one response doesn't buy you anything.
  - gjsman-1000 5y ago
    I guess this makes sense - but who is capable of decrypting it weeks later unless the original private key was stolen, in which case it could be decrypted almost in real-time? Maybe if you were concerned a nation-state or something was trying to get your private key, but you've got bigger fish to fry at that point.
    - w3ll_w3ll_w3ll 5y ago
      Also, using TLS with Perfect Forward Secrecy (all modern ciphers), it's not possible to just capture the traffic and dectypt it later. You have to know the private key and do MITM.
      - rixed 5y ago
        > You have to know the private key and do MITM. Which can safely be assumed to happen whenever the equipment is provided by another party such as an employer. All in the name of security, just not that of the user.
- throw0101a 5y ago
  > 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. If a zero knowledge (ZK) system combined with HTTP Basic was used, then account entry would come from the browser itself and not a web form that could be intercepted by JavaScript. Further, a ZK system would help with the silliness of folks using bad algorithms (straight MD-5 / SHA-1) to store passwords, or even storing them in plain-text.
  - gjsman-1000 5y ago
    Right - it would, I don't disagree, it'd be awesome. It's something like WebAuthn. I'm arguing here more against some people who think that using a JavaScript-based system to hash the password entry before sending it to the server is a good idea.
    - masklinn 5y ago
      > I'm arguing here more against some people who think that using a JavaScript-based system to hash the password entry before sending it to the server is a good idea. So you're arguing against something nobody is arguing for?
    - madacol 5y ago
      So you are strawmanning?
- oconnore 5y ago
  - If you share your password across sites that used a hypothetical browser-implemented PAKE, site A cannot login to your account on site-B - If a site is attacked, there is no risk that password material was extracted from application memory — site operator can dump session tokens and safely re-auth users.
  - gjsman-1000 5y ago
    This sounds like an interesting system, but I think you are arguing for a system that as-of-now is only theoretical and is very different against the current crop of JavaScript-powered client-side-hashing methods which I am arguing against.
    - staticassertion 5y ago
      PAKE isn't theoretical at all and the post you're responding to didn't say client side hashing it said zero knowledge proofs.
      - gjsman-1000 5y ago
        PAKE is theoretical from a web-development perspective because there is no secure way for me to implement PAKE in my web app for a user to log in with in 2022. It doesn't exist - you tell me how to implement PAKE login right now. Zero Knowledge Proofs would be awesome (something like WebAuthn/FIDO right now?) but I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones.
        staticassertion 5y ago
        Not sure what you mean. 1. There is, of course, a way to implement it in your web app. I don't know what you mean by "no secure way" ? > I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones. Even a trivially implemented client side hashing approach protects against a number of attacks.
- na85 5y ago
  >Yes - it does - but I am having a hard time thinking that this actually matters in the real world. In the 90s and early aughts it was fashionable for php sites to store passwords hashed, usually some combination of a salt with md5 and later the SHA variants. For a brief few years there were entire communities on IRC and elsewhere dedicated to making rainbow tables for cracking stolen password hashes. Often the salt would be common across all passwords, so if you got a database dump it was a gold mine for credentials.
  - gjsman-1000 5y ago
    Right - but that's been resolved, PHP and others now store the unique salt used with the password together, so every password has its own salt. That didn't need client-side hashing to fix it.
    - garbagecoder 5y ago
      Gee, it’s almost like on the internet there are computers between you and the destination.
  - staticassertion 5y ago
    A trivial fix here is to: a) Add a static value to the salt ie: your company's name b) Add the user's email address to the salt The "right" way would be a zero knowledge proof.
    - na85 5y ago
      Yeah well PHPnuke wasn't exactly written by secure coding experts.
  - Too 5y ago
    bcrypt solves that in two ways. It uses per password unique salts and it has a tunable cost-parameter to deliberately slow down the computation, making it slow and infeasible to build a rainbow table.
- staticassertion 5y ago
  > 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.
- garbagecoder 5y ago
  Is this a parody of a webdev?
- marcosdumay 5y ago
  Zero knowledge proofs protect against the password leaking due to any kind of error from the server. That's not security theater, passwords leak all the time. And the nice thing is that browsers already implement that, no need for Javascript. The bad news is that the UX sucks so much that you just can not use, so it's as useful as it not being there. But digest password authentication protects against nearly none of those errors. On this case, leaking a digest is just as bad as leaking a password.
  - throwaway81523 5y ago
    > Zero knowledge proofs protect against the password leaking due to any kind of error from the server. That's not security theater, passwords leak all the time. That's a little confused. PAKE usually still stores a password or hashed password on the server, with the password potentially recoverable by brute force reversing the hash. What it avoids is transmitting a hash over the wire that can be reversed into a password, the way HTTP digest auth allows. The stuff transmitted over the wire by PAKE instead reveals no info about the password. Most login pages on web sites today send the cleartext password underneath the https encryption layer, so the server sees the password (though hopefully stores it in only in hashed or MAC'd form). That is equivalent to http basic auth sent through https. I use basic auth + https for my own stuff (where I don't care about styling) and it suffices for most things. Obviously you can escalate from there to 2fa, client certificates with credentials wrapped in hardware tokens, or whatever. I haven't needed that for personal stuff so far.
    - unscaled 5y ago
      Most PAKE implementations actually make a security trade-off here - they protect the password transmitted over the wire, but you end up with a weaker password hash stored in the server's database. Modern PAKE implementations, like SRP, don't store the plaintext password on the server side, but rather store a "verifier", which is essentially a hashed and salted version of the password. This way the server never sees the actual password, even at the registration phase. The problem is with the hashing function though. For instance, all the SRP implementations I've seen use fast hash functions like SHA-1, SHA-256 or Blake2b by default. But contrary to folk wisdom (which is unfortunately often repeated here as well), hashing and salting a password is not enough. This is not 2003 anymore, and rainbow tables are not your main threat - your main threat is a cluster of fast GPUs demolishing your hashed passwords at rates that often just start at 1 GH/s. The best practice nowadays is to use a function which is both computationally expensive and memory-hard such as scrypt or the newer Argon2 (and not PBKDF2!). You could very well do that with a PAKE, but now you run across a nasty UX trade-off: the computationally expensive function would have to be executed on the client side every time the client authenticates. There are WASM implementations of Argon2 out there, so this is probably not a big issue on a beefy PC, but you'll have to aim for the lowest common denominator here, and tune your function for a low-end smartphone. tl;dr: In practice, with a carefully implemented PAKE, you'll give the attacker a 10-100 times faster hashrate than you would with a plain-text password authentication approach implemented with the same amount of care. In real practice, you'll probably use whatever defaults your library gives you and give often end up with a ridiculously weak hash. Now, I said this is a trade-off. If you implement PAKE well, you will reduce the resiliency of your stored password hashes against brute force attacks, but this is what you get in return: * Protection against password sniffing at TLS-terminating proxies * Protection against hackers taking over your server and stealing user passwords as they login (Online password leak) * Protection against MITM with a stolen CA key[1] All of these things are still an issue with clear-text passwords even if you're using TLS. If any of these issues are a concern for you, this means you consider your users' passwords to be significantly more sensitive than the data that flows between your clients and servers, but that could be a valid threat model. In this case PAKE looks like a nice solution. For everything else, I don't recommend PAKE. It is harder to implement correctly (with library defaults being insecure as I mentioned above), and this is more important than whatever theoretical strengths it has. Cryptographic systems are generally broken because of incorrect implementation rather than theoretical weaknesses in the algorithm. [1] Not very common, but that did happen in the past: https://en.wikipedia.org/wiki/DigiNotar https://en.wikipedia.org/wiki/DigiNotar
- lordlimecat 5y ago
  Scenario 1: Attacker compromises ECOMMERCE_SITE where you have a login. The ECOMMERCE_SITE uses md5 for logins, so the attacker just brute-forces the hash and then uses that password to compromise your logins on other sites. Scenario 2: The ecommerce site has upgraded to SHA512, so cracking isnt an option. But the site is relying on basic auth, so the attacker simply sniffs your password when you auth. Scenario 3: the ecommerce site is using a secure zero-knowledge auth against a hashed/salted/peppered/whatever credential. They cannot brute force it, and the server never sees your password. They can mess around with the ECOMMERCE_SITE but cannot pivot to any of your other logins. >If I was a hacker, I can add JavaScript to send plaintext somewhere. We've just shifted from "quiet, persistent threat" to "hacker announces to the world that he's in". Changing javascript on a prod website is going to trigger alarms.
  - BeefWellington 5y ago
    > We've just shifted from "quiet, persistent threat" to "hacker announces to the world that he's in". Changing javascript on a prod website is going to trigger alarms. While I'd like that to be true, it really isn't. There have been loads of card skimming operations injected into production sites which weren't noticed for sometimes months.[0][1][2][3] [0]: https://blog.malwarebytes.com/hacking-2/2020/03/criminals-hack-tupperware-website-with-credit-card-skimmer/ https://blog.malwarebytes.com/hacking-2/2020/03/criminals-ha... [1]: https://www.wired.com/story/british-airways-hack-details/ https://www.wired.com/story/british-airways-hack-details/ [2]: https://www.riskiq.com/blog/external-threat-management/magecart-ticketmaster-breach/ https://www.riskiq.com/blog/external-threat-management/magec... [3]: https://sansec.io/research/svg-malware https://sansec.io/research/svg-malware
- amluto 5y ago
  PAKE is highly phishing resistant. If you type your password for an important website into a browser-controlled PAKE UI, but you’re being phished and the browser tries to authenticate to a malicious website, the worst the website can do is guess one single password. It can’t relay the password to the real website.
  - Thorrez 5y ago
    Good point that it protects against a phishing site that exactly replicates the victim site but with a different URL. But the phishers could do a slight variation. They could create a website that looks very similar to the browser's Basic Auth popup, but implemented in HTML and Javascript. Most people won't notice the difference. Most people don't understand the line of death[1]. [1] https://textslashplain.com/2017/01/14/the-line-of-death/ https://textslashplain.com/2017/01/14/the-line-of-death/
    - eru 5y ago
      You could make the line of death better. In the context of the pop-up: a simple pop up can be faked. But what if the browser would flash all the borders (and other stuff outside the line of death) when the real popup is displayed? I'm not saying any of this is 100% foolproof, just that we should be doing some UI experiments on real people to see what works better.
      - thesz 5y ago
        This is what was done in the EROS [1] (extremely reliable operating system) UIs - it was not possible for user window to be rendered completely undistinguishable from system windows like, you knew it, a password prompt. [1] https://en.wikipedia.org/wiki/EROS_(microkernel) https://en.wikipedia.org/wiki/EROS_(microkernel) EROS used capabilities to enforce such rules. If you lack a capability to be a system window, you can't pretend to be one.
        amluto 5y ago
        This is also what a secure attention key is for. Sadly the well known implementation (Windows NT) made it sufficiently obnoxious that it went away. I can imagine keyboards having a special “password” key and trying to train people that all passwords start with the password key. I don’t know if this would work, but it can’t be worse than Ctrl-alt-delete.
- thisoneistheone 5y ago
michaelcampbell 5y ago
> No, it would be much better to use a zero knowledge proof Yes, it would. A further improvement to an improvement doesn't take away from the first improvement. Don't let the perfect be the enemy of the good.
geektips 5y ago
Intresting idea, this kind implementation would have prevented password leak from something like Cloudbleed[0] [0] https://en.m.wikipedia.org/wiki/Cloudbleed https://en.m.wikipedia.org/wiki/Cloudbleed
armchairhacker 5y ago
idk if you even need a zero knowledge proof. Server sends client a salt, client hashes the salt and password and sends back to server. Implement this as a built-in feature of the web browser, and the browser can show a special icon or symbol to mark that the password will be sent hashed (and later show a warning on password fields sent via plaintext).
- xmprt 5y ago
  Could that really work? Sounds like it's highly abusable if someone compromises the database and gets a list of all the hashes. Now, they don't even need to use rainbow tables or any brute force to compute the password. They just send the hash to the server and will be logged in.
  - mikea1 5y ago
    The salt-and-hash combo is how email logins worked for decades. The problem with this approach is that what you really want different salts, which requires that the server knows the plain text password.
  - armchairhacker 5y ago
    Yes, if an attacker compromises the database they can send the direct hash. The point is that a malicious or badly-secured site can't use your password on other websites, because ultimately most people use the same password on many different sites.
- hnick 5y ago
  Then you either have: 1) A different salt each time, meaning the server must know your plaintext password to validate, or 2) The same salt every time, in which case the hash is essentially the password since that's all the attacker has to pass to the server next time.
ibic 5y ago
I don't think this is a major concern here, many websites pass username and password in plain text and rely on https for security (Just take a look at HN's log in form). If I'm not wrong, J2EE's login is implemented using plaint text also for password.
rcxdude 5y ago
Don't such methods require you to store the password in a non-hashed form on the server? That seems mostly worse than this approach, since now the passwords of all users are visible at rest and can be used directly as authentication. RADIUS I know commonly uses this approach and it always made me nervous having the passwords in plaintext.

thrashh 5y ago

But most login forms don’t do that anyway so it wouldn’t be any worse than how things are already done.

gjsman-1000 5y ago

> "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? 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. It's theoretically more secure... but against what? Accidental logging? I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript. In my opinion, client-side hashing is security theater. It sounds impressive, but it doesn't really stop any real-world attacks, and the attacks it does prevent can be prevented using simpler methods. Ironically, the other methods (i.e. making sure your logs are clean) are so much simpler to implement it's probably more secure than trying to build a secure client-hashing implementation in the first place.

almost 5y ago
Credential stuffing is a thing. So it’s pretty good if a compromised website just cannot leak your password. But as the other comment pointed out the current situation with web form login is that password is sent to server so it wouldn’t be worse than the the status quo.
- gjsman-1000 5y ago
  I hope you are kidding. A compromised website that was well designed should not leak your password any more than a client-side hashing implementation. This is because the passwords are hashed in the database. Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that. And credential stuffing? Client-side hashing does absolutely nothing to prevent credential stuffing other than that you may need a GPU to do a lot of hashes quickly. Client-side hashing doesn't make a server handle more or less authentication requests.
  - masklinn 5y ago
    > A compromised website that was well designed Ah yes, "if nobody makes any mistake there's no problem", that's worked so well forever hasn't it? > Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that. That makes quite literally no sense, did you miss the entire thing and go off with whatever? The request here is to make the browser's support for HTTP authentication better. The entire point is that there is no "quick code edit" without owning the entire browser at which point you're quite thoroughly owned anyway.
    - garbagecoder 5y ago
      I don’t think he understands salts or really hashing at all and this is messing up the logic in his posts.
  - garbagecoder 5y ago
    If “should” were a word that meant what people thinks it means, we wouldn’t need security at all.
weaksauce 5y ago
I could be missing something but they are not suggesting to use a javascript version but the version where the zero knowledge algorithm is used at the browser level. the password would never be outside the secure context of the browser and nothing other than the algorithm bits would be sent.
- masklinn 5y ago
  You're not missing anything, GP is.
fivelessminutes 5y ago
If someone gets a copy of the encrypted traffic - and we know that 'full take' is being done routinely for some parts of the internet - the credential in the plaintext means that if they are ever able to decrypt it even weeks later, they can make fresh connections using the valid credential afterwards. If the server issues a different challenge each time, decrypting one response doesn't buy you anything.
- gjsman-1000 5y ago
  I guess this makes sense - but who is capable of decrypting it weeks later unless the original private key was stolen, in which case it could be decrypted almost in real-time? Maybe if you were concerned a nation-state or something was trying to get your private key, but you've got bigger fish to fry at that point.
  - w3ll_w3ll_w3ll 5y ago
    Also, using TLS with Perfect Forward Secrecy (all modern ciphers), it's not possible to just capture the traffic and dectypt it later. You have to know the private key and do MITM.
    - rixed 5y ago
      > You have to know the private key and do MITM. Which can safely be assumed to happen whenever the equipment is provided by another party such as an employer. All in the name of security, just not that of the user.
throw0101a 5y ago
> 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. If a zero knowledge (ZK) system combined with HTTP Basic was used, then account entry would come from the browser itself and not a web form that could be intercepted by JavaScript. Further, a ZK system would help with the silliness of folks using bad algorithms (straight MD-5 / SHA-1) to store passwords, or even storing them in plain-text.
- gjsman-1000 5y ago
  Right - it would, I don't disagree, it'd be awesome. It's something like WebAuthn. I'm arguing here more against some people who think that using a JavaScript-based system to hash the password entry before sending it to the server is a good idea.
  - masklinn 5y ago
    > I'm arguing here more against some people who think that using a JavaScript-based system to hash the password entry before sending it to the server is a good idea. So you're arguing against something nobody is arguing for?
  - madacol 5y ago
    So you are strawmanning?
oconnore 5y ago
- If you share your password across sites that used a hypothetical browser-implemented PAKE, site A cannot login to your account on site-B - If a site is attacked, there is no risk that password material was extracted from application memory — site operator can dump session tokens and safely re-auth users.
- gjsman-1000 5y ago
  This sounds like an interesting system, but I think you are arguing for a system that as-of-now is only theoretical and is very different against the current crop of JavaScript-powered client-side-hashing methods which I am arguing against.
  - staticassertion 5y ago
    PAKE isn't theoretical at all and the post you're responding to didn't say client side hashing it said zero knowledge proofs.
    - gjsman-1000 5y ago
      PAKE is theoretical from a web-development perspective because there is no secure way for me to implement PAKE in my web app for a user to log in with in 2022. It doesn't exist - you tell me how to implement PAKE login right now. Zero Knowledge Proofs would be awesome (something like WebAuthn/FIDO right now?) but I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones.
      - staticassertion 5y ago
        Not sure what you mean. 1. There is, of course, a way to implement it in your web app. I don't know what you mean by "no secure way" ? > I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones. Even a trivially implemented client side hashing approach protects against a number of attacks.
na85 5y ago
>Yes - it does - but I am having a hard time thinking that this actually matters in the real world. In the 90s and early aughts it was fashionable for php sites to store passwords hashed, usually some combination of a salt with md5 and later the SHA variants. For a brief few years there were entire communities on IRC and elsewhere dedicated to making rainbow tables for cracking stolen password hashes. Often the salt would be common across all passwords, so if you got a database dump it was a gold mine for credentials.
- gjsman-1000 5y ago
  Right - but that's been resolved, PHP and others now store the unique salt used with the password together, so every password has its own salt. That didn't need client-side hashing to fix it.
  - garbagecoder 5y ago
    Gee, it’s almost like on the internet there are computers between you and the destination.
- staticassertion 5y ago
  A trivial fix here is to: a) Add a static value to the salt ie: your company's name b) Add the user's email address to the salt The "right" way would be a zero knowledge proof.
  - na85 5y ago
    Yeah well PHPnuke wasn't exactly written by secure coding experts.
- Too 5y ago
  bcrypt solves that in two ways. It uses per password unique salts and it has a tunable cost-parameter to deliberately slow down the computation, making it slow and infeasible to build a rainbow table.
staticassertion 5y ago
> 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.
garbagecoder 5y ago
Is this a parody of a webdev?
marcosdumay 5y ago
Zero knowledge proofs protect against the password leaking due to any kind of error from the server. That's not security theater, passwords leak all the time. And the nice thing is that browsers already implement that, no need for Javascript. The bad news is that the UX sucks so much that you just can not use, so it's as useful as it not being there. But digest password authentication protects against nearly none of those errors. On this case, leaking a digest is just as bad as leaking a password.
- throwaway81523 5y ago
  > Zero knowledge proofs protect against the password leaking due to any kind of error from the server. That's not security theater, passwords leak all the time. That's a little confused. PAKE usually still stores a password or hashed password on the server, with the password potentially recoverable by brute force reversing the hash. What it avoids is transmitting a hash over the wire that can be reversed into a password, the way HTTP digest auth allows. The stuff transmitted over the wire by PAKE instead reveals no info about the password. Most login pages on web sites today send the cleartext password underneath the https encryption layer, so the server sees the password (though hopefully stores it in only in hashed or MAC'd form). That is equivalent to http basic auth sent through https. I use basic auth + https for my own stuff (where I don't care about styling) and it suffices for most things. Obviously you can escalate from there to 2fa, client certificates with credentials wrapped in hardware tokens, or whatever. I haven't needed that for personal stuff so far.
  - unscaled 5y ago
    Most PAKE implementations actually make a security trade-off here - they protect the password transmitted over the wire, but you end up with a weaker password hash stored in the server's database. Modern PAKE implementations, like SRP, don't store the plaintext password on the server side, but rather store a "verifier", which is essentially a hashed and salted version of the password. This way the server never sees the actual password, even at the registration phase. The problem is with the hashing function though. For instance, all the SRP implementations I've seen use fast hash functions like SHA-1, SHA-256 or Blake2b by default. But contrary to folk wisdom (which is unfortunately often repeated here as well), hashing and salting a password is not enough. This is not 2003 anymore, and rainbow tables are not your main threat - your main threat is a cluster of fast GPUs demolishing your hashed passwords at rates that often just start at 1 GH/s. The best practice nowadays is to use a function which is both computationally expensive and memory-hard such as scrypt or the newer Argon2 (and not PBKDF2!). You could very well do that with a PAKE, but now you run across a nasty UX trade-off: the computationally expensive function would have to be executed on the client side every time the client authenticates. There are WASM implementations of Argon2 out there, so this is probably not a big issue on a beefy PC, but you'll have to aim for the lowest common denominator here, and tune your function for a low-end smartphone. tl;dr: In practice, with a carefully implemented PAKE, you'll give the attacker a 10-100 times faster hashrate than you would with a plain-text password authentication approach implemented with the same amount of care. In real practice, you'll probably use whatever defaults your library gives you and give often end up with a ridiculously weak hash. Now, I said this is a trade-off. If you implement PAKE well, you will reduce the resiliency of your stored password hashes against brute force attacks, but this is what you get in return: * Protection against password sniffing at TLS-terminating proxies * Protection against hackers taking over your server and stealing user passwords as they login (Online password leak) * Protection against MITM with a stolen CA key[1] All of these things are still an issue with clear-text passwords even if you're using TLS. If any of these issues are a concern for you, this means you consider your users' passwords to be significantly more sensitive than the data that flows between your clients and servers, but that could be a valid threat model. In this case PAKE looks like a nice solution. For everything else, I don't recommend PAKE. It is harder to implement correctly (with library defaults being insecure as I mentioned above), and this is more important than whatever theoretical strengths it has. Cryptographic systems are generally broken because of incorrect implementation rather than theoretical weaknesses in the algorithm. [1] Not very common, but that did happen in the past: https://en.wikipedia.org/wiki/DigiNotar https://en.wikipedia.org/wiki/DigiNotar
lordlimecat 5y ago
Scenario 1: Attacker compromises ECOMMERCE_SITE where you have a login. The ECOMMERCE_SITE uses md5 for logins, so the attacker just brute-forces the hash and then uses that password to compromise your logins on other sites. Scenario 2: The ecommerce site has upgraded to SHA512, so cracking isnt an option. But the site is relying on basic auth, so the attacker simply sniffs your password when you auth. Scenario 3: the ecommerce site is using a secure zero-knowledge auth against a hashed/salted/peppered/whatever credential. They cannot brute force it, and the server never sees your password. They can mess around with the ECOMMERCE_SITE but cannot pivot to any of your other logins. >If I was a hacker, I can add JavaScript to send plaintext somewhere. We've just shifted from "quiet, persistent threat" to "hacker announces to the world that he's in". Changing javascript on a prod website is going to trigger alarms.
- BeefWellington 5y ago
  > We've just shifted from "quiet, persistent threat" to "hacker announces to the world that he's in". Changing javascript on a prod website is going to trigger alarms. While I'd like that to be true, it really isn't. There have been loads of card skimming operations injected into production sites which weren't noticed for sometimes months.[0][1][2][3] [0]: https://blog.malwarebytes.com/hacking-2/2020/03/criminals-hack-tupperware-website-with-credit-card-skimmer/ https://blog.malwarebytes.com/hacking-2/2020/03/criminals-ha... [1]: https://www.wired.com/story/british-airways-hack-details/ https://www.wired.com/story/british-airways-hack-details/ [2]: https://www.riskiq.com/blog/external-threat-management/magecart-ticketmaster-breach/ https://www.riskiq.com/blog/external-threat-management/magec... [3]: https://sansec.io/research/svg-malware https://sansec.io/research/svg-malware
amluto 5y ago
PAKE is highly phishing resistant. If you type your password for an important website into a browser-controlled PAKE UI, but you’re being phished and the browser tries to authenticate to a malicious website, the worst the website can do is guess one single password. It can’t relay the password to the real website.
- Thorrez 5y ago
  Good point that it protects against a phishing site that exactly replicates the victim site but with a different URL. But the phishers could do a slight variation. They could create a website that looks very similar to the browser's Basic Auth popup, but implemented in HTML and Javascript. Most people won't notice the difference. Most people don't understand the line of death[1]. [1] https://textslashplain.com/2017/01/14/the-line-of-death/ https://textslashplain.com/2017/01/14/the-line-of-death/
  - eru 5y ago
    You could make the line of death better. In the context of the pop-up: a simple pop up can be faked. But what if the browser would flash all the borders (and other stuff outside the line of death) when the real popup is displayed? I'm not saying any of this is 100% foolproof, just that we should be doing some UI experiments on real people to see what works better.
    - thesz 5y ago
      This is what was done in the EROS [1] (extremely reliable operating system) UIs - it was not possible for user window to be rendered completely undistinguishable from system windows like, you knew it, a password prompt. [1] https://en.wikipedia.org/wiki/EROS_(microkernel) https://en.wikipedia.org/wiki/EROS_(microkernel) EROS used capabilities to enforce such rules. If you lack a capability to be a system window, you can't pretend to be one.
      - amluto 5y ago
        This is also what a secure attention key is for. Sadly the well known implementation (Windows NT) made it sufficiently obnoxious that it went away. I can imagine keyboards having a special “password” key and trying to train people that all passwords start with the password key. I don’t know if this would work, but it can’t be worse than Ctrl-alt-delete.
thisoneistheone 5y ago

michaelcampbell 5y ago

> No, it would be much better to use a zero knowledge proof Yes, it would. A further improvement to an improvement doesn't take away from the first improvement. Don't let the perfect be the enemy of the good.

geektips 5y ago

Intresting idea, this kind implementation would have prevented password leak from something like Cloudbleed[0] [0] https://en.m.wikipedia.org/wiki/Cloudbleed https://en.m.wikipedia.org/wiki/Cloudbleed

armchairhacker 5y ago

idk if you even need a zero knowledge proof. Server sends client a salt, client hashes the salt and password and sends back to server. Implement this as a built-in feature of the web browser, and the browser can show a special icon or symbol to mark that the password will be sent hashed (and later show a warning on password fields sent via plaintext).

xmprt 5y ago
Could that really work? Sounds like it's highly abusable if someone compromises the database and gets a list of all the hashes. Now, they don't even need to use rainbow tables or any brute force to compute the password. They just send the hash to the server and will be logged in.
- mikea1 5y ago
  The salt-and-hash combo is how email logins worked for decades. The problem with this approach is that what you really want different salts, which requires that the server knows the plain text password.
- armchairhacker 5y ago
  Yes, if an attacker compromises the database they can send the direct hash. The point is that a malicious or badly-secured site can't use your password on other websites, because ultimately most people use the same password on many different sites.
hnick 5y ago
Then you either have: 1) A different salt each time, meaning the server must know your plaintext password to validate, or 2) The same salt every time, in which case the hash is essentially the password since that's all the attacker has to pass to the server next time.

ibic 5y ago

I don't think this is a major concern here, many websites pass username and password in plain text and rely on https for security (Just take a look at HN's log in form). If I'm not wrong, J2EE's login is implemented using plaint text also for password.

rcxdude 5y ago

Don't such methods require you to store the password in a non-hashed form on the server? That seems mostly worse than this approach, since now the passwords of all users are visible at rest and can be used directly as authentication. RADIUS I know commonly uses this approach and it always made me nervous having the passwords in plaintext.