WellsFargo Ignores Case Sensativity on passwords | Hacker News Reader

WellsFargo Ignores Case Sensativity on passwords

5 pointsnamidark11 comments

To everyone who has a WellsFargo bank account: Call up their online banking and talk to a representative and ask for a FREE RSA token to add 2 factor authentication to your bank account.

Wells Fargo DOES NOT respect case sensitivity in passwords. ABC123 is the same abc123, your password strength is getting cut in half. Call and demand a free token - # is 1-800-956-4442 . Go to Account Services -> My Profile -> Managed Advanced Access and order the RSA token. Once you do tell them you want the charge waived.

After calling them and getting a call back from their IT department, they are aware of this and have no immediate fix planned.

View on HN

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

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 ("I don't see why that's an issue" != "That is not an issue")

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.

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

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.

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

Hmm, this would indeed be a simple, yet non-catastrophic explanation (and useful UX to boot). That would make sense; and if this were the case, I'd be glad I was wrong.

How is the UI just calling to_lower on the password while passing it to your encryption difficult to understand? No case sensitivity has nothing to do with no hashes. Period.

Also the value versus risk ratio for Diablo 3 accounts is probably better then trying bank accounts. The risk for attempting entry into a bank account is FAR higher then for a Diablo 3 account.

If you want to complain about something you should be complaining about websites that when you password recover e-mail you your old password. THAT is a sign of plain text password storage.

"your password strength is getting cut in half" - which is only the icing on the cake. As soon as the other side manipulates the plaintext version of your password, it is reasonable to assume that THEY ARE PROBABLY STORING THE PASSWORD REVERSIBLY. Whoa. (To be precise, they could be lowercasing the password client-side; but every case of "hello, we've mutilated your password" I've seen so far has been down to "oh, and we're storing it in plaintext; is that bad?").

Most banks consider a password to be a form of security theater (and quite rightfully so). Banks monitor many other aspects of the login (e.g., IP address, date/time, computer, what you do when you log in, etc.). Even if someone knows your password they will not necessarily be able to conduct a transaction on your behalf. Case sensitivity only adds an extra bit of entropy (possibly even less since I suspect the average user employs lower-case characters more frequently).

Sensitivity?

Reply on news.ycombinator.com