Balancing Security and Usability in Authentication

Since January, the Conficker.B worm has been spreading like wildfire across the Internet: infecting the French Navy, hospitals in Sheffield, the court system in Houston, and millions of computers worldwide. One of the ways it spreads is by cracking administrator passwords on networks. Which leads to the important question: Why in the world are IT administrators still using easy-to-guess passwords?

Computer authentication systems have two basic requirements. They need to keep the bad guys from accessing your account, and they need to allow you to access your account. Both are important, and every authentication system is a balancing act between the two. Too little security, and the bad guys will get in too easily. But if the authentication system is too complicated, restrictive, or hard to use, you won’t be able to—or won’t bother to—use it.

Passwords are the most common authentication system, and a good place to start. They’re very easy to implement and use, which is why they’re so popular. But as computers have become faster, password guessing has become easier. Most people don’t choose passwords that are complicated enough to remain secure against modern password-guessing attacks. Conficker.B is even less clever; it just tries a list of about 200 common passwords.

To combat password guessing, many systems force users to choose harder-to-guess passwords—requiring minimum lengths, non alpha-numeric characters, etc.—and change their passwords more frequently. The first makes guessing harder, and the second makes a guessed password less valuable. This, of course, makes the system more annoying, so users respond by writing their passwords down and taping them to their monitors, or simply forgetting them more often. Smarter users write them down and put them in their wallets, or use a secure password database like Password Safe.

Users forgetting their passwords can be expensive—sysadmins or customer service reps have to field phone calls and reset passwords—so some systems include a backup authentication system: a secret question. The idea is that if you forget your password, you can authenticate yourself with some personal information that only you know. Your mother’s maiden name was traditional, but these days there are all sorts of secret questions: your favourite schoolteacher, favourite colour, street you grew up on, name of your first pet, and so on. This might make the system more usable, but it also makes it much less secure: answers can be easily guessable, and are often known by people close to you.

A common enhancement is a one-time password generator, like a SecurID token. This is a small device with a screen that displays a password that changes automatically once a minute. Adding this is called two-factor authentication, and is much more secure, because this token—”something you have”—is combined with a password—”something you know.” But it’s less usable, because the tokens have to be purchased and distributed to all users, and far too often it’s “something you lost or forgot.” And it costs money. Tokens are far more frequently used in corporate environments, but banks and some online gaming worlds have taken to using them—sometimes only as an option, because people don’t like them.

In most cases, how an authentication system works when a legitimate user tries to log on is much more important than how it works when an impostor tries to log on. No security system is perfect, and there is some level of fraud associated with any of these authentication methods. But the instances of fraud are rare compared to the number of times someone tries to log on legitimately. If a given authentication system let the bad guys in one in a hundred times, a bank could decide to live with the problem—or try to solve it in some other way. But if the same authentication system prevented legitimate customers from logging on even one in a thousand times, the number of complaints would be enormous and the system wouldn’t survive one week.

Balancing security and usability is hard, and many organizations get it wrong. But it’s also evolving; organizations needing to tighten their security continue to push more involved authentication methods, and more savvy Internet users are willing to accept them. And certainly IT administrators need to be leading that evolutionary change.

A version of this essay was originally published in The Guardian.

Tags: , , , , , , , , ,

Posted on February 19, 2009 at 1:44 PM • 60 Comments

Comments

Davi Ottenheimer • February 19, 2009 2:08 PM

“But if the same authentication system prevented legitimate customers from logging on even one in a thousand times, the number of complaints would be enormous and the system wouldn’t survive one week.”

Apparently you haven’t been using Microsoft products.

Kashmarek • February 19, 2009 2:26 PM

We once had a VPN network system for home access that used the securid tokens. It was a double logon, once to the laptop then with the securid token to the network. This was good.

Then we switched to a browser based VPN system that used the same credentials as for logging on to the laptop, but not single signon since we had to do the same thing twice (2nd time for the network). Not as secure but cheaper.

I want the older system because it works while the new one has many failures (locked sessions for Xwindows & ftp, dropped sessions for ssh & email, and failed VPN sessions).

dan-in-philly • February 19, 2009 2:51 PM

I don’t care what secret question they use because I use a double secret answer. Mom’s maiden name? No problem, Temple University, that’s her name all right!

kangaroo • February 19, 2009 2:55 PM

I don’t get the logic of password rotation. If you’re account is compromised, and you change the password — well, you might lock out your enemy. Or not, since they’ve had access to all options such as secondary passwords (mother’s maiden name, etc) or creating backdoors.

You should identify intrusions. Otherwise, you’re just creating a false sense of security, placing the blame on users for your security lapses (“but the password had already been rotated”), and creating security holes (“I taped the password on my monitor because it keeps getting changed. I made the password simple because it keeps getting changed. I forget my password so we need a backdoor like mother’s maiden name because it keeps getting changed…”)

Seems like another example of security theater — it definitely hasn’t been though through.

Ward S. Denker • February 19, 2009 3:16 PM

“This is a small device with a screen that displays a password that changes every time the button is pressed.”

I’m not sure this is an accurate description of the behavior of these devices. All of the ones I have seen change on a consistent basis by an algorithm which is in sync with a server somewhere. There’s even a little “heartbeat” on the device to warn the user that the password displayed is about to change so they can just wait for the next iteration (if they aren’t a fast typist of numerics).

