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