7 ms·
> My hypothesis is that this is a technical limitation due to the password being stored as a char(6) in their database. and legacy security policies/requiremen
by nchlswu 12y ago
> My hypothesis is that this is a technical limitation due to the password being stored as a char(6) in their database.
and legacy security policies/requirements that have not undergone any update.
I've worked on a project that touched banking passwords in the past and in a push for modern password requirements (which was met....somewhere in the middle), the response was that since the number of attempts was so restricted (and claims about whatever security/fraud engine they were using), the risk caused by the restrictive passwords were essentially negated.
From a security perspective, how true is this? I'm genuinely looking to be educated. It did seem like a reasonable measure to prevent a bruteforce attack, but I'm not sure if I'm missing anything
- Afforess 12y agoHow true is this? Bullshit. Sure, it's secure from a front-door perspective. But if say, a future unpatched software vulnerability leads to the password hashes being leaked (a when, not an if) the 6 letter password hashes are going to be mighty easy to crack.
- wlesieutre 12y agoFor a system that limits passwords to 6 letters, I bet they weren't hashing them to begin with. But maybe nchlswu fixed that.
- danielweber 12y agoHow often do major US banks have their password tables leaked? When was the last time it happened?
- radicalbyte 12y agoActually, having weird password requirements might make them, on average, more secure. Why? Because the passwords will be different. The average person uses the same password over many sites. The chances of one of those sites being hacked/rogue is 100x higher than the bank getting hit. Weird requirements = different password = more secure.
- KMag 12y agoA common way of expressing what Afforess said is that simple passwords with effective rate limiting offer "brittle" security. As long as everything works perfectly, it's safe. However, there are many failure modes that rapidly degrade to trivially having access to all accounts. One would prefer to have defense in depth, such that failure of one part of the system would yield a system in which it's easier, but not trivial, for an attacker to access accounts. Using a modern Key Derivation Function (KDF) such a Scrypt along with allowing more complex passwords would in many cases prevent attackers from accessing those accounts that used more complex passwords (or force the attackers to change the passwords on the accounts, risking discovery when the owners next try to log in). Enforcing minimum password complexity would dramatically increase the percentage of accounts that couldn't be bruit forced if hashes were stolen. Hopefully the answers to security questions aren't kept in the same database as the password hashes, since they're nearly password equivalent. Even if the security question answers are hashed, 99.9% of the answers can be easily bruit forced. I grew up on g1SUIt2FJr1IHI Street and my first grade teacher was Mrs. IvwiYZ4Oar9uZg. Last year my dog was named AuiwVvMSPNTWbgy and this year I renamed him to dBuSHCTJDuSdAUu, but few people are so lucky. Also, when calling up my bank for help, it sure sounds like the phone operator can read my secret question answers off of the screen. In any case, an attacker takes some risk of discovery by resetting someone's password and hopefully banks all watch for spikes in rate of password resets, but secret question answers are nearly password-equivalent and seem to almost always be stored in plain text. The secret questions answers are the keys to the kingdom and the amount of code that has access to them needs to really be minimized and audited extremely well.