There may be some which act this way, but I kind of doubt it. The remote keyless entry system employed by auto manufacturers generally has precomputed 255 codes in advance so that the remote won’t fall out of sync with the car. Pressing the button 256 times out of range of the car (which prevents the car from resetting its table) would lock the remote out, requiring a re-sync.

Forcing a re-sync like that on either side by allowing the user to select codes on a whim (pressing a button) would add an element of predictability to the system that I’m not sure I’d be willing to incur.

Ping-Che Chen • February 19, 2009 3:29 PM

@kangaroo:

The original idea of password rotation is that it takes some time to guess a password, so if you rotate your password more frequently than the time it takes to guess that password, it would be useless to guess the password at all. For example, supposed that it takes 100 days on average to guess a password, you should be quite safe if you change your password every 50 days or so.

Of course, the problem now is that it’s just too easy to guess a “bad” password now. Even a mixed password like “word” + number + special symbol may only take a few days to crack with a fast computer, especially with current GPU assisted password cracker. A very good password still takes very long to guess (e.g. a random password generated by password safe), but very few people actually use this kind of password. So it’s kind of making password rotation pointless, because if you use a very strong password it takes extremely long to guess so there’s no point on changing it. On the other hand, if you use a weak password, then it may be broken in, say, 2 days, so password rotation won’t help you at all.

Of course, there are other concerns with password rotation too. For example, in some cases the attacker may not be able to use the broken password at once, so if you change password before the attacker uses it, you can prevent an attack. However, this is kind of rare and it requires a very frequently rotation.

Carlo Graziani • February 19, 2009 3:52 PM

For a while, there were implementations of one-time passwords based on S/Key that were popular. I liked S/Key — all software (no token), could be securely re-initialized remotely, as strong as the underlying hashing system, portable, easy to implement as a library (e.g. a PAM module).

Any application secured by password auth could be tweaked to use S/Key instead. I never understood why the hardware OTP systems caught on, and S/Key disappeared.

Anon Y. Mouse • February 19, 2009 4:02 PM

Whatever happened to the idea of blocking entry to the account
for a few seconds when an invalid password is entered?

A legitimate (human) who simply mis-typed their password wouldn’t
even notice, but it would slow down automated guess-the-password
attacks to the point where they wouldn’t be viable.

The other technique is to complete lock an account after more than
a certain number of wrong passwords have been entered. This might
lead to a denial-of-service attack, which would have to be balanced
against the possibility of accounts being comprimised.

moo • February 19, 2009 4:19 PM

@Anon Y. Mouse:
Those are good ideas, but they only work against online attacks (online authentication systems are those where you are challenged by a system and have to send a response back to it to prove you deserve access). Thats the same reason a bank PIN is pretty secure despite being only a 4-digit number: you only get about 3 random guesses before the ATM decides to take your photo and swallow your card.

But there are lots of cases where you don’t have an online system in the loop to do the authentication, or where you do but a hacker gets access to something containing the results of the algorithm (like a password file) and so the attacks become offline attacks.

andyinsdca • February 19, 2009 4:28 PM

Unfortunately, this essay assumes that a user has a single password to remember. Off the top of my head, I can think of 30 passwords I need on a fairly routine basis. Making it harder for me to remember my password means it’s more likely it’s going on the [postit under keyboard|password.txt on desktop|whiteboard]

Roy • February 19, 2009 4:58 PM

SecurID can be made to work very well. Attach the token to the ID badge, require the ID badge to be in plain sight at all time, and admit no one through the front gate without a badge. If someone leaves home without the badge-and-token, they’ll have to have it brought to them by a family member or they’ll have to retrieve it themselves.

Peter • February 19, 2009 5:16 PM

Whatever happened to the idea of blocking entry to the account
for a few seconds when an invalid password is entered?

Most places do this, but Twitter didn’t. So when a hacker attacked a Twitter account, there was no lock out, no throttling, no IP blacklist, nothing to stop them from hammering the server with a dictionary attack. Plus the added bonus of the account being an administration account, so it could do lots of deliciously evil things.

http://blog.wired.com/27bstroke6/2009/01/professed-twitt.html

Curmudgeon • February 19, 2009 5:39 PM

@andyinsdca:

Good point. Solutions that implicitly assume users have only one password to remember aren’t good enough.

I have 154 passwords in my PasswordSafe database. Switching even the most critical 10% to two factor identification or a rapid rotation scheme would be completely impractical.

Renee • February 19, 2009 5:41 PM

I have real doubts about password rotation systems that force the user to switch passwords regularily. It could be argued that such an arrangement makes the whole system less secure.

I worked for some time in an environment with such a policy (just a windows domain with 60 days expiry on password). I found my self starting to use the same password again and again, only with a counter post-fixed to it (swordfish1, swordfish2, swordfish3). I also found out from a few co-workers that they also used the same arrangement.

Now, I know this is not a very smart security decision but as a user I am forced to remember a whole lot of passwords. It is just too much hassle to remember new passwords.

jeff • February 19, 2009 5:49 PM

@ Ping-Che Chen

For example, supposed that it takes 100 days on average to guess a password, you should be quite safe if you change your password every 50 days or so.

I think you have your probabilities wrong. At least if I remember my college probabilities class correctly. If you can guess a password in 100 days on average, then it doesn’t matter whether you change the password every 50 days or not. You’ll still guess the password “on average” every 100 days, or near about.

