4 ms·

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 al

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

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.]