Hacker News Reader

Comment by tracker1 | Hacker News Reader

Two of three bank sites I log into regularly are limited to 8 alphanumeric characters, I'm frankly unsure if they even distinguish letter case.

It's probably time to start holding these sites accountable, however anything that could be proposed as regulation by the gov't on this would be a clusterfuck in implementation details, so I have bad feelings all around. I agree that there should be "unlimited" or reasonably limited (64-256 character limit) in input, since hashing will take care of the rest. Personally, I'd love to be able to use pass-phrases, ie, "Because, cookies are awesome!" ... Most of my "really" secure passphrases are like that (password manager, authy, etc).

View on HN

I can confirm this. Wells Fargo, a very popular bank in the US, limits passwords to 6 to 14 characters. In fact, your passwords are not even case sensitive. This is absolutely unacceptable in 2018.

I no longer have any bank accounts with Wells Fargo. In fact I don't have any bank accounts with any of these banks that have these stupid password restrictions.

I almost didn't believe you because their own password page says to use mix case, but I just tried it... and flipping case totally works. Crazy!

Wow, that's quite a dark pattern.

re: case insensitive .. I've heard of a bank with a similar problem, I don't recall which, where the reason was legacy compatibility with touch-tone phones. The password was normalized to something you could key in on a phone.

This isn't an excuse, just a poorly-remembered anecdote as to how backwards some of these systems are.

I can actually see a case for case-insensitive password provided that other security measures are in place, and that there is an entropy requirement somewhere. I doubt that is the actual reason why those banks have it implemented, but it could certainly be argued that people will remember their passwords better if case is not an issue; and lets face it, most remember-able passwords will either be all of one case, or have the first letter capitalised. Goes back to the saying "Security at the expense of usability comes at the expense of security".

This argument is based on the assumption of passwords needing to be remembered, which is certainly debatable from a security POV, but it a very common use pattern by humans.

Sadly, if the limit is 8 characters, they might be using something like the original DES provided by crypt()[1], it silently truncated to 8 characters. Or they may have moved on to something newer by now on the backend, but have the 8 character limit hardcoded in a bunch of places.

[1] https://en.wikipedia.org/wiki/Crypt_(C)#Traditional_DES-base...

Some DBMS' do require a limit... eventually. I think 256 is a reasonable bound, since that allows very generous pass phrases.

And actually, the NIST password recommendations are very reasonable, at least currently.

You failed the test. Back to Security 101 with you!

The point being made is that all passwords should be hashed and a hash is going to be fixed-length. Therefore there should be no limit on password length beyond, say the limit of the total HTTP POST size -- but you're not using a megabyte-long password, are you?

What meaningful distinction are you drawing between a 1mb limit and a 256 character limit?

They aren't. They're just referring the the POST request size limit (which isn't hard set at one megabyte, but that's not their point, either).

I use The Complete Works of William Shakespeare, Unabridged as my password to several sites. How could you get more secure?

Unix or windows line endings?

I mix them up using a CSPRNG to flip a coin.

I replace all line-endings with "Bee Movie" as binary in avi format.

And every time someone says "Bee", it's replaced with "We Are Number One"

Only the hash should be stored so limit of the original password is mute

Pedantic comment: The word is "moot"

The current NIST requirements almost read like someone at NIST read the famous XKCD[0] and decided to implement it. Likely the best standard we've ever had in its reasonableness.

[0] https://xkcd.com/936/

But you shouldn't be storing a raw, unhashed password in the database anyway.

Are your banking sites smaller? (Eg, credit union)

One core financial stack I know of stores home banking passwords unencrypted. They transcode ASCII -> EBCDIC to obscure the password and call it a day.

Tangerine (Canadian bank) only offers a choice between exactly a 4-digit or 6-digit password. These are numeric digits, not alpha-numeric. Yes, this is for online and telephone banking, not just one's debit card PIN - though I'm sure most people use the same 4-digit code for both.

These may as well be stored as plaintext. What would be the point of hashing when you're dealing with a mere 10,000 permutations for 4-digit passwords (or 1,000,000 for 6-digit)?

Reply on news.ycombinator.com