Think of it this way, regardless of whether you are systematically trying every password or randomly guessing, if you average 100 days, that means that you’ll exhaust 50% of the password-space in that time, or 25% every 50 days. So if you reset your random search every time the password changes, you’ll have a sequence of 25% probabilities of guessing the password. That’s a 75% chance to miss it within the first 50, only a 56% chance to miss it in 100 days, a 42% chance to miss it in 150, 31% chance in 200 days, etc. The 50% mark is at 120 days. Not really that safe.

What the frequent changing does is increase the maximum time to guess a password. Without the frequent password changing, its 100% guaranteed in 200 days. With the password changes, it takes a bit over 520 days to get to 95% and 800 days to get to 99%.

In any event, my guess is that there aren’t many passwords that fall in that 100 day range. Either they are easy to guess (e.g., your daughter’s name with a 1 in place of the L) or extremely hard (12 random upper/lower/numeric/special characters).

Jeff

NM • February 19, 2009 5:55 PM

I’m currently involved in the beginning of a PCI-DSS certification process. The auditor disagrees with me on the generated random password in the wallet idea with me. He says that it would make pen tests dead easy for him.
For me, user selected passwords are inherently insecure, especially so when coupled annoying restrictions — must pick a digit! must have a non alphanumeric character! must change every 30 days — because the result is that from what I can see, most people use something like “password1!”, and then “password2!” and so on the next month. Basically, you can guess everyone’s password in a couple tries if you know last month’s, so the whole thing about changing it monthly is completely useless.
What are you people’s thoughts on this?

jeff • February 19, 2009 6:13 PM

I hate to double-post, but this got me thinking. If you measure the password change interval as a % of the time it would take to randomly guess a static password, you can calculate the increase in the time it would take to randomly guess a changing password.

I did the math and I came out with a surprising result. So much so that I don’t trust my math. According to my calculations, the MAXIMUM increase in the average time to guess a changing password over a static password is 38.63%. And that’s with basically continual changing.

The equation that I’m using is:

where
i = password change interval in days / # days to exhaust password-space with random guessing, and
r = result expressed as a percentage of the average time to guess a static password

r = (ln(0.5)/ln(1.0-i))/(0.5/i)

so, as i approaches 0, r approaches 138.64% (give or take, I didn’t do the calculus, just used a really, really small i).

If that’s right, then an average of 100 days to guess a static password becomes an average of 138.64 days to guess a continually random password.

Why are we going thru all this grief for only a 38% increase in average hack time?

The only way to avoid this problem is increase the time necessary to exhaust the password space. And as others have written, requiring frequent changes actually reduces the effective password space since the passwords have to be that much easier to remember. So, this truly does seem to be counterproductive.

Jeff

Moderator • February 19, 2009 6:26 PM

Ward,

I checked with Bruce and it turns out that’s a change the Guardian made for some reason. It should indeed say that the code changes every minute.

There are, or at least used to be, some tokens that do change codes every time you press a button — a few years ago I used a Secure Computing token that worked that way. Maybe the Guardian’s copyeditor had one too.

John Hardin • February 19, 2009 6:50 PM

Whatever happened to the idea of blocking entry to the account
for a few seconds when an invalid password is entered?

A legitimate (human) who simply mis-typed their password wouldn’t
even notice, but it would slow down automated guess-the-password
attacks to the point where they wouldn’t be viable.

That’s not an obstacle to a virus sitting on the local network, and that’s only trying ~200 password guesses. It can be patient.

The other technique is to complete lock an account after more than
a certain number of wrong passwords have been entered. This might
lead to a denial-of-service attack, which would have to be balanced
against the possibility of accounts being comprimised.

I seem to remember discussion of widespread reports of unexpected corporate account lockouts when this first appeared – that might have been the first clue systems were infected with something trying to propagate via domain account password guessing…

randall • February 19, 2009 7:17 PM

One thing I might have mentioned: we can block attacks against even relatively weak passwords by just limiting how many rapid-fire login attempts we get before we recognize and shut off an attack. If you’re talking about a server’s administrator password, it takes tricky engineering to make sure your ratelimiting doesn’t enable a DoS, but it’s still possible.

Second is that it’s kinda hard to set a good password policy. If you just require numbers, everyone will choose “password1” instead of “password” — not much more entropy.

System-chosen passwords (pronounceable, or composed of a few random words) are an approach, but, of course, you don’t want to force someone to remember a bunch of random passwords. We use them at the small shop where I work, but I don’t know what I’d do if I were setting policy for a huge corporate IT dept.

Matt from CT • February 19, 2009 7:22 PM

I believe at this point in time, our working assumption and what security professionals should be emphasizing is this:

We should assume usernames and passwords are under active surveillance by organized groups.

Today’s computing power is such that data minining does not require state sponsorship like the NSA. Organized crime certainly has the resources to do so. If not state sponsored by Russia or China, I would not be surprised to find organized criminal syndicates in those countries acting with tacit state approval. Nor would I put past NSA or other Western intelligence organizations to be gathering and building a database of usernames and passwords they happen to catch passed in the clear for future use.

Most people use variations of the same username and password. Start building up a decade of security breaches on various sites, you’ll probably find a pattern. Now you use that in a targetted attack — maybe you manage to breach a bank that had the passwords well encrypted, but you get a valid list of usernames. Rather then a true brute force, you use the passwords you’ve previously collected for that user or similiar usernames. Just try one or two a day so it doesn’t trip alarms.

We should assume username and passwords are collected and traded just like other information, such as selling credit card data and valid email addresses. We should assume that data is actively, and if not current it will soon be, subject to data mining operations that will quickly break the simple password patterns most people use.

Your other personal information like city of birth and grandmother’s maiden name likewise will be information for future datamining by nefarious persons of both crime and government.

That means we need to divide our systems.

A simple password used for “throw away” systems, say to post comments on newspaper sites. Something you don’t mind if gets breached.

For systems we are concerned about, and don’t have two-factor authentication, we need to develop passwords that are not easy to guess.

Let’s take an example I’m starting to use (this is for Linux, Windows folks will need their own tools):

$ echo mybasicpassword@www.yahoo.com | sha256sum
9a7c3ff19da0207cae4c4c7f820d38397f672a47500795c4f56d6b45fe578603
$ unset HISTFILE

Then figure out some pattern from the hash that you use. Say acf1d00c as your password. For a trusted system you use daily, throw it in Password Safe.

A wallet card or note taped under the keyboard that happens to have the whole hash printed out that you chose your known pattern from would also be relatively secure even if it fell into hostile hands.

Obviously change the name of the company (@whoever) between services. unset HISTFILE gives you a bit more protection, so if the .bash_history or similiar files are breached you haven’t given a big clue how you’re generating the passwords.

While I realize there’s plenty of random password generators around, I think the problem is they are random random. If you lose them, you’ve lost them. While it’s still a pain…having a way to recreate the passwords easily will reduce the desire for people to record these difficult to remember passwords in six different places.

The system I describe, I believe, is relatively easy to remember how you create your passwords while at the same time making them extremely resistant to data mining attacks.

randall • February 19, 2009 7:26 PM

@Ward, Moderator:

Some competitors to SecurID act like the garage-door system you describe: you press a button to get a password, and if you press it too many times without authenticating, you have to do a slow, manual resync process. It’s probably a patent workaround. Anyway, that’s what the Guardian editor was probably thinking of.

And it’s kind of cool that we have a pseudonymous Moderator. 🙂

Glenn • February 19, 2009 9:05 PM

Whatever happened to the idea of blocking entry to the account
for a few seconds when an invalid password is entered?

Old Linux systems used to do that: after two guesses, each further guess would impose five seconds more delay. It was very nice to make a typo once and not be forced to sit around pointlessly (as current Linux systems do), and it prevented fast brute-forcing–at least, on a single connection. To work properly, it’d need to share the delay among all parallel connections.

There’s still a basic flaw: it only slows down brute-forcing from a single IP. If your worm is controlling ten thousand IPs, then each of them can connect independently to each target machine, which will more or less bring it back to brute force speeds. (Then, each IP can do the same brute force attack on any number of target machines, each making a few guesses per minute per machine.)

another bruce • February 19, 2009 9:50 PM

then there’s…

pa55word
pa5sword
pas5word
passw0rd
pa55w0rd
pa5sw0rd
pas5w0rd, and lest we forget the creative kinkies among us,

assword and its siblings. unless you limit the number of attempts, eventually computers will get smart enough to guess these and more. you could go to something like a private key input, but that could be compromised by a flaw in the channel, hacking the device the user stores it on, or torturing the user. the ultimate gold standard for authentication will be something relatively simple and unknowable to anyone in the universe, including the user, until she has to input it on cue. it isn’t clear at this moment that even bruce #1 is smart enough to figure out what this could be.

PS • February 19, 2009 11:56 PM

Weak security that’s easy to use will help more people than strong security that’s hard to use. E.g.: door locks.

(I think this quote was by Rob Pike)

Walt • February 20, 2009 12:15 AM

A long time ago a 1 page memo about how to select a passward was circulated. It started with not a word in any language and got increasingly bizzare until the final line which said “there is only one known password which satisfies these restrictions. ask your manager.”

JH • February 20, 2009 3:04 AM

“but banks and some online gaming worlds have taken to using them—sometimes only as an option, because people don’t like them”

..pardon me but logging on to my online bank should be very very secure. Having tokens as an option because people dont like them.. that is a very stupid attiditude

Nick • February 20, 2009 3:43 AM

As I blogged at http://nick.brown.free.fr/blog/2008/09/protecting-us-from-our-own-passwords.html, there would be far fewer calls for in-house password support if people were allowed the option of seeing their password instead of blobs. Given that a substantial number of people have their password on a Post-It stuck to the monitor, a closed office door, no Tempest issues, or a keylogger trojan stealing the password, hiding what they’re typing from their own eyes does not add much value…

Ping-Che Chen • February 20, 2009 3:58 AM

@jeff,

As I said in my post, I agree that password rotation is kind of pointless now, because the time it takes to crack a bad password is already ridiculously low. A good password, on the other hand, may still take years to crack. Although, one has to take account of the improvement of computers. A 8-character random password was secure maybe 10 years ago, but it’s not very safe now. Therefore, a 16-character random password may be safe now, but it probably won’t be safe 10 years later. Therefore, in some sense you still have to change your password, but on a much longer time period (such as, change it once per year).

IMHO, a two-way authentication system like SecurID is a better solution in general. Because no matter how good you password is, it’s still quite possible that it may be recorded by a virus (this is, to my understanding, behind the majority of on-line game account attacks). A SecurID makes it harder: you have to get both your target’s password, and his SecurID, to mount a successful attack.

