Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: