Irreal

Yesterday, I wrote about stupid password rules and why they don’t matter for banks. Serendipitously, right after I published that post I came across an old Coding Horror post on stupid password rules. It’s a long and righteous rant on the infuriating, nonsensical password rules that confuse the less technically sophisticated leading them to seek workarounds that are less secure. At the same time, they frustrate the ideal user who employs a password manager to generate the long, random passwords that are more secure than anything the rules could provide.

Atwood doesn’t subscribe to the Irreal rule that any restriction is a sign of weakness. He divides password rules into two classes: those that you tell the users about before they attempt to choose one and those you apply as a sanity check after the a password is chosen.

There’s one rule in the first class: passwords must exceed a minimum length. What that minimum length is will vary according to the application you’re protecting and the environment you’re working in. Even if passwords are salted and hashed, a stupid password like abc is still easy to discover. A long password is effectively safe from brute forcing even with an offline attack.

The rules in the second class get rid of obvious passwords that any attacker will try. They include things like the user’s login ID, the user’s email address, and perhaps any password on one of the lists of most commonly used passwords that appear every year. You can read Atwood’s post to see the exact rules in the second class.

Of course, the only sensible thing to do is to use a password manager to generate long, random passwords. At least if the site will let you.

Over the years, I’ve done a lot of huffing and puffing about passwords, most recently in my post on Bad Password Policies. Troy Hunt has a slightly different take on things, at least as far as banks are concerned. It seems odd that Hunt would give banks, of all institutions, a break. After all, the stakes are generally higher and banks have ridiculously lax password policies.

Hunt does agree that banks shouldn’t have these silly policies but says that they’re usually required by legacy concerns and, in any event, don’t really matter. Wait. What? How can they not matter? There’s two reasons for that. First, banks are aggressive about blocking accounts after three failed login attempts. Even if the bank has a ridiculous password policy like four digits—yes, some banks have exactly that policy—two mistakes doesn’t leave a would-be exploiter very much room.

Second, banks don’t rely just on the customer-facing security mechanisms to verify a login. They have additional mechanisms hidden from the customer. The banks, of course, rightfully won’t say what those additional mechanisms are. We’re more or less required to trust the banks that they’re effective.

Although Hunt says the policies don’t really matter, he does, as I wrote above, say that they should do better. “We’ve got old systems to interface with” shouldn’t be a perpetual excuse. After a while you have to upgrade those old systems. One of the main reasons it matters, he says, is trust. It’s pretty hard to judge the security of a site. The best method we have is, as I’m always harping, is to consider any password restrictions a sign of weak security and worse, an indication that your passwords aren’t being salted and hashed. Trust is important with any commercial interaction and especially so when dealing with banks so they shouldn’t squander it with stupid password policies.

Take a look at Hunt’s post. It’s an interesting and informative look at a little-understood aspect of banking security.