Clerkendweller • February 20, 2009 4:59 AM

“If a given authentication system let the bad guys in one in a hundred times, a bank could decide to live with the problem—or try to solve it in some other way.”

Yes balancing the risk is part of this. Monitoring what users do after authentication is just as important. A malicious user may be using valid authentication credentials.

Rich L. • February 20, 2009 5:26 AM

@Nick

You certainly raise an interesting point when it comes to showing/not showing the user their password as they type – on a large scale, there could be a significant change in the rate of passwords being forgotten.

However, consider the phsycological impact of not seeing your password as you enter it – you’ll maybe feel that it’s special, it’s secret, and it should be treated with care. Perhaps this definite distinction between username and password is required?

I actually wrote a password related post yesterday – it’s an interesting concept that could perhaps be applied to other areas (though I certainly don’t claim it to be a practical defence):
http://idlescan.co.uk/2009-02-19-1-exploiting-the-curiosity-of-hackers.html

Rich

Roger • February 20, 2009 6:16 AM

@Jeff:

The equation that I’m using is:

where
i = password change interval in days / # days to exhaust password-space with random guessing, and
r = result expressed as a percentage of the average time to guess a static password

r = (ln(0.5)/ln(1.0-i))/(0.5/i)

Hello Jeff, I got a very similar result with some simplifying continuity assumptions, but then realised my continuity assumptions are not valid in the limit i -> 0. I think a better result is as follows.

  1. Let the password space be of size N, all passwords assumed equally likely. (If the defender does not choose strong passwords, you might like to consider N to be the size of a dictionary which is very likely to contain the password. Of course in this case it is not really true that each password is equally likely.) The attacker gets to try one guess per time t.
  2. Then in the static case it is easy to see that the mean time to successfully guess a password is tN/2
  3. For the limit of the dynamic case, the defender changes passwords after every guess. (It clearly achieves nothing to do it any faster.) Thus every guess is an independent trial with success probability 1/N. Hence the mean time is:
    t. 1/N + 2t (1-1/N).1/N + 3t (1-1/N)^2.1/N + …
    =t/N ( 1 + 2q + 3q^2 + … ) where q = (1-1/N)
    = t/N . 1/(1-q)^2
    = t/N . 1/(1/N)^2
    = tN

Thus in the limiting case, dynamically changing passwords doubles the mean attack time. Which is slightly larger than 2ln2, but still far too small an increment to be useful.

  1. Now suppose the rate of change is reduced so that attacker is able to try n passwords before a change, where 1 < n < N. We assume the attacker knows approximately what n is, and so just cycles through the same n passwords until one works. In that case, the mean time is:
    nt/2 . n/N + 1.5 nt . (1-n/N) . n/N + 2.5 nt . ( 1-n/N)^2.n/N
    =n^2t/(2N) ( 1 + 3q + 5q^2 + … ) where q = (1-n/N)
    =n^2t/(2N) (1+q)/(1-q)^2
    =n^2t/(2N) (2-n/N) (N/n)^2
    =(2-n/N) tN/2
    =(2-i) tN/2 using your previous definition of i.

As i -> 0, this is the same result as result 2. As i -> 1, it is the same as result 1, as expected.

BF Skinner • February 20, 2009 7:05 AM

@root “Why in the world are IT administrators still using easy-to-guess passwords?”

Because they can. (T.EvilSysAdmin)

Of all the people in a system sysadmins can bypass the server security controls and due to the number of servers they are managing (dozens?) they have more motivation then most to keep it simple.

It’s the only reason I see to run password cracks against etc\passwd or sam.

AJ Finch • February 20, 2009 8:49 AM

“but banks and some online gaming worlds have taken to using them—sometimes only as an option, because people don’t like them”

— I suspect it would be more accurate to say that:

“people who haven’t had their identities or money stolen don’t like them”

AppSec • February 20, 2009 8:58 AM

@Jeff, Roger:
Those calculations aren’t valid unless the victim/defender is changing their password at random times. Attackers can generally figure out forced time frames and can restart their process at that point.

My thoughts on password changing is just like selecting a card out of a deck:
I select a card, the “magician” has 52 chances to guess it. Only I don’t know what card he is guessing. If he knows that I’m changing that card every 5 minutes, he’s going to start over on that 5th minute or sometime there after. If I change it every 3rd minute, then he runs into an issue and a larger problem.

Most password expirations are 45, 60 days, or 90 days. I don’t need to know when it changed, as long as it is changing on that specific time period I can re-run my brute force attack.

Give a 2 second delay on all login attempts, and enforce strong password creation, effective monitoring and alerting (you don’t even need to lock the account out right away) and you solve the problem.

For instance: track ip addresses, if you notice 10 multiple attempts from the same address, flag that address and see if the attempts conintue. If you notice 10 attempts from different addresses within a short period of time, you problem have a bigger issue.

Bill • February 20, 2009 9:08 AM

I’m big on pass phrases rather than passwords. Pass phrases can be both easy to remember and secure. For example:

I can’t believe it’s not butter

That’s a 31 character password. The only problem is the probability of making a typing error.

As for the Conficker worm – it also seems to attach itself to Explorer. So, if a domain administrator logs onto an infected machine, the worm can propagate throughout a domain using that account without needing to crack any passwords.

Matt from CT • February 20, 2009 11:36 AM

