The Psychology of Password Generation

Nothing too surprising in this study of password generation practices:

The majority of participants in the current study most commonly reported password generation practices that are simplistic and hence very insecure. Particular practices reported include using lowercase letters, numbers or digits, personally meaningful words and numbers (e.g., dates). It is widely known that users typically use birthdates, anniversary dates, telephone numbers, license plate numbers, social security numbers, street addresses, apartment numbers, etc. Likewise, personally meaningful words are typically derived from predictable areas and interests in the person’s life and could be guessed through basic knowledge of his or her interests.

The finding that participants in the current study use such simplistic practices to develop passwords is supported by similar research by Bishop and Klein (1995) and Vu, Bhargav & Proctor (2003) who found that even with the application of password guidelines, users would tend to revert to the simplest possible strategies (Proctor et al., 2002). In the current study, nearly 60% of the respondents reported that they do not vary the complexity of their passwords depending on the nature of the site and 53% indicated that they never change their password if they are not required to do so. These practices are most likely encouraged by the fact that users maintain multiple accounts (average = 8.5) and have difficulty recalling too many unique passwords.

It would seem to be a logical assumption that the practices and behaviors users engage in would be related to what they think they should do in order to create secure passwords. This does not seem to be the case as participants in the current study were able to identify many of the recommended practices, despite the fact that they did not use the practices themselves. These findings contradict the ideas put forth in Adams & Sasse (1999) and Gheringer (2002) who state that users are largely unaware of the methods and practices that are effective for creating strong passwords. Davis and Ganesan (1993) point out that the majority of users are not aware of the vulnerability of password protected systems, the prevalence of password cracking, the ease with which it can be accomplished, or the damage that can be caused by it. While the majority of this sample of password users demonstrated technical knowledge of password practices, further education regarding the vulnerability of password protected systems would help users form a more accurate mental model of computer security.

Tags: , ,

Posted on March 2, 2006 at 11:46 AM • 63 Comments

Comments

Matt Austern • March 2, 2006 12:53 PM

The problem, of course, is that everyone knows the recommendations for good password security and everyone also knows that it is impossible to follow all of the recommendations simultaneoursly. (Use passwords that can’t be guessed even by someone who knows you and your interests well. Use long passwords that include letters of both cases, numbers, and symbols. Use a different password for each site. Vary passwords regularly. Never write your passwords down.)

One of the reasons people get this absurd advice: each site gives password advice for that site alone, because each site only considers its own security problems. But from the point of view of a user, each site is just an incremental addition to an overall password management problem. A bank probably thinks that its job is to solve its own banking problems, not to solve users’ overall password management problems.

If people are given advice that’s impossible to follow, it should come as no surprise that they will do something else.

bob • March 2, 2006 1:05 PM

I have reached password saturation. At my current job I require 7 different passwords to get through an average day. They all have mandatory criteria which differ, and they all require me to change passwords at varying intervals. So I not only have to remember each one, I have to remember the last 8-15 of each system because I need to know which ones I can NOT use because they’ve expired.

Otherwise, when presented with a “mental password generation algorithm” (ie criteria), its like a pseudo-random number generator, I generate the same thing every time and its already been used – try again. Additionally, there’s probably 10 more that I only use occasionally.

And of course when you get in the loop of “generate password” – “nope that one cant be used” – “try again”; once you’ve gone through the loop more than 8 times you tend to forget what you just typed – so if it comes back “password change approved” you are no better off than you were before – you dont know what you just entered that was finally accepted.

Then at home I have probably 5 passwords I use daily, with another 20 that I dont use often enough to have a hope of remembering, I just automatically do the “cant remember password” process which actually means I use my SSAN and birthdate as my password and never have to change it.

Then in the reserves I have a further 5 or 6 which I use twice a month and they require me to change every other month (ie every 4 work days) and cant reuse, etc. I no longer can accept responsibility for remembering my passwords if I am not allowed to write them down.

What I want is an NSA approved secure PDA where I can store them ALL (of course if they had this, its no great leap to just using the PDA itself as a token of some sort).

Mark J. • March 2, 2006 1:44 PM

At the university here there is discussion about consolidating the various passwords into a single logon so users can get to any of their secured apps or sites. Some are very much for it (99% of users), and some are very much against it (sys admins and security folks). But even some of the security-minded folks complain of needing to enter several passwords an hour just to do their jobs.

I don’t know that there is a comfortable middle ground. Ease of use and security are almost always a yin and yang situation. More of one equals less of the other.

Alan Porter • March 2, 2006 1:46 PM

My first choice is to abandon passwords in favor if SSH keys.

However, since I must use passwords for a lot of things, I use PasswordSafe (originally written by Bruce Schneier) on a USB pen drive. I can carry it with me and run the application directly from the pen drive. The passwords are encypted using AES, and I can organize them into folders within folders. It features a “generate password” button that creates and remembers a string of gibberish.

This is about as close to “an NSA approved secure PDA” as it gets.

greg • March 2, 2006 1:55 PM

What about a if exlude offline attacks on passwords? Put that in the model, ie offline attack is a full security faliure. Cus if its always online, then you just put the needed delays in. We use exponetial delays, so 1 sec then 2 then 5 then 25 then well–you end up waiting a long time.

Yea, i know –but what if they do a offline attack. Well what about keyloggers? Its a password. It should not be securing the bank of england.

Anjan Bacchu • March 2, 2006 2:03 PM

hi bob/bruce,

I’ve been using your(bruce) password safe for more than 3 years now. This lets me keep all my password grouped into work/fun/dev/emails/blogs/finance/etc. I’ve also spread the word around but I guess people don’t embrace it easily.

I have lots of accounts — hence it’s a really tough proposition for me to remember. For a while, I was using password genererator bookmarklet.

Both these approaches assume that you have a master password which is not necessarily a bad idea. Both of these will generate a unique password for each site.

Bob : if I were you, I would use password safe and then have a group of work passwords and then rotate through the list (and you can have multiple lists) in a circular manner.

BR,
~A

Andrew • March 2, 2006 2:18 PM

@ Milan

Have you tried PasswordSafeSWT? It’s a Java implementation that can read the same database as the Windows version of password safe. I’m not sure if it’ll run on a Mac, but its worth a try. You can get it at http://tinyurl.com/dvzt6

Andrew • March 2, 2006 2:20 PM

@ David

Either a) you don’t, or b) logon somewhere else and use remote desktop. I use both methods.

Filias Cupio • March 2, 2006 2:21 PM

Password safe on a USB drive:

What if you’re away from home, go into an internet cafe, and find the computers refuse to run software off your USB drive? You could be completely shut out of all your accounts until you get home. (I certainly hope that internet cafe computers won’t run software off user-supplied media.)

Fred Page • March 2, 2006 2:40 PM

@Matt-
I think that’s why Bruce sems to favor writting down passwords (and sticking them somewhere relatively safe, like a wallet). Personally, since I’ve followed that logic, my password complexity has increased.

Longwalker • March 2, 2006 2:47 PM

If you’re using an internet cafe to access important accounts (i.e. anything with financial or reputational consequences), you don’t need a password solution. What you need is to have your head examined. Public computers are often loaded to the gills with keyloggers, password grabbers, and other malware. It is not prudent to use cafe computers to access anything more important than personal email.

If you need to access important accounts while away, bring your own laptop with all your PWs in password safe or in an encrypted file.

Henno • March 2, 2006 3:07 PM

@ Milan:

what about Keychain? It keeps your passwords in an encrypted database, and is intergrated right into the OS, works with Safari (not Firefox, though) and other iApps. And of course turn on FileVault for extra security…

fred • March 2, 2006 3:21 PM

Passwords where good enough 20 years ago. Maybe we need to find an another solution to be authenticated on a given system. I am like most of you guys I am tired of all these passwords and dying for an new solution.

-fred-

BenR • March 2, 2006 3:49 PM

I seem to recall reading that after 9/11, as businesses were getting back on their feet, there were situations where access was needed to files belonging to someone who had been killed in the attack. It was surprisingly easy in many cases for the coworkers of the deceased to guess passwords, which were frequently SS#s, pet names, etc.

Smoke • March 2, 2006 4:13 PM

I used to have a job requiring me to remember over 300 passwords of which I could have to use up to a third of them in any given day. Most seemed to have come from a random alphanumeric generator since they didnt appear to look like any particular word I could think of in any language I am aware of. Still, that did appear to be the limit of the security they were willing to impliment at the time I was there.

Ian • March 2, 2006 4:14 PM

I use a two-pronged solution.

I use KeePass to generate and save passwords, as mentioned by many others. However, I am horrible about backing stuff up, so I’m always afraid it will fail, so I’ve got a rolodex-like thing where I write all my passwords for different sites as well. That way if I lose the database, I haven’t lost the passwords.

My philosphy is that if someone breaks into my house, them reading my email is the least of my problems.

fatman • March 2, 2006 4:20 PM

What’s wrong with passphrases?

Think of a sentence, any sentence, something that can be remembered (e.g. my favourite food is pizza)

Result: a 26 character password which doesn’t have a hope in hell of being discovered by brute force methods and is easy to remember as it is personal to you. And in this case, it doesn’t matter that the passphrase is personal. Who is going to guess the particular way that you phrased the passphrase based on your interests, personal info or hobbies?!

Is there any problem with using that same passphrase with lots of systems? Not really – as long as you don’t reveal it to anyone.

And lets face it, if someone has a keylogger or other nefarious device or software attached to your system, they’re going to get all your passwords/passphrases, whether you use one password/passphrase or completely different ones for each system you use.

The only problem with passphrases is getting stupid senior management to understand that a passphrase is (a) easier to remember than a ‘strong’ password and (b) provides more protection against brute force attacks. For some reason, they freak out about the number of characters required.

Dave • March 2, 2006 4:20 PM

I use Roboform Passtogo (USB) and Roboform/PDA. Arbitrarily complex passwords, encrypted, and available on my PDA in case I can’t use my usb key. Yep, it costs $30 or so. But now I literally have a hundred or so passwords, no one who cracks one can try it on other sites etc.

jmr • March 2, 2006 5:28 PM

@fatman:

The problem with using the same passphrase on many systems is the assumption that the system securely handles your passphrase. There are plenty of systems out there that transmit or store passphrases in clear text. Once one system exposes your passphrase, all the systems you log on to are now vulnerable.

Avery • March 2, 2006 5:35 PM

Does brute force password cracking still happen? I thought that every system worth protecting was immune to that in this day and age.

Candide • March 2, 2006 5:39 PM

@fatman:

Think of a sentence, any sentence, something that can be remembered (e.g. my favourite food is pizza) Result: a 26 character password which doesn’t have a hope in hell of being discovered by brute force methods and is easy to remember as it is personal to you.

You’d be surprised how easy it is to brute force something if I know it’s an english(esque) phrase. That’s not a secure passphrase. I think Bruce’s “Applied Cryptography” has a good thing about the poor entropy of the english language: I’m sure you can find good websites on it, too.

Candide • March 2, 2006 5:41 PM

@avery

Does brute force password cracking still happen? I thought that every system worth protecting was immune to that in this day and age.

It’s definitely still kicking around, as a security validation thing, if nothing else. The advantage of brute force password cracking is when you have access to many passwords stored as hashes via the same algorithm — like on your average Unix box.

Tobias Weisserth • March 2, 2006 6:05 PM

pwgen and a small paper pocketbook I keep safe.

That way I can have many long and secure passwords for each account or login there is in my digital life.

For all the administration work I do I also use key authentication or where possible one-time key authentication like s/key.

I also like the idea of Bruce Schneier’s Password Safe programm, although I don’t know how secure your passwords are, while the programm is running and the password file is opened (unencrypted) in memory. Bruce, can you tell me if it is possible to access the part of the memory from other programms where your Password Safe programm puts the passwords after decrypting (if at all)? Is there a safe way to work around this problem?

Christoph Zurnieden • March 2, 2006 6:13 PM

Based on years of experience I can tell you: a human is neither able to produce a secure password nor to memorize one.
Even the first problem is not easy to solve. You can use a good automated password generator and link it to a well of good entropy–perhaps a hot cup of tea?–, but how can you deliver these carefully picked passwords?
It is simple in a single place: use a sealed envelope or something alike but it is quite complicated for the more remote places. Not impossible, there exist a couple of well known techniques, but nevertheless complicated and no user wants somthing complicated; the computer itself is complicated enough.
Eventually the user got its shiny new password, a bunch of funny signs, more similar to a comic figure swearing (yes, I have complaints about that rarely but regularly) then something usefull. And than they are told to memorize it! Sorry, but no way!
That is (probably) one of the reasons Bruce recommended to write them up and take care of the writ. That recommendation anihilates the memorize-condition and thus offers the possibility to trade time for some of the entropy. Because the security of a password is the answer to the question how may tries are needed to break it [NCSC1985a] and tries are defined in proportion to time the live of a weaker password can be shortened to get higher security of that password.
The people do not have to memorize the passwords anymore so it is only the little inconvinience left to change the password on the wit.

All of the above should be well known to any sysadmin worth the money, but it seems that it is very rarely implemented. Why? Because it must be convenient for the users to get new passwords everytime they need some? Yes, convenience for the users, Mr. BOfH! 😉

@Filias Cupio

I certainly hope that internet cafe computers won’t run software off user-supplied media

Some will with Javascript. I once sketched a small script (http://forum.de.selfhtml.org/archiv/2005/10/t116299/#m744023 and the following post. Works in Mozilla 1.7 IIRC. Uses XTEA and MD5 so do NOT use except for educational purposes! Public Domain of course) but dropped it. It protects against the simplest keyloggers only–not very usefull except of some very narrowly defined circumstances e.g. a keylogger in the cable between the key- and the motherboard.

CZ

Tobias Weisserth • March 2, 2006 6:20 PM

Regarding Password Safe:

“You can copy a password just by double-clicking, and paste it directly into your application.”

I guess that answers the first part of my question. Password Safe is /probably/ storing all the passwords in memory unencrypted after opening the safe. Even worse, copying a password into the clipboard makes this password available to other Windows processes running (true?). I could imagine a malware targeted at Password Safe users that simply checks whether Password Safe is running and waits for passwords being dropped into the clipboard where they can be picked easily.

Convenience seems to be the main danger to security. It would be much safer, if you output a password not as text that can be marked but as non-selectable images. Users would have to transcribe by hand but at least that way no passwords make it into the clipboard.

Am I too paranoid or did I hit a soft spot?

Andrew • March 2, 2006 6:29 PM

@ Tobias

If someone can run a program on your computer to snoop on the decrypted bits of memory of a password database, you’re already screwed. A keystroke logger to grab the master password and a simple copy of the encrypted database would be easier to accomplish, and would get you all the passwords, not just the ones that happened to be decrypted at the moment.

PasswordSafe does of course have a feature where it wipes the memory it uses to store decrypted passwords after it is done with them so someone can’t come along after the fact and steal your password. But if you can’t trust that the computer you’re sitting at now hasn’t already been tampered with, no password, even a memorized one, is safe to use.

Andrew • March 2, 2006 6:38 PM

Better than displaying the password on the screen at all is autotype, which converts the password directly into simulated keystrokes. The password never hits the clipboard or the screen.

One heck of a timesaver too… one particularly annoying system I have to log into has a custom autotype string of over 100 characters. Granted, most of them are the same damn character repeated over and over just to get the right element in a drop’n’scroll list selected. That such a broken UI design could survive testing and exist in a production system astounds me.

Roy • March 2, 2006 7:18 PM

The passphrase ‘Time and tide wait for no man.’ is guessable on the basis of redundancy in English, but a little fiddling gives …

'Thyme and Tide weight for Nomar Garciaparra;'

… which I think is not guessable.

BTW, my laptop allows 256-character strings, although I’m sure they are reduced to far shorter hashes and compared there.

Go2Null • March 2, 2006 8:20 PM

I normally change my passwords every month – I think of a phrase that topical and apply the following modications as appropriate – remove vowels, include numbers, replace letters with numbers (I have a quasi-standard replacement alphabeth), and capitalize. If the password will only be used on my laptop, I may also enable numlock while typing. This tends to produce a password that typically easy to remember and good enough for a month. Of course, I also save it in KeePass.

Kristin • March 2, 2006 8:55 PM

There’s nothing different here from trying to get people to use condoms to protect themselves from HIV (except perhaps that HIV is actually deadly).

We know a bit about getting people to adopt self-protective behaviors, including that it’s exteremely difficult.

Has anyone actually tried applying a theory-based behavior change intervention to the problem, I wonder?

And have the security folks yet taken it on board that making the end users change how they do things is almost certainly not going to be the fix to this problem?

Stefan Wagner • March 3, 2006 12:05 AM

I don’t understand how changing a password makes it more safe.

Assume a brute-force attack is running (very slow) on your one-character password ‘p’.
You don’t know whether the brute-force-attack is running from a to z or from z to a.
Shall we change it to ‘s’ or to ‘c’ or to ‘a’?
Perhaps the attack is going from a to z, and already reached b, and I’m now changing my password to ‘c’ – what a great security improvement!

If the new password is simply more complex, and per se better, it would have been better to choose it in the first place.

If the attack didn’t start yet, changing the password is no improvement.
If the password is already cracked, it’s too late.
If an attack is going on, we only improve security,if we can jump to a password, which has already been tested by the attacker.
Don’t they usally start with short and weak passwords?
So let’s choose a short and weak password!

How does the setting change, if don’t know, whether the attack did start at all?
How does it change, if we use to characters, digits, Uppercase and spe<|al sign$?

It doesn’t change – does it?

A message ‘Hi Stefan. 9737464 unsuccessful logins since 2006-03-01’ would help, and a forced delay.

Paeniteo • March 3, 2006 2:49 AM

@Stefan: Good points, but I disagree with the “If the password is already cracked, it’s too late.”.

If it is something like a root-password, the attacker could use it to install a backdoor for him and changing it would not be useful anymore.
But if it is e.g. a password to your mail-account, changing it would at least “lock out” the attacker from future access (until he has cracked it again). So it is intended to limit the damage.

Anders Thulin • March 3, 2006 2:56 AM

You don’t rely on non-combatants to provide a final line of defence. You may hope for it, but you don’t plan for it. Neither do you leave it up to end-users to create such a protection by their choice of password. Unless, of course, they get the support they need for taking on that responsibility, as well as the training for it.

To leave them with mere advice about password construction is irresponsible in extreme. It deserves to be punished, and it ususally is.

Concentrating on bad selection of passwords is misguided. It is the entire authentication situation that needs to be balanced: user-selected passwords is a protection weakness that needs to be complemented with stronger protection and detection capabilities.

Users may select bad passwords — so ensure that such passwords are detected quickly: ask the IT department to weed out really bad passwords, either by pre-filtering or by thoughtful cracking of password hashes. Pre-filtering by standard policy is also silly — far too many easily guessed passwords do have one uppcase letter, one lower-case letter, one special character, and one digit. If that rule is used as the password baseline, users will find their way around it — just as lab mice will jump over partition walls to get to where they want to be, to the frustration of scientists trying to make them go there through some labyrinth.

Bad passwords will fall to guessing attacks — so ensure that typical guessing attacks are discovered as well as prevented. A reasonable lockout policy together with proper alarms does that — and that does not mean lockout after 3 failures except in very high-security situations. 20 failures per day seems generous, but it will still slow down most guessing attacks as well as give alarms that a guessing attack is in progress.

Passwords (which includes passphrases in my mind) are on the way out, but it is silly to treat password security as if it was only up to end-users. That just helps perpetuate the illusion that IT departments are not at all involved with complementary measures. In typical corporate environments, they are. Or should be.

If users can’t be trusted with selecting good passwords, and IT departments are incapable of detecting them, it’s very simple. Don’t allow users to set their own passwords. Give them their password for the next month or two.

But of course, that puts the responsibility for password safety squarely in the lap of an IT or security department. Uncomfortably so. I wonder if that explains why things are done the way they are.

Kristof Meirlaen • March 3, 2006 7:03 AM

The recommendation suggesting us to memorize our codes is an old security principle which unfortunately does not apply anymore to our current needs.
(http://www.schneier.com/blog/archives/2005/06/write_down_your.html and http://news.com.com/Microsoft+security+guru+Jot+down+your+passwords/2100-7355_3-5716590.html)

Today, we must face up a multitude of access codes requesting to be regularly changed and based on the best practices. Our multiple access codes are now such complex that it is no more possible for us to remember them.

We all must remember and manage multiple “passwords” and some of us are just not creative enough to select strong passwords. That is why tools like PasswordSafe or even online services like PWMGR.COM (http://www.pwmgr.com/) can help keeping the balance and making it managable.

It is also important to note that the status of our passwords and other codes called “secret” has evolved from the level “confidential” or “private” to the level of pure information requesting the same treatments as any other data. From all the so called passwords I have, most are not really sensitive to me, as they lead to the same information as anybody else who registers.

Regards,
Kristof

ronys • March 3, 2006 7:08 AM

@ Tobias

Regarding PasswordSafe: Each entry in the database is stored encrypted in memory, using a session-unique key for each entry. Now, given that the sources are available, it is possible to write a program that will find the session key and derive the keys protecting each entry, but if someone went to the trouble of writing and installing such a program on your machine, you’re toast anyway, as has been pointed out. What the in-memory encryption does protect you against is someone who’s using a general purpose tool to comb through your computer’s memory. Also, you can “lock” the database when the application is minimized, which totally clears the memory. Unlocking requires you to re-enter the passphrase, after which the database is re-read from disk.

PasswordSafe tries very hard to minimize the exposure of the passwords it protects. At most a single password is exposed at a time.
It has (so far) stood the test of time, and is used by many (many!) individuals and institutions, including banks.

(Disclaimer: I’m the current maintainer of PassswordSafe on SourceForge)

Patrick • March 3, 2006 7:46 AM

Use diceware.com to generate high entropy but easily remembered passphrases.

http://diceware.com

To generate a word, you simply roll a set of 5 standard 6-sided dice and look up the corresponding word in the diceware list. Do this repeatedly to generate multiple words.

A 10 word diceware passphrase has about 130 bits of entropy and is surprisingly easy to remember. (Using funny mental imagery helps.)

I write down web site passphrases on a piece of paper which I keep fairly secure. I memorize my PGP passphrase and never write that down anywhere.

Just in case someone gets a glance at my written passphrases, I have rolled a few extra diceware words and committed them to memory. Now whenever I enter a passphrase from my written list, I type these extra words from memory onto the front of the passphrase.

Clearly Roboform, USB sticks, SSH login, and other technologies are tremendously useful. But there are also low-tech methods for easily managing multiple secure web site passphrases.

Mike Sherwood • March 3, 2006 7:48 AM

@Anders Thulin
“If users can’t be trusted with selecting good passwords, and IT departments are incapable of detecting them, it’s very simple. Don’t allow users to set their own passwords. Give them their password for the next month or two.”

These passwords can be printed on a little card to be taped to the monitor. That’s basically what happens in the majority of cases where passwords are given. The problem with giving people passwords is that there is no hope of them being memorized.

My experience mirror’s bob’s (3rd post). I have several accounts on numerous machines with different requirements for passwords. Off the top of my head, I can think of 14 separate systems that I access frequently. I also administer 6 of those, so I have multiple passwords to remember. That’s a minimum of 26 password instances. Combine that with policies that require passwords to be changed every 30-45 days and using good passwords becomes much more difficult. All of this just addresses my work accounts.

I use groups of passwords that I can remember. Some of them are better than others. Ie, some are susceptible to attack if someone looks at the history of the passwords used on some systems. Others are pieces of md5’s that I memorize. Others are purely random things that I pieced together into decent passwords. The majority of them have significant weaknesses to make them easy to remember.

I know how to generate good passwords and do that for my home machines. There I can change the passwords when I feel it makes sense. Ie, when I load a new OS version, I change the password. Fresh install + fresh password means the baseline for attacking that system is not based on past traits. It’s worth generating and memorizing a good password when I can keep using it for a significant period of time.

Having so many passwords that need to be frequently changed at work, I’ve adopted bad habits. The bad habits let me stick to the rule of never writing the passwords down. If I could keep the passwords longer, it would be much easier to remember a batch of random passwords.

Then again, the systems where I use what I consider to be poor passwords are ones that can be reset by anyone who calls tech support claiming to be me. My passwords aren’t the weak point in the overall system security. The systems where I have root access use decent passwords and getting passwords reset there has to come through me anyway.

Rich • March 3, 2006 7:50 AM

How about Anderson’s research on mnemonic passwords? For example, take sentence and use the first letters to make the password. It is best if the sentence has numbers and non-letters.

From the paper:”… passwords based on mnemonic phrases are just as hard to crack as random passwords yet just as easy to remember as naive user selections.”

Check it out at http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-500.pdf

Tobias Weisserth • March 3, 2006 8:09 AM

@ronys

Thanks a lot for your explanations! I guess I should really take a closer look at how Password Safe is handling exposure of keywords while running. This is indeed very interesting. Other programms/software could benefit from this.

thanks,
Tobias

Gordon Worley • March 3, 2006 8:16 AM

A paper I read about passwords that I liked a lot is “The Memorability and Security of Passwords – Some Empirical Results” by Jianxin Yan, Alan Blackwell, Ross Anderson, and Alasdair Grant at the Cambridge University Computer Laboratory. In this paper they show a way to generate easy-to-remember passwords that are very nearly random using memorable phrases. I use this scheme in my own passwords and rarely have trouble remembering a password even though I have a different password for every site (of course the use of a password manager helps).

Didier • March 3, 2006 9:55 AM

Nowadays beside these well known issues, we have to deal with an additional parameter which is the mobility. Many of us are travelling, using more than one computer from different locations. In the same way, we need to access our application and web sites from everywhere, from every computer. This is why, I opted for an online password manager.

I’m using PWMGR (www.pwmgr.com) for different reasons. I store there my passwords, PINs but also any kind of number I need to access from everywhere. I don’t need to be bothered with the selection of a new password since I can use the integrated password generator. When a new password is requested I simply asked PWMGR.COM to generate one for me based on my defined policy. I even don’t know some of my secrets. I just go on-line, select the related entry and copy it to the application. Furthermore, I don’t have to be concerned by the availability of my data in case of disk crash as this service is provided by the PWMGR. It also allows me to align the required level of authentication ( simple or strong authentication) to the sensitivity of the data contained in each individual vault. It is so useful and it saved me so many times that I keep convincing my friends to use it.

jose • March 3, 2006 11:56 AM

Use file keys and you dont need to remenber one weak password inclusive you can not remenber it if you are abducted so your files will be death exaxtly than like you , but hey they will be secure from NSA…

GotToBTru • March 3, 2006 12:55 PM

I use PasswordSafe for the important ones. I will shed a small tear when they turn off our last VMS computer here because I have used it’s password generator for more than a dozen years. It produces passwords of the desired length from digraphs and trigraphs so you end up with a non-word that you can pronounce and more easiliy remember (ingeanarim, poishorry, grabberion, elleating, jorainger…) PasswordSafe generates passwords but ones that only it can remember!

Another thing people have trouble remembering is padlock combinations. Master Lock has had a website for a while now where you can record them under a password. Check out:
http://combolocker.com/

Avery • March 3, 2006 1:34 PM

Unfortunatly in my place of employ that want upper and lower case letters, numbers and punctuation (Pick 3).

I don’t have the background to guess, but I’m guessing the complexity of my passwords went down when they did that because my ability to remember them was no longer sufficient to the task.

shoobe01 • March 3, 2006 3:26 PM

I have 18 authentications at my workplace. That’s on top of a whole sea of them for personal use. I just have them on a piece of paper that’s not even unreasonably well hidden.

Even if I instead used a usb dongle or other clever solution, it would only be so useful. That’s because they ALL have different requirements. Min AND max length, number of alternative characters allowed AND required, how often they expire, etc. I have 11 different USERNAMES. Even when allowed to set my own, even those are too often restrictive and I cannot use the same one everywhere.
No clever solution (like passphrases) will work till its been out for 20 years, and /everyone/ implements it. Consistently.

There’s another psychological component I’ll bet is at play for most users; the entity suggesting that security is your job is often not doing their job. SSN as a secure piece of info? How about the number of serious exploits of CC companies? No one can think of a time that their pswd was cracked, but almost everyone has had a letter saying that finacial data has been lost due to some /professional/ computer guy’s screw up.

Christoph Zurnieden • March 3, 2006 3:31 PM

@Stefan Wagner

Interresting question: why, when and how does a password change help?
A quite simple picture would be a game of whack-a-mole with one mole and several trillion holes. If the mole uses only one hole (no password changes) the attacker finds the mole by probing all holes “surely”. If the mole uses random holes (the password changes) the attacker has much less chances to find the mole. Even if the attacker probes all holes randomly (and everytime all) the chance to find the mole reduces to “almost surely” by the law of big numbers. You see one problem here and you are right: if the attacker chooses the same hole as the mole, the mole gets a very flat head. Thus the password change rate must be a minimum; if you change the password too often the chance to meet the attacker at the same hole rises, if the attacker chooses a purely random attack over all holes and everytime it is still only almost surly to find the mole.
So: if the mole stays in its hole/password does not change the attacker will find the mole/password surely but if the moles/password changes it is at most almost surely that the attacker/mole succeeds (yes, both have the same chances here).
It would be a nice finger exercise to do the calculations so have fun with it.

CZ

Milan Ilnyckyj • March 3, 2006 7:12 PM

@Andrew,

Thanks. I will give it a try.

@Henno,

I need something that works for Windows Server 2003, Mac OS 10.3.9 and 10.4, and linux. Useful as Keychain is, it’s a partial solution.

Stefan Wagner • March 3, 2006 11:35 PM

@Christoph Zurnieden
Ok – let’s whack-a-mole.

Password-policy: Use a single digit from 0-9.
Variant a) I don’t change my password.
Variant b) I change my password after 5 days.

Brute force attack is running from 0-9, trying one digit a day.

a) The password might be hacked at day d with probability p.
ps shall be the probability the password is broken at day d or before:
At the first day, the probability to be hacked is 1/10 – obvious.
The second day, 9 keys are left, so the probability is 1/9.
The summarized probability to be hacked isn’t 1/10 + 1/9, because the day 2 attack is only made if the first attack wasn’t successful.
The attack of day 1 was successful with 1/10, so it failed with 1-(1/10)=9/10.

sp(d) is p(d)*(1-p(d-1)) + sp(d-1).

d……keys*……p(d)……sp(d)
0……10…..0,10……0,1
1……9……0,11……0,2
2……8……0,13……0,3
3……7……0,14……0,4
4……6……0,17……0,5
5……5……0,20……0,6
6……4……0,25……0,7
7……3……0,33……0,8
8……2……0,50……0,9
9……1……1,00……1

change at day 5:
d……keys*……p(d)……sp(d)
0……10…..0,10……0,1
1……9……0,11……0,2
2……8……0,13……0,3
3……7……0,14……0,4
4……6……0,17……0,5
5……10…..0,10……0,55
6……9……0,11……0,6
7……8……0,13……0,65
8……7……0,14……0,7
9……6……0,17……0,75

Well – what’s the conclusion?
In real life, passwords are much longer and much more complicated.
On my machine, the advice is to use 6-8 characters of a-zA-Z0-9 and punctation.
If the term punctation is to be read as c-style punctation, that’s 32 possibilities, which leads to a total of 94 signs.
94^8+94^7+94^6 = 6 161 227 014 611 136
Hm.
How many of these might be tested per second?
If 1000 passwords per second are used, a complete attack would take 195 371 years.
Of course I should change my password after – let’s say 20 000 years.
Everything else would be silly.

