They wouldn't have to store 3 hashes, would they? They could just get the hash of each of those transformations, e.g., reverse case, get hash. If the transformation make the incorrect password into the correct one, it will match the original hash.
HeLLo, heLLo, hEllO, HEllO all normalize to heLLo
Going further to avoid collisions that could happen between words like massen and maßen when upper cased the rule of thumb was to convert ß to SZ when that happened, so getting the correct upper case would have also required a full German dictionary.
TL;DR: Upper/Lower case conversion is complex, avoid it if possible.
> Case Mapping Rule: There is no case mapping rule (because mapping uppercase and titlecase code points to their lowercase equivalents would lead to false accepts and thus to reduced security).
To implement, choice of storing three hashes or computing n * hashes where n < 1, the probability of getting a match before having to try another.
Maybe these generous assumptions about someone’s pseudo code are unwarranted?
Didn't I write that this shouldn't be done via the clause? I haven't edited my comment either so it should still be there and I see it is.
> the pseudo sql doesn’t select anything
It should select the hash(es) and bring them back to the app for comparison.
> The name of the original is “pass” but since it wouldn’t make sense to compare a plaintext string to a hash another logical assumption is that “pass” is a hash.
It doesn't matter whether it's a password or a hash, the form of the SQL statement is going to cause trouble and should be the other way round.
> Maybe these generous assumptions about someone’s pseudo code are unwarranted?
Perhaps you meant to reply to someone else?
Agreed 100%. Calculating three hashes and sending them to sql for comparison—maybe index lookup—seems backward to me.
Which means you are performing 3 hashes, two of which are likely unnecessary and sending all of them to sql for evaluation.
Pseudo code is supposed to strip away details that might distract from fundamentals, yet your pseudo code and subsequent replies suggest that your understanding is contrary to the actual fundamentals of checking a password securely. Start with limiting the set by choosing by user, never by hash.
Jeremy Evans goes over many of the fundamentals[1], including why restriction of the selection is important, and why restriction of access to hashes (i.e. not sending them from the initial machine) are important. In his own framework (Rodauth) he doesn’t even allow selects of the hashes to be returned to app, let alone used as part of the where clause. Note the clause in each of the functions he defines (12:53 and 14:05).
It’s not the select that’s the problem, it’s the clause, so your explanation also seems to imply that misunderstanding on your part is real.
The same password won't hash to the same thing without the same salt so you can't compare them like that.
(If you could, then you would notice multiple users with the same hashes, i.e. the same passwords).
To verify a hash you need to retrieve the user's salt (typically stored with the hash the algorithm in a single string) then re-hash with the same salt.
Given the forum I too would have believed that to a reasonable assumption, but this thread shows it may not have been.
Back of the envelope: 2 million logins per second would mean about 170 billion logins per day. With 7 billion people on the planet, that'd mean about 25 logins per day from each man, woman and child.
EDIT: Oh right, salts.
Salting is more about making it non-obvious which passwords map to which hashes so you can’t easily build tables of hashes for common passwords.
Sending the password to the server in “plain text” is fine over https, it’s a secure channel. Hashing isn’t meant to hide the password on the wire, it’s to prevent anyone with access to the database from learning what the passwords are.
I feel like if the client always hash passwords as soon as it is typed (the javascript never sees the unhashed password), no one would notice. (except some with crazy password rules that would disallow a hash-looking password)
SRP is one such system: https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...
This often isn't considered worth the accessibility and maintenance costs of requiring the user to compute a hash (the threat model isn't exactly hugely concerning, especially to service providers, and is mostly obviated by transport encryption anyway) or the risk that somebody's going to come along and ask why we're hashing twice and rip out the server hash (very bad), but calling that "no benefits" is more or less lies-to-children.