A related question: when a password system tells me I need to change my password, and it has to differ by 3 letters from my previous password, is that system storing my password text rather than the hash of the password? Is that safe?
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.
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).
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.
What I'm more worried about is the system that some Polish banks use, called masked passwords over here. With this system, you're only required to enter certain characters of your password, but the set of required characters changes at each login. This exists to make key loggers much less effective. There's apparently some hashing going on (something to do with curves and polynomials), but I couldn't find more details when I last looked.
If someone steals a hash for characters 1-4 they'll be able to brute force it. Only 10000x the cost of a single login. And then if you have the hash for characters 2-5...
Then, suddenly, they got back to a normal login and password (I think I had the choice IIRC) but then I left the country.
Poland is a beautiful country, I lived in Krakow for a few years and it was A-WE-SOME.
So if i typed "Password" on mobile. The client would first send the request as "Password". If that succeeds, then no worries. If it fails, then the client could send a second request by reversing the case of the first letter. In this case, it would send a second request for "password".
At most, it is 2 login requests per password. Many other commenters here are incorrectly stating that 3 requests would be necessary, but this is untrue. A letter can only have 2 possible cases (uppercase or lowercase). So the client sends the originally typed one, and if that fails, then it flips the case of that first letter. That is the only alternative. There is not a third option.
A well-built login form would restrict users after 3-5 login attempts anyway and require a password-reset process. So that is 6-10 client requests to the backend (n * 2). That shouldn't be hitting any sort of rate limit.