The Problem with changing the password is: It starts paying, when the probability of a broken password is high, but it should prevent the probability of a password beeing broken to be high.
From a mathematical point of view, you should change your password after every unsuccessful use attemp to login.
This would keep the probability of it being broken 1/M (M is the number of possible passwords on the system).
Whether someone attacks your system with 1000 attemps, each with a probabilty to match from about 1/10 000 000 or each with a probability of 1/8 000 000 – that’s not a big difference – is it?

There is only a small korridor between a lot of attacks per day, and a time interval to change your password.

I guess a delay of 1 second between two passwords being entered is sufficient, together with 94^6.
Even passwords of 5 characters from a-zA-Z0-9 => 62^5 would need a 29years attack to try them all.

Christoph Zurnieden • March 4, 2006 3:56 PM

Password-policy: Use a single digit from 0-9.
Variant a) I don’t change my password.
Variant b) I change my password after 5 days.

(let’s refine b) by adding “randomly” to make it a bit simpler)

Brute force attack is running from 0-9, trying one digit a day.

I described two other versions too: choosing randomly with and without putting back. But let’s start with your definitions first.
If the password is never changed the statistic is quite is clear, but if the password changes randomly (with or without putting back does not matter theoretically; lazyness is a social problem) and the attacker never puts back, a password can be choosen which the attacker had already tested->attacker fails. If the attacker chooses the passwords randomly–well, it doesn’t change anything statistically, only if the attacker does not put the balls back into the box. It is then a race between the attacker and the defender or better: a game of whack-a-mole (with an invisible mole btw, but you’ll see blod&gore splattering around if you hit it).

