I log into my local bank's website quite often. I transfer money between accounts and all the usual things. Today, when I logged in, I saw that they've decided to dump the security questions they had us answer earlier this year and replace them with a completely new and obscure set. If you don't set the security questions, you can't get to your bank account.

Don't get between me and my money. Seriously. There's no better way to get on my bad side.

In addition, they decided to make the questions really different from the usual set. I'm sure they feel like they're doing the right thing in the name of security, but here, they have failed. That got me thinking about security usability and other anti-patterns I've run into again and again. So here's my rant er.. list of things I think are stupid when it comes to usability of security approaches. These are only the front-end (UX) things that people seem to think are good approaches, but really aren't. I'll leave out the obvious things like emailing you your forgotten password, accepting login info in plain text, storing passwords without salted hashes etc.

Security Questions: Obscure is better?

Here are the question sets my bank has chosen. You must pick one from each set and provide a short answer. The field is pretty small, but it's limited to 50 characters via the maxlength attribute in HTML. The field also has autocomplete turned off.

Here's the form I was presented with, with the first set of questions open. Looking at this, I've got nothing to answer that I'll remember. Keep in mind that these will be compared by computer. Case may or may not be important, but a string match certainly is. In every implementation I've seen, "rock" and "the rock" will be treated differently. You're also not asked to retype the answers, so typos will also hang you up.

Note that "Your answers should not include special characters". Good thing the artists formerly known as Prince wasn't my favorite childhood friend. More on this later. Where did my parents meet? Well, there are three children including me, so in the bedroom at least three times, I guess. My son just turned 6. If I asked him what he wants to be when he grows up (I hate that question), I'm pretty sure it'll change from week to week. What was my dream job as a child? It's not something I'd remember, so I'd have to make something up. Will I remember what I made up? Probably not.

Here's the second set. There are a few better candidates here, and some real doozies. Unfortunately you can only use one from this group. You know, I actually remember my childhood phone numbers, but as a way into security that's pretty weak. Seriously, you want a numerical answer to one of these questions? No, I'm sure that could never be cracked.

Ack! Back to even more stuff I'll never remember. "What's the most extravagant purchase [I] would make?" A new security team for you guys. <rimshot>

If you want to retire in a foreign city, keep in mind: no special characters! Your dream car had better be one with only letters and numbers in the name (again, not like a dictionary attack could ever succeed when limited to just the domain of cool autos, right?)

Many of the answers to these questions are just too ephemeral. What is your dream car? Where do you want to retire? What is your pet peeve? Who is your least favorite boss? Two years from now, will these answers be the same? Will you remember what you answered in your "I just have to answer these questions so I can transfer some money to cover xyz" rush from your lunch hour?

I'm sure they wanted questions that weren't popular on other sites. Like reusing passwords, entering your mother's maiden name for your security question isn't all that secure. A slightly better approach which accomplishes the same thing is to allow user-entered questions. Sure, people can be stupid about what they enter in there, but it's better than this approach. Another approach would be to pool all the questions and let the customer pick three from the larger pool. There's a much higher chance that they'll find three they can remember.

Here's another good one:

So you invest all that time coming up with good passwords, only to have it thwarted because of this loophole. Consider that it's a lot easier to do a dictionary lookup or guess your favorite car than to figure out your password.

Oh, and I bet your company isn't putting as much thought into encryption to the answers (and which question they selected) as you would a password.

Unless you go meaningless and just use memorable answers that have nothing to do with the questions, these Q&A are now a candidate for post-it note security, just like overly complex and constantly changing passwords.

Requiring Super Complex Passwords

As computers get more powerful and arrays of computing power cheaper, cracking passwords has gotten easier and more affordable. In response to this, many IT organizations have taken the knee-jerk "best practice" approach of requiring complex passwords. You know, the ones that require "At least one uppercase letter, at least one lowercase letter, one or more numbers and one or more symbols"

xkcd did a great job tackling this one some time ago, so I'll simply refer you to that:

Not to mention that passwords that are more secure (using things other than simple substitutions) are often written down and stored near the computer somewhere. This is especially true for ones which don't get used often.

A better choice would be to, during the password setup/registration process, do a server-side lookup of the password and see if it's in a dictionary (spell checkers have good dictionaries). If it is, tell the user they need to pick something else, or use multiple words together. It's really not that hard to do.

These same companies/sites etc. will often require you to change your password every X days, and then not allow you to reuse any of the past X (where X is often a year's worth) passwords. Understand that this results in people writing down their passwords. Sorry, SSL and fancy database-level hashes don't cover notebook paper or post-it notes.

Plus, not every site needs to be secured like Fort Knox. I love seeing forums with these really "strong" password requirements. Really, it's a forum, not an ICBM launch control center.

Limiting Password Length to 8 or 12 Characters

On the opposite side of things, we have passwords of limited length. I've been to more than a few sites which limit passwords to 8 or 12 (and one was 6!) characters.

Dear banks and other sites: It's time to update your fixed-width COBOL field to something a little longer. With all the other complexities you've added for security, you've completely thrown it out the window by restricting us to overly short passwords. That known restriction makes it easier for hackers to calculate passwords both because they have a known upper bound and because short passwords are easier to crack. One of the most important aspects of password strength is the length of the password (assuming it's not a simple dictionary word).

Not allowing "Special" or Foreign Characters in Passwords / Answers

Similar to the password length issue, we have sites that tell you *no* special characters or spaces. It's like the password must be a valid COBOL identifier or something. Similar restrictions often exist for answers to the security questions. You can see in my bank above, they tell you you shouldn't have "special" characters in the answers.

Not everyone in America was born here. When you ask "Which street did you grow up on" and them disallow "special" characters, you've made it hard for some people to provide real answers. Use a MBCS or Unicode field. ASCII is so 1985.

Not only that, but instructing against using "special" characters tells me that your data layer or parsing system is probably brittle. It gives the hacker another clue into your implementation. I hope you're not just building up a SQL string in that code, are you? If so, let me introduce you to little Bobby Tables.

Password Masking

While I'm at it, password masking should always be optional. Have a checkbox near the password box so you can decide not to mask it if you want to. This is especially important for small devices.

99% of the time, when I type a password or a giant WPA passkey, I'm in my home office with no one else around. Most phones and tablets handle this by letting you see the typed character for a second before it's masked, but I shouldn't have to shift focus that much. I'm not a great touch-typist on phone keyboards (autocorrect helps a lot, but not with passwords), let's not use touch-typing approaches here.

I recently had to type the (long) WPA passkey on to my son's new Nintendo 3DS. The virtual keyboard on that thing makes the smallest phone seem spacious. It's designed to be typed using a stylus. And yes, it's masked as you type and you can't unmask it. If you get it wrong (which I did the first time, as the key is case-sensitive), they clear out the whole field and make you start over. Bite me, Nintendo.

Summary

There are many things you can do to increase the security of your system without making it horrible for users. I am not a security expert, but it seems to me that many of the patterns that are common knowledge "best practices" haven't been actually proven or analyzed by anyone, or more importantly, aren't particularly valid in today's environment.

Anyway, thanks for listening to er..reading my rant. Feel free to rant below if you want ( <-lame attempt at starting a "discussion". Maybe I'll rant on blogging anti-patterns too)