I can’t believe it’s not butter

That’s something that makes the best of a bad situation.

I believe increasingly we should emphasize that a password only system can NOT be considered secure anymore under any circumstances. What can’t be brute forced or rainbow tabled easily is likely to be data mined.

We can take steps that are fairly extreme to make our passwords immune from data mining but the vast majority of people will not do that. Not until we have the proverbial Digital Pearl Harbor.

We have to assume there is an active data mining effort underway regarding breaches in usernames and passwords — it’s too tempting of a fruit to assume otherwise.

Financial and critical infrastructure needs to be secured behind two factor authentication. Maybe that means your ATM card needs to become a hybrid ATM/SecureID card.

Ponter Boddit • February 20, 2009 12:21 PM

The “treasury direct” system the Treasury offers for buying and tracking savings bonds is an excellent example of how not to implement strong security.

To start with, you enter your password by clicking your mouse on a “virtual keyboard” with randomly arranged “key” buttons. Of course each click echoes as a “blob,” so there’s no way of knowing if you’ve made an error until you’re done– at which point you have to start all over again with your account number if you made a mistake.

If you correctly entered your password, you’ll get another “virtual keyboard” to use with a token, a card they send you with a serial number and a matrix of random characters. First select the card serial number from a pull-down of choices. Then it presents three sets of coordinates from the matrix on the card. You enter the character in the matrix corresponding to each coordinate using the “virtual keyboard.” The entries again echo as “blobs.” If you make any error in this painstakingly fussy process, you get to start all over again entering your account number and password.

I suppose this really is strongly secure. Or at least it gives the appearance of entering an impregnable fortress where your savings bonds are really, really safe. But is it really commensurate with the hassle of using the system? If almost looks like they brought in Security Theater Consultants from the TSA to design it.

Shane • February 20, 2009 1:38 PM

I don’t know about the rest of you, but being a generally well-informed and healthily paranoid end-user, I make my passwords as insane as possible.

One of my major issues, and I run into this just about everywhere, is password limitations imposed by the sites / applications / systems themselves.

I agree that user awareness, especially the IT ilk (who need to wake the hell up and stop being lazy-brains about their passwords) is essential, but we really really really really need a sea-change in the development world. There is absolutely no reason under the sun that, even a decade ago, a system should require passwords to be under a certain (generally ridiculously small) length. I mean, a char field in the DB for your first name has more storage than your password? WTF? Storage is a non-issue folks, especially today, and unless an application or protocol is using a particularly finicky algorithm that imposes key-length restrictions (many of which are quite long enough anyhow), there is absolutely no reason to limit password length.

Case in point, MySpace. Last I checked, it imposed a 10 character limit on your password (but admittedly allows most non-alphanumerics, which is something I cannot say for a large number of other sites / systems). That is, of course (jaw-clenched), overlooking the fact that it’s sent in the clear anyhow….. sigh

A 10 character password limit, even allowing any combination of letters, symbols, or case, is (at least nowadays and in my mind) a joke, imposing about as much security as a ‘No Trespassing’ sign with nary a soul for a hundred miles.

Changing the outlooks and poor habits of millions of end-users around the world will take a number of catastrophes, either personal or pandemic, but getting the much smaller subset of the above, mainly IT admins and developers, to stop being simpletons about their authentication methods / constraints, seems a more approachable goal in the near future.

Like many of Bruce’s posts of late have pointed out, psychological road-blocks hamper the propagation of more security-aware habits among the masses simply due to the fact that most people don’t experience breaches of their accounts to any degree large enough to shake them out of their bad habits. Much like jerk-wad drivers that don’t change their poor driving habits until they (or someone close to them) experiences some kind of tragic accident, despite the fact that auto accidents kill more people than just about anything out there per year. The very least we can do, and something we can do NOW, is give them all safety belts, dependable breaking systems, speed limits and stop lights. We can’t expect that everyone will use them, but we have to provide them before we can nay-say.

Granted, imposing minimum length and character requirements in a password can lead to even more bad (and arguably less-secure) habits among users, perhaps upping-the-ante (as it were) little by little, quarter by quarter, can help ease end-users into a little more security in the end. Certainly the majority of people who have historically used a 7-character lowercase string for their password wouldn’t cry foul if the minimum length was raised to 8 characters, and imposed a mixed case requirement. They’d just add an ‘A’ at the end or similar. Coupled with strict policies on password changes every 3 months (or whatever), these small requirements changes (over time and cumulatively) would certainly be more digestible for the masses than an immediate switch from a free-form password less than 8 characters to a password over 10 characters containing at least one mixed case letter, one number and one symbol.

Also, this allows for some nerd-related fun should anyone give you trouble; just quote The Simpson’s:

“… even monkeys can memorize 10 numbers. Are you stupider than a monkey?”

Kind of spewing off into a tangent here, but it reminds me of how, prior to the late nineties, I remembered 40+ full phone numbers of interest, and now, 50% growth in the probability of a brain tumor later, I seriously only remember 3: my mother’s, my girlfriend’s, and my own…. lazy brains + technology = sigh.

Of course, people will even complain about a free meal if it’s given to them the wrong way. In the end, we may have to start giving the ‘user complaint’ issue a lower weight when calculating these trade-offs. No one likes change until their neighbor tells them it’s alright (well, generally speaking), and while I condemn dictatorships and fascism of all types, sometimes you have to give them the fruit juice they need, but tell them it’s just a new kool-aid flavor… you know, to save them from themselves, haha.

