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)
No hay comentarios:
Publicar un comentario