That means of course, that a weak password is allowed if you change it often and/or do not allow much tries for the attacker (the latter allows for a DoS in certain circumstances!) and vice versa.
The ‘f’ in your first name allows me to guess that you may speak german fluently. If that’s true the following link may be interresting for you: http://www.selflinux.org/selflinux/html/passwoerter.html. Yes, I must admit it’s a very shameless self plug and has some errors in it too, sorry, but “Movable Type 3.2” has no direct (La)TeX-support.

But I digress. My point is that you may lower the password quality to an easily memorizable level if you change your briefs^Wpasswords often enough, randomly and reduce the number of tries per time; the risk is easily calculable.
BTW: PHBs love it if something is easily calculable in excel and has a nice and shiny formula that looks impressing in powerpoint! 😉
So in most circumstances there is no need for a password with exactly 256 bit of information such that the SHA-256-hash is fully used.
A small problem are the so called rainbow-tables which offer a log-n search within a precalculated bunch of hashes. These tables make it necessary to add some more bits of information to the password then calculated, but it is not much, one letter and/or a different hash is sufficient in most cases. The cost for the rainbow-tables is calculable, it can be added to the formula to compute the length and life of the password.

From a mathematical point of view, you should change your password after every unsuccessful use attemp to login.

That’s the reason behind the “3 times and you are out” of systems with a need of higher security. But it is, as I have written above, a chance for a (D)DoS.

Even passwords of 5 characters from a-zA-Z0-9 => 62^5 would need a 29years attack to try them all.

Yes, but you don’t need to try them all, you’ll find the password statistically in half of the time/tries and even the chance to find the correct password the first time is greater 0. You are of course right: it doesn’t matter if the attacker needs 15 or 30 years, but the problem is the probability that the attacker finds the correct password very fast is greater 0. If you change the password randomly and the attacker tests without putting back: what is the probability that you found a save harbour by choosing a password the attacker had already tested and will never touch again? You’ll see, that the chances are proportional to the size of the part of the set of available passwords the attacker had tested already and are above 1/2 if the attacker had tested more than half of the set. As expected.
But as I have shown above: the best tactic for an attacker would be to choose one password randomly and without putting back. Even if you change your password wildly like a rabid rabbit the attacker can be almost sure by the law of big numbers to catch you. But that tactic is obviously very expensiv, so the attacker uses all information to reduce the set of probable passwords, e.g. by using a dictionary attack and/or a rainbow-table. The dictionary attack is very fast because you can test a given hash in O(1) if it is not(!) a hash of an entry in the dictionary with a Bloom-filter.
So, anything else what the change of passwords is good for? Yes: the attacker does not know how much time is left up to the next password change. Given, of course, that the password changes randomly (more-or-less randomly in praxi, but that should be sufficcient too) and a new login/file-open is needed every time the password changes (and for the third time: DoS possible!).

But most of that discussion is quite useless if the attacker has a good chance to get the password by just asking/offering a candybar/sitting at the harmless side of a 12-gauge so use the prooven techniques for choosing and using of passwords and spend more calories for a good plan to “degrade gracefully” meaning: one must cut a lot of trees to kill a forrest–one must break a lot of accounts to kill a company.

CZ

Ari Heikkinen • March 4, 2006 8:37 PM

Exactly what’s the problem with easy passwords if the system in question is completely in control of the tries?

There were the days with world readable password files on unix systems (and thus giving an attacker complete control over trying to guess the password), but those days are pretty much long gone.

