7 ms·

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 on

by remram 5y ago

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

azernik 5y ago
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.
rovr138 5y ago
Doing this reduces way more the space of characters and reduces security.
- freemint 5y ago
  It reduces the password strength by at most two bits. For passwords made solely of non letters there is no reduction in password strength.
  - nitrogen 5y ago
    It's one bit per alphabetic character, isn't it?
    - smrq 5y ago
      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.
      - nitrogen 5y ago
        Whoops, I didn't notice that the two L's were still capitalized in the normalization example a few comments up.
      - freemint 5y ago
        *and one for the caps lock key
- remram 5y ago
  It reduces the space of passwords just as much as having the backend try those same combinations for every query.
josefx 5y ago
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.
- deleted 5y ago
  [deleted]
- ademarre 5y ago
  https://tools.ietf.org/html/rfc8265 https://tools.ietf.org/html/rfc8265
  - josefx 5y ago
    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).
- josefx 5y ago
  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?

by remram 5y ago

azernik 5y ago

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.

rovr138 5y ago

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

freemint 5y ago
It reduces the password strength by at most two bits. For passwords made solely of non letters there is no reduction in password strength.
- nitrogen 5y ago
  It's one bit per alphabetic character, isn't it?
  - smrq 5y ago
    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.
    - nitrogen 5y ago
      Whoops, I didn't notice that the two L's were still capitalized in the normalization example a few comments up.
    - freemint 5y ago
      *and one for the caps lock key
remram 5y ago
It reduces the space of passwords just as much as having the backend try those same combinations for every query.

josefx 5y ago

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.

deleted 5y ago
[deleted]
ademarre 5y ago
https://tools.ietf.org/html/rfc8265 https://tools.ietf.org/html/rfc8265
- josefx 5y ago
  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).
josefx 5y ago
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?