5 ms·

Honestly this is the same argument that has been swirling around Diablo 3 recently regarding their decision to use case insensitive passwords. The importance o

Honestly this is the same argument that has been swirling around Diablo 3 recently regarding their decision to use case insensitive passwords. The importance of case sensitivity is dramatically overblown. An appropriately long password is still just as safe regardless of case sensitivity. http://en.wikipedia.org/wiki/Password_strength#Random_passwords http://en.wikipedia.org/wiki/Password_strength#Random_passwo... If you examine the length versus entropy chart you'll notice that you get identical results with only 2 more characters in your password for case insensitive. http://xkcd.com/936/ http://xkcd.com/936/ also seems relevant. This really seems like mountain out of a molehill, although I think everyone should get 2 factor authentication whenever it's an option. I don't see any correlation between someone choosing to use caps insensitive passwords and clear text password storage.

Piskvorrr 14y ago
Unless you're storing the passwords reversibly (which is pointless, and in 90% cases means "in plaintext"), how exactly do you know what to lowercase? Sane systems store passwords hashed (and salted) - and two strings, different only in casing, will give you completely different hashes. So: no case sensitivity => no hashes => reversible password storage => IT Security 101 Fail. There's a difference between a user choosing a case-insensitive password, and the provider changing the user's password to something else. As you point out, the entropy added is not very significant; but it is very significant who makes this change in data - in a properly secured system, the provider should have no way of getting at the user's passwords ("we have a policy" doesn't cut it, this needs to be technically infeasible - which is what password hashing does). Well, of course their backend systems are probably uber-secure and impenetrable, but there's no way to verify this, so you're depending on their honor - like people did with the various companies which had their databases hacked lately (Yahoo comes to mind - two weeks back?) and the passwords published out on the intertubes. And, to be honest, how much value is there in an average user's Diablo 3 account? And in an average user's bank account? I think this is the core difference. Further reading - e.g. this: http://dustwell.com/how-to-handle-passwords-bcrypt.html http://dustwell.com/how-to-handle-passwords-bcrypt.html ("I don't see why that's an issue" != "That is not an issue")
- blamarvt 14y ago
  I'm not sure I understand the correlation between storing a case-insensitive value and encryption type / data storage medium. Just because they do pre-processing on a value passed over secure means (in this case .toLower() or toUpper() or equiv.) before inserting it into a database doesn't hint at all at what format is being chosen for storage. It's a silly thing to do and might hint at stupidity, but it's not "IT Security 101 Fail" unless more information can be ascertained.
  - Piskvorrr 14y ago
    If you're doing one irreversible transformation on the string (hashing), doing another (lowercasing) is quite pointless. This doesn't prove use of a reversible storage, but it's a very, very strong indicator. "If you hear hooves, it's probably horses, not zebras."
    - Jacquass12321 14y ago
      Again I'm not seeing how a to_lower on a string in any way implies plain text storage. There's no indicator at all frankly. It was a 2 minute decision by whoever implemented the user input and has negligible impact on password entropy.
    - Firehed 14y ago
      No, it does not. Here's a sample: function checkPassword($user, $posted_password) { return bcrypt(strtolower($posted_password), $user->saved_hashed_password) === $user->saved_hashed_password; } function setPassword($user, $posted_password) { $user->saved_hashed_password = bcrypt(strtolower($posted_password), generateSalt()); } Lowercasing the password before hashing (both on save and check) indeed lowers the strength of the password, but it saves a lot of support headache from users that have caps lock turned on, or your mobile device auto-capitalizes the first letter. Facebook does this, although in a better way: http://www.zdnet.com/blog/facebook/facebook-passwords-are-not-case-sensitive-update/3612 http://www.zdnet.com/blog/facebook/facebook-passwords-are-no... While we can't know without looking at their implementation, it's certainly possible and indeed fairly easy to build a forgiving system without having the password stored in a reversible format.

Piskvorrr 14y ago

Unless you're storing the passwords reversibly (which is pointless, and in 90% cases means "in plaintext"), how exactly do you know what to lowercase? Sane systems store passwords hashed (and salted) - and two strings, different only in casing, will give you completely different hashes. So: no case sensitivity => no hashes => reversible password storage => IT Security 101 Fail. There's a difference between a user choosing a case-insensitive password, and the provider changing the user's password to something else. As you point out, the entropy added is not very significant; but it is very significant who makes this change in data - in a properly secured system, the provider should have no way of getting at the user's passwords ("we have a policy" doesn't cut it, this needs to be technically infeasible - which is what password hashing does). Well, of course their backend systems are probably uber-secure and impenetrable, but there's no way to verify this, so you're depending on their honor - like people did with the various companies which had their databases hacked lately (Yahoo comes to mind - two weeks back?) and the passwords published out on the intertubes. And, to be honest, how much value is there in an average user's Diablo 3 account? And in an average user's bank account? I think this is the core difference. Further reading - e.g. this: http://dustwell.com/how-to-handle-passwords-bcrypt.html http://dustwell.com/how-to-handle-passwords-bcrypt.html ("I don't see why that's an issue" != "That is not an issue")

blamarvt 14y ago
I'm not sure I understand the correlation between storing a case-insensitive value and encryption type / data storage medium. Just because they do pre-processing on a value passed over secure means (in this case .toLower() or toUpper() or equiv.) before inserting it into a database doesn't hint at all at what format is being chosen for storage. It's a silly thing to do and might hint at stupidity, but it's not "IT Security 101 Fail" unless more information can be ascertained.
- Piskvorrr 14y ago
  If you're doing one irreversible transformation on the string (hashing), doing another (lowercasing) is quite pointless. This doesn't prove use of a reversible storage, but it's a very, very strong indicator. "If you hear hooves, it's probably horses, not zebras."
  - Jacquass12321 14y ago
    Again I'm not seeing how a to_lower on a string in any way implies plain text storage. There's no indicator at all frankly. It was a 2 minute decision by whoever implemented the user input and has negligible impact on password entropy.
  - Firehed 14y ago
    No, it does not. Here's a sample: function checkPassword($user, $posted_password) { return bcrypt(strtolower($posted_password), $user->saved_hashed_password) === $user->saved_hashed_password; } function setPassword($user, $posted_password) { $user->saved_hashed_password = bcrypt(strtolower($posted_password), generateSalt()); } Lowercasing the password before hashing (both on save and check) indeed lowers the strength of the password, but it saves a lot of support headache from users that have caps lock turned on, or your mobile device auto-capitalizes the first letter. Facebook does this, although in a better way: http://www.zdnet.com/blog/facebook/facebook-passwords-are-not-case-sensitive-update/3612 http://www.zdnet.com/blog/facebook/facebook-passwords-are-no... While we can't know without looking at their implementation, it's certainly possible and indeed fairly easy to build a forgiving system without having the password stored in a reversible format.