Peter Shaw • March 4, 2006 10:23 PM

Steve Gibson’s GRC’s Ultra High Security
Password Generator generates a unique set of custom, high quality, cryptographic-strength password strings every time the web page https://www.grc.com/passwords is displayed.
Just copy as long a key as you want and paste.

Stefan Wagner • March 5, 2006 10:07 AM

@christoph:
Yes – I speak german much better than english. 🙂

Well – chances are good to find a secure harbor, if the attacker already tested a lot of possible passwords, which means: chances are good he already broke in.
And of course we leave the secure harbor after the predefined time again.

The linked article is fine, and I have to correct myself:
In the article, the author is calculating with about 250 000 tests per second.
I thought too much of my own environment, where only me has fast access, and everybody else is limited to a few tries per second. (Dial-in connection to the internet, only reachable by ssh).
Perhaps the note about login-delays shouldn’t claim ‘should not be used’ but ‘should not be trusted too much’, and mention which environments are vulnerable in which circumstances.

Nobody would run a brute-force attack for 6 months to gain access to my system, I guess.

A question not mentioned in the article is the inditrect influence on security by changing the password often, and using a long, cryptic password: You need to write it down.
j~//pdZq< isn’t something I like to memorize, especially if changed every month.

(btw: ;<& may cause problems in shellscripts, don’t they?)

In general the article doesn’t compare security with change and without change.
I wrote a program (which is not very performant implemented) to compare the effekt of changed and unchanged passwords.
For a weak password with a len of 6 and a charset of 62 characters, and 20 tests per second, and an optional policy to change it after 30 days comparing the security after 300 days:

p(cracked) = 0,0091267 without change
p(cracked) = 0,0090893 with change

For a len of 8 characters and 250 000 attacks/s:

0,0356142 without change
0,0350385 with change

For a duration of 1800 days (about 5 years) there is still nearly no difference:

0,1780708 without
0,1633384 with

We have to increase the runtime to 10 years for a more clear result:

0,3561416 without
0,2999974 with

or 20 years:
71% without
51% with change.

The last examples means the password changed 240 times, and the probability of a crack is 51%.

Of course machine-power will increase in 20 years – btw.: I didn’t find a date when the article was written.

Something I didn’t understand:

BTW: PHBs love it if something is easily calculable in excel …
Who is PHBs?

Christoph Zurnieden • March 5, 2006 12:17 PM

(It seems as if “Movable Type 3.2” has no provisions against double-clicks, hasn’t it?)

And of course we leave the secure harbor after the predefined time again.

No, that is not sure if the new password is choosen randomly, the probability is not 1. The probability to choose a safe password is even higher than before because the save harbour grows with time.

Nobody would run a brute-force attack for 6 months to gain access to my system, I guess.

Depends on the assets of Nobody and the value of your system.
I don’t have the actuall prices at hand, but you can rent a very large botnet for a couple of thousand US-dollars and you do not have to strain you imagery much to estimate the cababilities of a 50.000 member botnet.
But as Ari Heikkinen righteously mentioned: gaining access by breaking the login is not much of a problem anymore by reducing/delaying tries. With the price of allowing DDoS to block access and the chance to gain money by blackmailing. The blackmailing by threat of DoS seems to be very popular these days. I had the “fun” to fight it four times last year (all were smaller companies. Pure chance? I don’t think so) and it is very hard to defense because of their quite elaborated mosquito-tactic.

(btw: ;<& may cause problems in shellscripts, don’t they?)

Yes, you must take care.

In general the article doesn’t compare security with change and without change.

Yes, I didn’t think of it that time and it’s a couple of years old. I would have corrected it, but the organisation had some non-technical troubles.

I wrote a program […]

Please publish it or at least a formal description of it, such that other people like me are able to reproduce your results more easily than building one ourself with your informal description. Yes, I’m lazy 😉

Who is PHBs?

PHB = Pointy Haired Boss (http://www.dilbert.com/comics/dilbert/the_characters/)

Not everyone knows Dilbert as it seems? I think you’ll have a lot of fun here: http://dilbert.com/, a good start may be: http://dilbert.com/comics/dilbert/archive/index.html.

CZ

Stefan Wagner • March 5, 2006 8:47 PM

The sourcecode (java) is here:
http://home.arcor.de/hirnstrom/minis/index.html#pwdcrack
if it contains a bug, I hope you’ll find it.
(It’s a bit gaudy around there – it is to drive away the PHBs:) )
It’s a fast hack and produces garbage, if you choose an expiration time, such that the password is found before expiration.

I hope it’s at least calculating precise when feed with proper values.
I tested it with a few very small values and they worked as expected.
The results for large attacks were astonishing for me, but seem plausibel, after thinking of it.

You’re a bit astonished of the results too?

P.S.: I’ve seen some dilberts before, but I prefer Bill Sienkevicz/ Frank Miller:
http://www.wordsandpictures.org/Elektra/art37.html
and Art Spiegelmann
http://64.23.98.142/indy/winter_2005/breakdowns/index.html

mjs • March 6, 2006 10:44 AM

Password security is primarily a human issue, not a mathematical issue. That’s why, in my opinion, requiring frequent password changes is likely to result in less security. You might be able to get the average person to choose a decent password once a year, but there’s not a chance they will do it once a month. If you discover an old password that is “x6#1B)Feb”, it doesn’t take much to guess what the current password is likely to be.

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.