Kyle Wilson • February 20, 2009 2:49 PM

In my experience, passwords fall into two distinct groups. Internal passwords are used to protect resources from friends and associates. External passwords are used to protect resources from outsiders. An ‘internal’ password that is relatively weak, but easily memorized works reasonably well (unless you have lots of hackers or spies as friends). An ‘external’ password that is strong, but written on a yellow sticky under your keyboard also should work well.

The chances of a coworker or friend using the password that is visible on my desk to harm me are relatively small. The possiblity that a password that is weak, but easily memorized being compromised (used for an internet based resource) are large. This seems to suggest that yellow stickies aren’t all that bad (at least as long as you don’t have a web-cam staring at the bottom of your keyboard). Even better if you lock your office door when you’re not there…

AppSec • February 20, 2009 3:01 PM

@Shane:
I mentioned this in the other blog. Forcing password changes is useless unless the time to live of the password is random. An attacker will know the valid time length and be able to adjust accordingly.

This whole concept of “ROI” security (ie: facebook versus a bank site versus a blog post) is like saying: we’ll only build a car with seatbelts if it goes on a highway.

mumbly • February 20, 2009 3:18 PM

“…and the second makes a guessed password less valuable.”

I don’t believe this is true. As soon as a cracker has access to an account, they can do whatever it is that they want, including, in most cases, making it so that changing a password after the fact won’t have any affect.

This is why I think requirements to change passwords after some number of days is not just unhelpful, but is in fact bad policy. You end up with poorer passwords if folks have to change them often and you get no improvement in security. This is definitely a case of closing the barn door after the horse is out.

Bill • February 20, 2009 6:49 PM

@Shane wrote
< One of my major issues, and I run into this just about everywhere, is password
< limitations imposed by the sites / applications / systems themselves.

I agree that the limitations many systems impose on passwords is too restrictive. I have seen many banking websites only allow alphanumeric passwords – no punctuation characters.

However, there are two types of password attacks – online and offline.

Online attacks are relatively easy to defend – just employ delays between attempts and account lockout (perhaps automatically re-enabling the account after a certain time to reduce DOS attacks). So, passwords do not need to be very secure to protect against online attacks (that’s why the banks issue four digit PINs).

None of the above will help with offline attacks. The best defences against offline attacks are strong passwords (complex and long, with long generally being better[1]), slow algorithms, a salt and making sure that no one can get access to the password store in the first place (the reason *nix systems now store passwords in /etc/shadow instead of /etc/passwd).

If the password store is secure (e.g. bank PIN numbers) then relatively weak passwords may be good enough.

[1] My keyboard has 95 characters. According to my calculations, that would give 6,634,204,312,890,620
possible 8 character passwords (more if you include shorter passwords). There are 64,509,974,703,297,150,976
possible 14 character passwords using just the 26 keys of the lower case alphabet. In this instance, length beats width.

Roger • February 20, 2009 7:01 PM

@AppSec:

Those calculations aren’t valid unless the victim/defender is changing their password at random times. Attackers can generally figure out forced time frames and can restart their process at that point.

and

Forcing password changes is useless unless the time to live of the password is random.

Actually, my calculation no. 2 does not depend in any way on knowing either the password change time or frequency. It shows that the best improvement that dynamic passwords can give — even if change times and periods are totally random — is at best a factor of 2. This is far too small to be useful; if a cracker previously took 5 hours to break a weak password, pushing that out to 10 hours is no real help. And that factor of two only applies if the period of change is faster than the mean time to guess a password; since many passwords can be guessed in a few hours, and few password expiry policies are tighter than 1 month, they then have no effect whatever. Further, if the attacker can guess the approximate period of the changes, he can reduce that factor of 2 further (note that for this reduction, the exact update times don’t matter, only the period.)

In contrast, there are a number of strategies that have been tried, with which much larger gains in mean strength can be achieved — factors of hundreds or thousands times stronger — and these work less well, if at all, if passwords have to be changed frequently. As such, most security professionals now agree that password expiry policies are not just useless, they are actively harmful, and must be abandoned immediately.

Having said that, while password expiry is useless for making it more difficult to attack a password, it can be useful for mitigating the damage from an already known password. Other commenters on this blog have observed that this doesn’t really apply to a system intruder: once the intruder gets in, the damage is done in seconds. However it can reduce the insider threat attributable to the odious practice of password sharing. Many organisations have one or two passwords which are known by several or even many people, and consequently eventually get known by nearly everyone, and are very difficult to have changed. This is especially a problem if someone who does know the password, or is suspected to, leaves the organisation under a cloud. Occasional forced password changes make shared passwords impracticable, and eliminate the risk of long-gone employees still knowing a set of working credentials.

Stephan • February 21, 2009 8:58 AM

This reminds me of a related issue – encryption key length. If your fancy AES 256 encryption scheme has just an 8-10 (or even a few more) character password protecting it (say, on boot-up for whole disk encryption), does it really make a difference that the total AES 256 keyspace is too big to brute force? The total keyspace may be too big to brute force, but the “passwordspace” of the length of password someone can remember is not. What am I missing?

Jonathan Wilson • February 22, 2009 9:36 PM

I hate mandatory password rotation and concur with those who say it just makes it harder to remember things (and more tempting to write them down). Which is of course why companies that DO implement password rotation should also implement policies prohibiting passwords (or anything else confidential/important) from being left visible on a desk (or attached to a monitor/keyboard/etc)

Fred P • February 23, 2009 9:36 AM

I found the use of key patterns (like zxcvb) interesting; my second group of passwords usually had a key pattern along with another element.

Shane • February 23, 2009 10:37 AM

@AppSec, others

For the record, I certainly wasn’t implying that a forced password expiration at predictable intervals was an added security measure, rather, I was illustrating an example of how to gradually implement stronger passwords on an enterprise scale, with the idea being to minimize gripes from the user base by strengthening the password policies themselves gradually over time.

@Bill

I do believe that stronger passwords would increase the difficulty in performing a successful attack, online or off, even (in many cases) on systems with delays and lockouts. It’s been illustrated a number of times how even these measures can be bypassed in a number of ways, to say nothing of the ddos possibilities on those systems.

Bank card PIN numbers provide a relatively secure trade-off being that they are easy to remember, and brute force can only be applied by someone standing at an ATM for hours, some of which may even take the card and destroy it after a number incorrect attempts. This is also a two-factor authentication method, since it requires ‘something you have’ and ‘something you know’. So, while I understand your point, I don’t think it’s relevant in terms of sites/systems being too restrictive when it comes to password creation.

Like I said, there is really no reason at all to restrict the characters in a password to alphanumerics, nor is there any reason to restrict it to a maximum length (IMHO). It’s fairly counter intuitive if you ask me.

However, I would add that having too high of a minimum length requirement could actually net a decrease in overall security, if an attacker can assume that most (if not all) users will use a password of *exactly the minimum length.

greg • February 23, 2009 11:38 AM

I know many people have moved on.

But really passwords can be quite secure. How the hell can any online attack work in a password system without that system being insecure in the first place? The weak link is suppose to be off line attack. 2-5 seconds between password tries should work fine.

Hell I get ssh login attempts on my home machine about 2 times daily. We have quite simple but long passwords. ie its letters from a pass phrase. And yet nothing gets in.

I did get sick of the junk logs too, so I also use sshutout.

Stephane Benoit • February 23, 2009 12:32 PM

I have read many comments on password rotation. Rotating your passwords often has too many human factor drawbacks that I would risk. I prefer my users have a more complex password that they would only change 1 a year. This way that don’t have to write it down and stick it under their keyboard…

DaveC • February 23, 2009 9:15 PM

Forced rotation is a technique definitely well past its sell-by date, and as many have observed here, it causes more problems than it solves, but it is often forced on more knowledgeable IT practitioners as it is mandated by external policies like PCIDSS and SAS-70.

Such public policies are inevitably very slow to change, and thus full of legacy content – PCIDSS still specifically calls out RC4-128 as an adequate session encryption method; personally, I was already phasing out RC4 for browsers when PCIDSS 1.0 was published (IE6 being the last holdout 🙂

Such policies also contain a significant amount of security theater – it’s not about being secure, it’s about sounding secure to a lay person.

Anonymous • February 24, 2009 11:01 AM

Password updating might be useful in certain circumstances.

Suppose an encrypted database of user information (including site passwords) for a public site was obtained but needed months to decrypt.

By the time the database was cracked, the password would have moved on

AppSec • February 24, 2009 12:31 PM

@Anonymous:

If the password file was obtained once without being notice, it will be obtained again.. and again.. and again..

Vatos • February 25, 2009 4:48 AM

A fair point AppSec.

With respect to the human factor disrupting plans, this has been known about for years. An episode of The Champions (espionage show) “Reply Box No 666” mentioned it which shows that the topics of security and spying are closely related.

It also comes down to incentives. Bruce mentioned two stories, one that the financial traders took “bad” risks because they had an incentive to do so and the other that police made fewers arrests because it was inconvenient to record the arrests.

Ultimately, politics is in the mix. Security is not seen as a vote winner and thus politicians are not encouraged to take a good look at systems used by hospitals to provide security and to pay good money to train IT staff.

I am not sure how we make security a vote winner

PasswordSafeFan • March 18, 2009 10:41 PM

I’ve never thanked Bruce and all else responsible for Password Safe, which I started using a while back. And I just thought it would store passwords — who knew that it would also auto-browse to the site, auto-enter your U+P, and log you in? Cool! (Lazy!) Thanks all!

Note that PWS will generate random PWs for you according to rules you select, and that there is a pretty good (crypto-strength-pseudo-) random pw generator at http://www.grc.com/pass, over SSL connection, choice of hex, ASCII, or keyboard characters, up to 64 length, with the page expired before it’s sent to prevent replay attacks.

@Bill: For a pw that must be remembered (like the key to PasswordSafe lol), I like acronyms even better. Yours becomes “Icbi’nb” (keep the contraction to introduce a punctuation character). Needs numbers:
“Mom tried this in 1996, and she can’t believe it’s not butter! (“I” is too common to start a sentence). = Mtti1996,asc’bi’nb! = 86% or “very strong” at Passwordmeter.com. Easy to improve on from there: The 3rd time Mom and I tried “I can’t believe it’s not butter” was better than the 2nd. =T3tMaIt”Ic’tbi’nb”wbtt2. Too long for the above, but probably off the map.

@Shane: You can remember your own phone #? I can’t. How often do you call yourself? 🙂

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.