4 ms·

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 pas

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

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