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.

HeLLo, heLLo, hEllO, HEllO all normalize to heLLo

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.

Doing this reduces way more the space of characters and reduces security.

It reduces the password strength by at most two bits. For passwords made solely of non letters there is no reduction in password strength.

It's one bit per alphabetic character, isn't it?

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.

Whoops, I didn't notice that the two L's were still capitalized in the normalization example a few comments up.

*and one for the caps lock key

It reduces the space of passwords just as much as having the backend try those same combinations for every query.

I think that’s a likely route. It’s a question of what is more efficient, compute of hash or storage/retrieval and comparison to multiple.

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.

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.

You're now doing up to 3x the work for every login. When servicing millions of requests a second, that cost adds up.

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.

“Up to 3x the work” is very misleading, since the average will be much less than 3.

I would imagine it's sequential: check exact match hash, if it fails check uppercase-initial-hash, etc.

Please never implement a password feature without reading more about how passwords should be stored.

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.

> it's just meant to show that you could do a select in one go without having to do them one at a time

Which means you are performing 3 hashes, two of which are likely unnecessary and sending all of them to sql for evaluation.

What's more costly, sending 3 separate queries or calculating 3 hashes? I honestly don't know.

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

[1] https://www.youtube.com/watch?v=z3HZZHXXo3I

> 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?

Perhaps you meant to reply to someone else?

> It should select the hash(es) and bring them back to the app for comparison.

Agreed 100%. Calculating three hashes and sending them to sql for comparison—maybe index lookup—seems backward to me.

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.

You're really grilling someone for not fetching salts in psuedocode?

It's not about fetching salts, it's about the whole approach; you literally can't approach it that manner.

I guess they had faith that readers would be experienced enough to connect the dots.

Given the forum I too would have believed that to a reasonable assumption, but this thread shows it may not have been.

Oh you mean the client sends 3 hashes and backend validates if just one matches?

Hashing is done on the server. Hashing on the client would defeat the whole purpose.

Why? If you hash on the server, then you have to send the password in plaintext to the server.

EDIT: Oh right, salts.

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.

If you do not want to send them in plain text you can use SCRAM.

Great point, thanks!

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)

There are formalized approaches to keeping the server from knowing the password at any time: https://en.m.wikipedia.org/wiki/Password-authenticated_key_a...

SRP is one such system: https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...

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.

The client usually doesn't send hashes of passwords. Has he's are computed server side. Sending client side hashes beings no benefits

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.

I've considered that but then there is transport encryption.

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.

> a separate hash for each mask

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.

It can all be done client-side: the client can try (un)capitalizing the letters after the original password fails

And it should. Better not to clutter the security-critical parts of the back end.

This would be bad for rate limiting though.

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.

Why would you need the client to send the request over and over when you control the backend?

Not to send the password in plain, maybe?

Are you aware of transport encryption?

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

You would just hash the incoming password with however many mutations you need.

You could normalize the PW before hashing (invert case unless last letter is lower case, then make 1st letter lower case)

Most certainly not. Those systems normally work by A) you providing the old password for verification or B) storing hashes of password substrings.

This sounds like a combinatorial explosion situation for longer passwords and longer changes required.

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.