Is this implemented by Facebook holding 3 hashes of your password? It doesn’t save your actual password clear text (or encrypted clear text), does it?
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?
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.
You can also normalize the password, e.g. always make the first letter lowercase and reverse the case of the rest if the second letter is uppercase. Then you only have to hash that.
I hope Facebook passwords are limited to US ASCII, because I seem to remember that there are country specific conversion rules for various Unicode characters that may or may not be subject to change, not to mention the lack of 1:1 mapping for case conversions. Example the German lower case ß converts to SS, so does ss. Of course they also created an upper case variant ẞ of ß a few years ago so who knows what mapping any software will use.
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.
Small addition since I completely forgot it: Since here the attempt is to fix caps lock issues the upper case of ß also depends on the users keyboard layout, for my keyboard ß would map to ?. Does anyone even have a list of all the keys that map to ? in different keyboard layouts?
Correct me if I am wrong but this doesn't seem to allow case conversion:
> 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).
That only works if they have the same insensitivities across time and platforms. In this case, they still need to preserve the original information, because they're case sensitive on that first transformation for non-mobile devices.
No, it's only one bit for the first character and one for the second. The case of every other character is maintained relative to the second character, so the parity there provides the one bit of information for each subsequent alphabetic character.
why would you have to retrieve multiple? could you not calculate the 3 hashes, and then do SELECT WHERE pass = HASH1 OR pass = HASH2 OR pass = HASH3? You don't care which one was correct just that one is.
By retrieving three you can perform an if on one value; if that fails check the other two values. This allows you to save the other two calls for most logins.
You can push the comparison into sql but you still have a series of retrievals and comparisons. Just because it happens in sql doesn’t mean the processes don’t have to happen. In your example you have calculated three hashes, then pushed them to the sql server where the retrieval and comparison occurs.
Passwords are only verified on login. Does it seems reasonable that there are millions of logins to Gmail from mobile devices every second?
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.
Instead of just telling the parent that they're doing something can wrong in a condescending way, can you explain what it is they should do differently? At least a link to an article that explains this?
good lord, why would you ever expect psuedo code to be my level of understanding of how to store a password. i don't ever store passwords. hashes only.
Because the pseudo code looks quite bad? The clause should pick the user not the password or hash or anything like it. The hash (and possibly salt etc) should come back via the selected column list. The other way round is inviting trouble and could indicate a poor understanding, though I agree they shouldn't be so snarky without some explanation.
Unless it has been edited since i saw it, the pseudo sql doesn’t select anything, a logical assumption is user identity and not needed. The comparison is between the original hashed password and the hashes made at auth-time. 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.
Maybe these generous assumptions about someone’s pseudo code are unwarranted?
Jeebus, it's just meant to show that you could do a select in one go without having to do them one at a time cascading to the next one if no match. I don't know what you need to select, that's up to the reader. That's the point of psuedo code. You saw select and made the connection to "it's a database query". Boom. point made. Again, I understand the concept of user provided pass and a hash with a salt. If you can't really put 2+2 together to see that you're taking the 3 different options then I'm sorry for you.
Look, whatever it’s meant to show, it also looks like a security nightmare that implies a lack of understanding. Are we supposed to ignore that because it’s pseudo code? Clearly some of us think not.
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.
You have to calculate at least one hash and you only have to perform one query (as it can grab multiple hashes at once), and that query should not choose what to return based on the content of the hash(es).
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).
> The comparison is between the original hashed password and the hashes made at auth-time.
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?
You can't compare hashes like that unless they're not salted.
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.
More importantly if the server just accepts hashed passwords and stores them, then if you got ahold of a hashed password through a leak you could just use it directly to authenticate by modifying the client. The hashed password just becomes the password with one extra client-side step that you can trivially skip.
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.
The server could hash again the hashed password sent by the client. Especially if the client use an insecure hash algorithm (no secret salt for example).
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)
The various ZKP approaches are considerably more complex to implement properly vs the trivial approach of a client side hash. There are obvious tradeoffs, of course, but I wouldn't fault someone for an additional hash step on the client.
Hashing on the client still seems redundant though. In the end, whatever value is sent to the server is essentially plaintext, because it's all an attacker needs to know to authenticate. Whether it's the raw text the user typed or some transformed version of it isn't really relevant.
In a world where password reuse is rampant, whether it's the raw text the user typed or a hard-to-reverse transformation on it is absolutely relevant to the user, just not to the service provider.
Double-hashing (peppered on client, salted on server) does have a modest benefit: the passwords are no longer sent in plain-text and cannot be cheaply intercepted by a passive eavesdropper (i.e. without observably tinkering with the data sent).
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.
When you change your password, you're usually required to enter both the old and the new one. This is when the check is usually performed.
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.
Hopefully the bank stores a separate hash for each mask, generated at the time of password creation. Otherwise, it’s hard for me to imagine how this would be possible without saving the password in clear text.
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...
Is this still the case? When living in Poland 15 years ago I had an account with WBK and they had this idiotic system where I had to write my password on a piece of paper with numbers below to be able to give the 3rd, 5th and 11th character. Goodbye password managers (at least the automatization part).
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.
Note that the client would only need to do this on a failed attempt.
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.
It would only half the rate limit, but any real brute force attempt requires way way more than what a normal human would try. Something like 5 attempts would double to 10 in the backend, still nowhere enough to bruteforce, but enough for human trial and error.
To your related question, on the rare systems where I’ve had to do that, I’ve always (to the limit of my memory) had to submit “old password” “new password” “new password again”, so the old password would be available in plaintext client side (and still able to be verified server side after hashing).
I’m sure it’s client side and it just retries the different ways if it encounters a password error. Much easier and more secure than 3 versions of the password.
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?