6 ms·

>... why they’re not hashing passwords inside of their database? Sending passwords plaintext over the wire isn't good either, even with TLS. You don't want you

• eat_veggies 6y ago
  What's the threat model you have in mind for salting and hashing on the client? TLS is quite strong, and if your adversary has broken your TLS then they can also intercept cookies or inject code to capture the plain text.
  • thaumasiotes 6y ago
    The only threat model this would actually address is a threat from the user himself. Hashing on the client side means the user probably doesn't know his own password. But he still knows how to log in, so the password he accidentally discloses to someone else is trivially convertible to his actual password. (The threat model has to involve an accident, because if the user wants to know his password, he can just look at it when he logs in.) The strategy is called "passing the hash", and it will be flagged as a low-priority problem if you get a security review. It doesn't introduce a weakness, but it's a sign that you don't know what you're doing. (The more classical form is that you _only_ do the hashing on the client side, in which case you've also introduced the issue that your database stores everyone's password in plaintext.)
    • rl3 6y ago
      >The only threat model this would actually address is a threat from the user himself. Incorrect. Please refer to other comments in reply to you.[0][1] >It doesn't introduce a weakness, but it's a sign that you don't know what you're doing. How's the old proverb go? "Those who live in glass houses should not throw stones" [0] https://news.ycombinator.com/item?id=24026585 https://news.ycombinator.com/item?id=24026585 [1] https://news.ycombinator.com/item?id=24026954 https://news.ycombinator.com/item?id=24026954
  • riffraff 6y ago
    I doubt this is a serious issue, but it could protect the original password from accidentally being logged on the server, which has happened to respectable organizations. Connected with password reuse across different websites, this could present a problem for the end user.
  • rl3 6y ago
    >What's the threat model you have in mind for salting and hashing on the client? If your server is compromised, you don't want it handling plaintext/raw password input from your users.
    • thaumasiotes 6y ago
      > If your server is compromised, you don't want it handling plaintext/raw password input from your users. This doesn't work; see the other line of the comment you're responding to: >> if your adversary has broken your TLS then they can also intercept cookies or inject code to capture the plain text You're assuming that the attacker controls the connection with the user. Such an attacker is free to serve a login page that sends the unhashed password, and read that.
      • rl3 6y ago
        >You're assuming that the attacker controls the connection with the user. I am making no such assumptions. >Such an attacker is free to serve a login page that sends the unhashed password, and read that. Depending on the nature of the server exploit, and depending on if the client code is even delivered via the same server handling requests in the first place. Both are quite large assumption to make.
  • munchbunny 6y ago
    if your adversary has broken your TLS then they can also intercept cookies or inject code to capture the plain text. Pretty much this. If you’re stealing a password in transit, you can just steal the auth token instead, and that attack would bypass MFA. If you compromise the server, you’re well past caring about the individual passwords anyway because you can just serve a version of the client code that doesn’t hash on the client side. If you’re phishing the user, it doesn’t matter what the client normally does because the fake login probably isn’t going through your code. If you’re trying to safeguard against CSRF or a related attack, again either the client code got injected or they’re just using your auth token and don’t care about your password You could salt and hash again on the server side, but its benefits are marginal. But if you don’t salt and hash on the server side, because you did it on the client side, then you have a known vulnerability (“pass the hash”).
    • rl3 6y ago
      >If you compromise the server, you’re well past caring about the individual passwords anyway because you can just serve a version of the client code that doesn’t hash on the client side. What if the client files are delivered via CDN, and the server in this case is an API?
      • munchbunny 6y ago
        At the point where I’m on your front end server, I’m not stealing your password, I’m stealing your auth token. I don’t care much about your password once I can harvest auth tokens en masse. Don’t forget about the main point: hashing and salting on the client side does not replace doing the same thing on the server side.
        • rl3 6y ago
          >Don’t forget about the main point: hashing and salting on the client side does not replace doing the same thing on the server side. Per my original, top-level comment: "For that reason, it's a good idea to salt and hash passwords client-side as well." [emphasis.. nevermind.]
• thaumasiotes 6y ago
  > Sending passwords plaintext over the wire isn't good either, even with TLS. You don't want your server to have any knowledge of the plaintext password. This is literally impossible to avoid. Whatever the server receives, that's what the password is.
  • ilammy 6y ago
    This is literally untrue. Zero-knowledge comparison protocols exist [1], and their goal is to prevent malicious party from obtaining any knowledge of the secret. Yes, the genuine server will have its copy of the password (or its hash, whatever) and the user will have their copy of the password too. What you don't want is to have the user send their copy of the password to a place which looks like your server but isn't. [1]: https://www.cossacklabs.com/files/secure-comparator-paper-rev12.pdf https://www.cossacklabs.com/files/secure-comparator-paper-re... EDIT: I mean, yeah, you're right in the sense that whatever you send to the server is used to authenticate you, so that whatever is a 'password' of a sort by definition. However, using the raw password as is for authentication is not a great idea. If you intercept the password, you will be able to compromise any further authentications. There are alternatives that avoid this.
    • DarthGhandi 6y ago
      Another alternative is a PAKE. You'll never have a password sent over the wire. For some reason PAKE schemes aren't that commonly used despite having a solid grounding. Matthew Green has a few good articles on them.
      • thaumasiotes 6y ago
        > You'll never have a password sent over the wire. As far as I can see, you do need to send the full password over the wire once when you set its value. But the server doesn't need to remember it. > For some reason PAKE schemes aren't that commonly used despite having a solid grounding. It doesn't look like something you can implement unilaterally. How's browser support? (Interestingly, I guess you could implement it unilaterally between your server and client-side javascript...)
• runeb 6y ago
  How are you supposed to salt in plain view?
  • alexis2b 6y ago
    It does not really matters, the purpose of salting is to avoid rainbow table attacks (i.e. comparing against precomputed dictionaries of known hashes). (Edit: typo)
    • runeb 6y ago
      If you know the salt you also have a way of generating an updated table that matches the salted hashes.
      • BenjiWiebe 6y ago
        That's why the salt is randomly generated per-password, and stored in plaintext beside the (hashed) password.