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

Why would they need to store the hash of both possibilities? They can simply invert the case of what the user types before hashing it - ie. compare both hash(enteredPassword) and hash(invertCase(enteredPassword)) to the hash in the database and see if either match.


Ah, good point. The overhead of doing two checks isn't that high.


They could also just ignore case: hash(upper(password)) so there is only ever one hash (that happens to map to multiple input passwords) instead of multiple hashes relating to a single password each.


But this is less secure than storing the properly hashed password. This would reduce the space of all passwords to upper case letters (plus whatever symbols and numbers are allowed) only.


It is however the approach battleNet (Blizzard - World of Warcraft) take, their password is completely case insensitive.


Yeah, I'm being downvoted for pointing out the method some places use. It's terrible to have anything but a minimum length requirement IMHO. Making it password insensitive is nice for users, but does make the resultant search space much smaller (to the point that I don't think the convince for users trumps, especially given the UI can inform them if they have caps lock on to begin with).


Which is weird, too. I wrote an email once to Blizzard, asking why they also have a maxlength for the password. This doesn't mean anything, but it could be an indicator for password = VARCHAR(16). Makes no sense whatsoever to restrict the length of a password, especially in such a large network. Never got a reply though.


I suspect that Facebook still wants to know that some letters have a different case than other letters. If They just converted all letters to uppercase then that information would be lost.


Sure, I think that this means that the try the normal case and the flipped case.

> ie. compare both hash(enteredPassword) and hash(invertCase(enteredPassword)) to the hash in the database and see if either match

Here's an example in bash:

  $ echo PasSwoRd | tr 'A-Za-z' 'a-zA-Z'
  pASsWOrD
In the database store one variant

  $ echo PasSwoRd | tr 'A-Za-z' 'a-zA-Z' | sha256sum > db
Then you can test both on input

  $ echo PasSwoRd | sha256sum > sum1
  $ echo PasSwoRd | tr 'A-Za-z' 'a-zA-Z' | sha256sum > sum2
  $ diff -q db sum1
  Files db and sum1 differ # i.e. LOGIN FAILS
  $ diff -q db sum2
  $ # i.e. LOGIN SUCCEEDS
The problem with the caps lock behaviour on Macs is harder. You definitely don't want to force to uppercase!


Do you know how they handle caps lock on Macs then? When caps lock is on, it types in caps even with shift.


Who says they can't check 3 times? Original, caps inverted and uppercase? This would make sense. You could even make it try neighboring keys on common key layouts. If the hash has enough bits of security then good passwords will still not break.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: