4 ms·

This "Facebook approach" almost certainly requires you to have, at least once, access to your users' non-hashed passwords. Which is widely regarded as bad secu

• maaarghk 12y ago
  You do have access to their non-hashed password. When they type it into your form and press enter. You just invert the case and check it against the hash again.
  • k__ 12y ago
    Why not including the lowercase into the hash-algorithm?
    • MartinCron 12y ago
      A hashing algorithm specifically for passwords that would hash to the same thing based on inverted caps lock or other deterministic user errors (white space at the edges, maybe)? That sounds like a great idea.
• deleted 12y ago
  [deleted]
• deleted 12y ago
  [deleted]
• kibwen 12y ago
  Assuming that you run your own login service like Facebook does, you always have access to your user's passwords at least once because at some point you have to take the raw password and hash it. Facebook just creates two variations of the user's password and stores the hashes for all three of them.
  • ssmoot 12y ago
    All three of them? The Hash for the password as-typed, another for as-typed.invert(). What's the third? I feel like I'm missing something obvious. :-/
    • andrewaylett 12y ago
      Mac-style caps-lock, which doesn't invert again with shift, and PC-style, which does.
    • plorkyeran 12y ago
      First letter uppercase, for mobile devices that default to shift being on for just the first letter.
    • TheCoelacanth 12y ago
      Possibly for the two different types of caps lock. The kind that inverts the case of everything and the kind that makes everything uppercase.
      • ssmoot 12y ago
        I never noticed that. (I switched to Macs around 8 years ago.) Huh. In that case I guess I have to wonder what the point is? Why store three hashes as opposed to just upper-casing the plain-text before hashing? You end up storing fewer variations, and it makes no functional security difference to the front-end (since any attacker would just .toUpperCase() their inputs anyways)? At least best I can reason.
• varikin 12y ago
  You always have access to the user's unhashed passwords when they submit it. In authentication, hash the raw password and invert case and the hash that. Then compare the stored hash against both hashed passwords from the input. There is no need to store the password in plain text in any form.
• dsacco 12y ago
  You're right that it's bad to store non-hashed passwords, but your point about security is unfounded. Facebook, and any other company you'll log in to, requires a non-hashed password at some point to check against the hash. You need a cleartext password at some point, otherwise the user can't send anything to you. The best practice for security is to not store passwords in cleartext. You can certainly perform extremely limited actions on passwords in cleartext (like hash checking), and you inevitably have to. Which brings me to my overall point - as the Facebook security team has explained before on their whitehat page, you do not practically reduce security by allowing caps lock inversion to check a hash. What you're saying about Facebook having an abnormal process also isn't true either - Facebook does one of two things, both of which are secure: 1. Stores two hashes for each password, one the real password and the other the case inverted, or 2. Checks a password against a hash, and inverts the case and checks again if it fails. There is nothing about this which is different from normal password transmission in cleartext, and Facebook doesn't store the cleartext password you send them. EDIT to your EDIT: No, no no no no, no. Don't do clientside things like that. Allowing a user to directly manipulate something as major as whether or not their password is hashed before it is sent to you is bad. It doesn't even matter that it's just them hacking themselves; it's just bad form to put that in their browsers' hands. Plus, a stored cross-site scripting error that went viral on the login page pre-auth could screw your password database, leading to a layup for mass cleartext password compromise. Or in a worse scenario, you're giving a user direct write access (and then maybe reads) to the password database. It's much safer to do the industry best practice of destroying cleartext sensitive information upon successful hash. Say no to clientside security. There are arguments for hashing clientside, but they can all be summed up by "You shouldn't let people potentially sniff users' passwords" - if you implement TLS/SSL correctly, this won't be an issue and the cleartext password will exist briefly, then get destroyed. The one other argument is that someone could compromise the server handling the hashing process and write a script watching all the passwords. But this isn't a valid concern - if someone has backdoored your login server, it no longer matters if passwords are cleartext for the damage they'll do. The level of difficulty you introduce by having passwords hashed originally becomes moot at that point. Finally, consider that a client-side hash of a password sent to a server becomes the effective password for that user, not the hash of the password. This means that, effectively, if no other action is done at the server, you're actually then storing the password in plaintext. If a user was MITM'd while sending the password, the hash can now be sent directly to the server in place of the user's password, because it is the de facto password. The bottomline: client-side hashing offers no real addition to overall security posture under TLS/SSL, and removes most of the benefit of hashing.
• vertex-four 12y ago
  > Answers pointing out that you always have access to non-hashed passwords, and I believe this is wrong. When the user submits their password, it SHOULD be hashed client-side and only the hash SHOULD be sent to you. If you insist on doing this, you can always invert it and hash it on the client side, and send both hashes. You still have access to it, just on the client's computer (running your own code).
• ZoFreX 12y ago
  > When the user submits their password, it SHOULD be hashed client-side and only the hash SHOULD be sent to you. No. If you are going to do something like this, do it properly with something like a zero-knowledge password proof. As you describe it you are introducing a huge flaw: If your password database leaks, an attacker now has everything they need to log in to user accounts, no password hash attacking required.
• Someone 12y ago
  If you send a hash instead of a password, that hash _is_ your password. If I steal the hash but not the string it was derived from, I can pretend to be you and log in.
• stouset 12y ago
  Hashing client-side is not a good idea in practice — a leak of your password database leaks direct credentials for logging in. If you're going to go this route, something like the zero-knowledge SRP protocol is necessary.
• akerl_ 12y ago
  If you hash the password client side, then the hash is the actual password and the server still sees the actual password.