Banks, Arbitrary Password Restrictions and Why They Don't Matter
Sorry, but that article is just dumb. For one, obviously, the possible existence of other security mechanisms is exactly no reason for intentionally breaking password security. Either you store passwords as plain text, in which case you have just failed, or you are storing a hash, in which case there is no cost to doing the right thing and accepting arbitrarily long passwords. There is no way to start with &quot;we have other security mechanisms in place&quot; and end with &quot;therefore, we should weaken password security&quot;. And if an organisation is incapable of understanding that trivial piece of logic, I have very little hope for their supposed magic security solution.<p>But even worse: The idea that locking users out after so many failed attempts is a security mechanism. When a small bandwidth of unauthenticated requests can disable a critical service, that is known as a denial of service vulnerability and not a security mechanism. If you have proper passwords, locking users out is completely useless for security, but it&#x27;s still a DoS vulnerability. A brute force attack will not crack a 128 bit random password, no matter the rate at which it is tried. And while non-public user IDs can help mitigate that risk, it is not at all a given that banks don&#x27;t use essentially public account numbers as user names, even ones that have 6-digit password limits. Plus, the user ID at that point effectively becomes part of the password, just that it&#x27;s a password that you can&#x27;t change, which isn&#x27;t exactly brilliant either.<p>And finally: It&#x27;s quite a failure at assessing attack scenarios if you think that user lockout actually solves a problem. Your typical bank has a failure counter per account. A failure counter that is reset on every successful login. So, the real number of attempts an attacker could make is the number of attempts you have before lockout minus one, multiplied by the number of successful logins by the customer. An attacker might not necessarily be able to know very well when the user has logged into their bank account, which sure will limit the exploitability somewhat, but then, that very much depends on the circumstances. If you know someone pulls their transactions every 15 minutes, say (especially a business, which might even leak the time they pull transactions by sending payment receipts in response, for example), then you might very reliably be able to make 8 guesses per hour, or ~ 70000 per year, without causing lockout. If you instead want to target the general public, you might also just use a bot net to attempt login into accounts only occasionally, risking some lockout, but statistically compromising a certain number of accounts over time.<p>And all of that when proper passwords do solve all of those problems perfectly reliably.<p>Oh, yes, and the idea that some banks will give you your money back? Seriously? Now, if that isn&#x27;t a failure at assessing risks, I don&#x27;t know what is. Who seriously believes that banks will give you your money back on your word that you didn&#x27;t authorize some transaction? Of course, they won&#x27;t, they&#x27;d be wide open to fraud if they did. If the attacker is good enough at making it seem like the customer authorized the fraudulent transaction, obviously, the customer won&#x27;t get back a cent. Those claims by banks are marketing bordering on fraud, and obviously not something anyone claiming to be an expert in security should just trust to be something you can rely on.