Welcome to Pete Brown's 10rem.net

First time here? If you are a developer or are interested in Microsoft tools and technology, please consider subscribing to the latest posts.

You may also be interested in my blog archives, the articles section, or some of my lab projects such as the C64 emulator written in Silverlight.

(hide this)

UX Anti Patterns for Security on the Web and in the Enterprise

Pete Brown - 14 February 2012

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.



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)

posted by Pete Brown on Tuesday, February 14, 2012
filed under:          

11 comments for “UX Anti Patterns for Security on the Web and in the Enterprise”

  1. Biff Gautsays:
    Amen! My company requires our voice mail password to be reset every 30 days and can't use the last 8 values - as if the fact that I need to pick up a gallon of milk on the way home is a state secret.
  2. Joe Wirtleysays:
    I had the same experience with my bank some time ago. Luckily, I haven't had to answer any of the questions that I made up answer to. The day I have to do that and cannot access my account is the day I'll find another bank.
  3. Davesays:
    Chase asks for my password during a transfer and tells me every time that it cannot contain special characters. There are several problems with this:
    A) You don't need to tell me the rules when I'm just entering my password for verification. This just makes it easier for someone to guess my password.
    B) It actually displays the special character in the validation error. Now someone looking over my shoulder knows which special character I use in my password.
    C) It's not even correct! My password works even with the special character. Granted this might actually increase security since it misleads potential crackers.

    I just laugh a little every time I see this.
  4. Scott Bussingersays:
    My pet security peeve is websites with strange login processes that aren't LastPass friendly. Seriously, *everyone* should be using a secure password manager like LastPass or it's an equivalent. But some banks have strange multipage login flows that are very hard to work with (I'm looking at you B of A)!
  5. Petesays:

    Out of the banks I deal with regularly, 3 have multi-page login flows, two of which have "site key" pages in between your username and password. I'm actually cool with that as it *helps* prevent phishing sites (unless the phishing site targeted me specifically and went and grabbed my site key first -- a possibility I just thought of now), but I can see how it could screw up password managers.

  6. William Kempfsays:
    I'm not a security expert, but I think even the security experts get it wrong from time to time. The old saw about not writing down passwords for instance. There's nothing wrong with writing your password down. There is something wrong with taping it to your monitor, obviously, but that's a different story all together. Some of the things we care most about securing we do so through some physical key that we carry around with us. So, tell me again why it would be so bad to carry my passwords around in my wallet? Yes, I know the arguments about how it is easier to copy a password than it is a key, but given how well social engineering works for hackers, I still think a wallet full of passwords is secure enough for most things.

    Really, though, we need to stop using passwords. At least the way they are used today. Give me a physical key. For security reasons you can salt that with a "passphrase" I have to enter. That's one thing for me to remember and one thing for me to carry. Use it universally. No more having to remember a bazillion sets of credentials for all of the various sites and services I use daily. Much better overall security for everyone basically "free". The only thing this doesn't address is how to handle changes when the key is lost or in some way compromised (I forgot my password scenario, just will happen much less frequently). Best answer I have for that is one time temporary passwords sent via e-mail for less secure things and physical validation of some sort for the more secure things (i.e. I'd have to go into the bank and talk to a teller who'd verify my identity through some official photo id or other means).
  7. Billsays:
    I have two answers to security questions: one word and one number. I use the same answer for every question on every Web site that requires them. I pick a random question and use the word if it needs a word and the number if it needs a number. Since they're completely disconnected from the question, no one could ever guess them and I never have any trouble remembering them.

    There's a possibility that they're not one-way hashing the answers, but I think that's probably unlikely.
  8. Travis Nelsonsays:
    Nice summary and definitely some things to keep in mind (as a consumer and a developer). I've been particularly surprised at the limitation of the max length of fields or the lack of attention to personal preference with passwords.

    I recently dealt with a financial institution which imposed an 8-character limit, no special characters or spaces. I can only hope they had good salting and max password attempt mechanisms in place. But, that's not the problem; exploiting the server and getting access to the data is. Given a non-salted hash of that password, any person in the world could find a GPU MD5 collision in the comfort of their own home in what, 2 days? In another example, I had to provide a 4-digit PIN number to an account. When I did, the customer service rep told me I couldn't use that number because it had a repeating digit. So, not only are they telling me I can't use the number I want to use, but they're also removing a rather large set of potential pairings from the set of 4-digit numbers. *facepalm*

    I recently started using two-factor everywhere I can and definitely thankful for sites that offer it.
  9. carltonsays:
    Finally, someone else sees the stupidity in these types of questions! All it does is encourage (or require) that you write them down somewhere...much less secure than just sticking with questions that you would innately know the answers to.
  10. Aparecidasays:
    What a blast!!! We had such a great time celebrating this biutuefal occasion and Todd was absolutely incredible to work with, not to mention very, very patient .Thanks for all the fun and memories. We had a terrific night !!!Congratulations Sarah and Cameron !!! You both are so fun and crazy I just know you're going to have a lot of laughs together. Keep the sparkle alive!!! I love you both.

Comment on this Post

Remember me