<ocdtrekkie>
Basically all they're saying is that passwords aren't salted, so the pre-hashing is mostly useless for security.
<isd>
Does not affect sandstorm fortunately, since we don't use password auth
<ocdtrekkie>
(Sandstorm is presumably unaffected as it does not store passwords.)
<ocdtrekkie>
IMHO I would rather a rudimentary prehash than sending the password plaintext, although they are using TLS outside of that as well.
<ocdtrekkie>
But like... the solution of salting your hash is like 90s era basic stuff. If you are hashing, you probably should be salting.
<ocdtrekkie>
It's cheap and it just adds another stupid thing for an attacker to cope with.
<TimMc>
Not sure I buy the arguments at the scottbrady91 page.
<TimMc>
It's very hazy on the example scenario.
<ocdtrekkie>
I wasn't 100% positive either, tbh
<TimMc>
You'd first want to compare the probabilities that the user's password was in a cleartext breach vs. a SHA1 (etc.) breach.
<TimMc>
That ratio would have a *dramatic* effect on whether any of this makes sense.
<TimMc>
Next, how many of those SHA-1 (etc.) hashes *haven't* been cracked? My sense was that the crack rate is pretty high!
<TimMc>
OK, so let's pretend most or all breaches are SHA1, cracking SHA1'd passwords is annoyingly hard but not impossible, and you're using pre-hashing (on the client). I think another (important, but unstated) assumption here is that your own DB has been leaked. I *think* the claim here is that the attacker will now go through all of your bcrypt hashes and try each SHA1 they've seen elsewhere. Does that sound
<TimMc>
like a correct characterization?
<TimMc>
Under those assumptions, the attacker would have to try about 600,000,000 hashes (assuming Pwned Passwords dataset) against every bcrypt hash, since each of the latter is salted. At maybe 100ms of work per hash, that's 2 years of compute time just to check *each* user's bcrypt.
<TimMc>
Given that in reality people choose pretty crackable passwords, avoiding this attack (in a pre-hashed passwords scenario) gives marginal benefit, and there's a pretty compelling argument to pre-hash on the client side if you don't know if TLS will be in use in real-world deployments.
<TimMc>
(Counter-argument: There's benefit in the server knowing the cleartext password at login or registration time so that it check the Pwned Passwords DB and force a password reset for bad passwords!)
<TimMc>
Uh... happy to weigh in on the thread if that would help. :-P
<ocdtrekkie>
Arguably you could have the client check Pwned Passwords too.
<ocdtrekkie>
It's mostly a safety feature for people who do not know better. If you want to defeat yourself by circumventing it, go ahead, IMHO.
<TimMc>
Hah, true, no reason the client couldn't do it.
<TimMc>
...maybe we should do that at work.
<TimMc>
...nah, easier to do on the server, otherwise we'd have to implement it for the mobile apps as well.
<xet7>
TimMc: I added some comments to issue. It would be excellent if you could weight in to help :D
<xet7>
add some comments there
<xet7>
Most likely sometime there will be some audit of WeKan too