Security Myths and Passwords

Page Content

Share:

(This is an updated version of a contribution I made to the Educause security mailing list last week.)

In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration.  Some of these get included in policies, and thus may get propagated to environments they were not meant to address.  It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change.  The result is a stale policy that may no longer be effective…or possibly even dangerous.

Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom.

From a high-level perspective, let me observe that one problem with any widespread change policy is that it fails to take into account the various threats and other defenses that may be in place.  Policies should always be based on a sound understanding of risks, vulnerabilities, and defenses.  “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.

Consider the underlying role of passwords: authentication.  Good authentication is intended to support access control, accountability and (in some cases) accounting.  Passwords provide a cost-effective and user-familiar form of authentication.  However, they have a number of failure modes depending on where they are used and the threats arrayed against them.  Failure modes include disclosure, inference, exposure, loss, guessing, cracking, and snooping.  In the most general case, passwords (such as the security numbers on credit cards, or mother’s maiden name) are not sufficiently secret and are simply too weak to use as strong authenticators.  I’ll skip this case, although it is far too pervasive to actually ignore.

Disclosure is a systemic threat on the platforms involved, as well as in the operational methods used to generate and transmit the passwords.  This cannot be addressed through changing the password.  Instead, the methods used to generate and distribute passwords needs to be examined to ensure that the passwords are not disclosed to the wrong parties.  Most operating systems are currently designed so that passwords are not stored “in the clear” and this reduces the chance of disclosure.  Unfortunately, some 3rd-party applications (including web-based systems) fail to adequately guard the passwords as they are entered, stored, or compared, resulting in potential disclosure.

Another form of disclosure is when the holder of the password discloses the password on purpose.  This is an education and enforcement issue.  (Anecdote:  at one location where a new policy was announced that passwords must be changed every month, a senior administrator was heard to moan “Do you know how much time I’m going to waste each month ensuring that everyone on my staff knows my new password?”)

Inference occurs when there is a pattern to the way the passwords are generated/chosen and thus can be inferred.  For instance, knowing that someone uses the same password with a different last character for each machine allows passwords to be inferred, especially if coupled with disclosure of one.  Another example is where generated passwords are employed and the generation algorithm is predictable.

Exposure is the case where accident or unintended behavior results in a sporadic release of a password.  As an example, think of someone accidentally typing her password as the user name in login, and it is captured in the audit trail.  Another example is when someone accidentally types his password during a demonstration and it is exposed on a projection screen to a class.

Loss is when someone forgets his or her password, or (otherwise) loses whatever is used to remind/recreate the password.  This introduces overhead to recover the password, and may induce the user to keep extra reminders/copies of the password around—leading to greater exposure—or to use more memorable passwords—leading to more effective guessing attacks.  It is also the case that frequent loss opens up opportunities for eavesdropping and social engineering attacks on the reset system as it becomes more frequently used: safeguards on reset may be relaxed because they introduce too much delay on a system under load.

Guessing is self-explanatory.  Guessing is limited to choices that can be guessed.  After a certain limited number of choices, the guessing can only transform into a cracking attempt.

Cracking is when an intermediate form of the password (e.g., an encrypted form stored in the authentication database) is captured and attacked algorithmically, or where iterated attempts are made to generate the password algorithmically.  The efficacy of this approach is determined by the strength of the obfuscation used (e.g., encryption), the checks on bad attempts, and the power and scope of the resources brought to bear (e.g., parallel computing, multi-lingual databases).

Snooping (eavesdropping) is when someone intercepts a communication employing the password, either in cleartext or in some intermediate form.  The password is then extracted.  Network sniffing and keyloggers are both forms of snooping.  Various technical measures, such as network encryption, can help reduce the threat.

Now, looking back over those, periodic password changing really only reduces the threats posed by guessing, and by weak cracking attempts.  If any of the other attack methods succeed, the password needs to be changed immediately to be protected—a periodic change is likely to be too late to effectively protect the target system.  Furthermore, the other attacks are not really blunted by periodic password changes.  Guessing can be countered by enforcing good password selection, but this then increases the likelihood of loss by users forgetting the passwords.  The only remaining threat is that periodic changes can negate cracking attempts, on average.  However, that assumes that the passwords choices are appropriately random, the algorithms used to obfuscate them (e.g., encryption) are appropriately strong, and that the attackers do not have adequate computing/algorithmic resources to break the passwords during the period of use.  This is not a sound assumption given the availability of large-scale bot nets, vector computers, grid computing, and so on—at least over any reasonable period of time.

In summary, forcing periodic password changes given today’s resources is unlikely to significantly reduce the overall threat—unless the password is immediately changed after each use.  This is precisely the nature of one-time passwords or tokens, and these are clearly the better method to use for authentication, although they do introduce additional cost and, in some cases, increase the chance of certain forms of lost “password.”

So where did the “change passwords once a month” dictum come from?  Back in the days when people were using mainframes without networking, the biggest uncontrolled authentication concern was cracking.  Resources, however, were limited.  As best as I can find, some DoD contractors did some back-of-the-envelope calculation about how long it would take to run through all the possible passwords using their mainframe, and the result was several months.  So, they (somewhat reasonably) set a password change period of 1 month as a means to defeat systematic cracking attempts.  This was then enshrined in policy, which got published, and largely accepted by others over the years.  As time went on, auditors began to look for this and ended up building it into their “best practice” that they expected.  It also got written into several lists of security recommendations.

This is DESPITE the fact that any reasonable analysis shows that a monthly password change has little or no end impact on improving security!    It is a “best practice” based on experience 30 years ago with non-networked mainframes in a DoD environment—hardly a match for today’s systems, especially in academia!

The best approach is to determine where the threats are, and choose defenses accordingly.  Most important is to realize that all systems are not the same!  Some systems with very sensitive data should probably be protected with two-factor authentication: tokens and/or biometrics.  Other systems/accounts, with low value, can still be protected by plain passwords with a flexible period for change.  Of course, that assumes that the OS is strong enough to protect against overall compromise once a low-privilege account is compromised….not always a good bet in today’s operating environment!

And, btw, I’ve got some accounts where I’ve used the same password for several years with nary an incident.  But in the spirit of good practice, that’s all I’m going to say about the passwords, the accounts, or how I know they are still safe. grin

One of my favorite Dilbert cartoons (from 9/10/05) ends with the pointy-haired boss saying “...and starting today, all passwords must contain letters, numbers, doodles, sign language and squirrel noises.”  Sound familiar to anyone?

[A follow-up post is available.]

Comments

[...] A blog post by Eugene Spafford which examines password security, and the way that detrimental security practices sometimes get propagated because they’re considered by many to be “best practices.”  http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ [...]

Posted by Privacy Commission - On The Frontline Of Online Pr on Tuesday, June 6, 2006 at 04:00 AM

In an organisation with a variety of applications and data security classification levels but a single Windows domain login and single AD authentication backend I have recommended policies that require strong passwords and regular (90 day) change.

However I believe that a primary issue is not password change per se but the quality of passwords. I am working on a plan to educate users on a largish (1000+) scale on ways of creating passwords that are memorable and that result in high quality passwords. Pass phrases combined with letter substitution give a password that is easily created, easily remembered, easily modified and not easily guessed or cracked.
User education is the key and trumps just about any technology or draconian policy any time.

Posted by jim on Tuesday, June 6, 2006 at 11:43 AM

I agree that changing your password once a month does not decrease the chance that a brute-froce algorithm would find it in a give amount of time. However, if, for example, an attacker gains access to your list of password hashes (I have seen these traded on IRC in the past) and it takes more than two weeks to crack these on his PC, then there is a better than 50:50 chance that the passwords he cracked are no longer valid.

The big problem is that it’s not going to take an attacker two weeks to crack your passwords, especially if you have unsalted hashes (rainbow attacks) or do not enforce minimal password complexity/length. Changing your password every day or two is just not an option.

There are essentially three ways to authenticate a person. Either by what they know, what they have, or what they are. Passwords are something persons “know”.  A good authentication mechanism should use two or maybe even three of those methods. SecureID for example is something you have (the key fob) and something you know (your PIN) combined. Biometrics are an example of “what you are”. Since all these can be circumvented (with the possible exception of some biometrics), combining at least two methods gives you better protection. An attacker might crack a user’s password, but can they also steal that user’s key fob or irises? smile

I know this isn’t practical in most environments, but for highly sensitive data, a combination of methods should be considered.

By the way - passwords that can be entered on a standard keyboard (not counting Windows ALT combinations) are pretty limited in their keyspace. There are only about 90-ish characters on a keyboard. Not a huge amount of entropy for a 8-character password.

Posted by Markus on Monday, June 19, 2006 at 01:58 PM

[...] Security Myths and Passwords. This should be a must-read for all IT managers… that “change your password every 30 days” policy could well lead to less secure passwords and more time spent resetting lost ones — so why do it? [...]

Posted by The Clever Shark » Blog Archive » Some on Thursday, July 13, 2006 at 06:03 AM

[...] Good blog posting on password rules, with an interesting speculation on how one of them came about: In summary, forcing periodic password changes given today’s resources is unlikely to significantly reduce the overall threat - unless the password is immediately changed after each use. This is precisely the nature of one-time passwords or tokens, and these are clearly the better method to use for authentication, although they do introduce additional cost and, in some cases, increase the chance of certain forms of lost “password.” [...]

Posted by Condor’s Quill » Blog Archive » on Tuesday, August 1, 2006 at 05:52 AM

Guys, try out Securepass from www.securenez.com.  Been using it for about a month.  Seems the program acts upon all the recommendations of security experts and what is mentioned in this blog regarding password policies.

These guys stress a lot on replacing exisiting password with system generated password for enhanced security.  Also say that they never store passwords anywhere, making them undetectable.  Also support one click login on Internet Explorer (too bad this feature does not work with Mozilla - called them, the company said it is coming soon)

Can someone else also try the product out and write about it for benefit of others.

Posted by Ann on Tuesday, August 15, 2006 at 07:09 AM

<a href=“http://www.firsteuropa.es/” rel=“nofollow”>FirstEuropa.com - tu corredor de seguro en l

Posted by webmaster on Sunday, August 20, 2006 at 07:04 PM

I disagree that this is a *good* essay. I think the subject is an important one that should be treated, but this essay did a poor job.

The author stated his premise at the beginning, then wandered off to survey ways that passwords can be compromised. Finally, in the last few paragraphs he came back to his premise, but didn’t really present any hard evidence to support it.

IMHO this is just the start to a treatment of this subject. It is an important subject, though, because so many who don’t thoroughly understand security DO rely on ‘best practices.’

I think once before you advised (paraphrasing) “Use secure (i.e., non-trivial) passwords, then write them down somewhere—this is better than using more memorable ones that are easily guessed.” This, to me, is the most practical advice I have heard in a long time. I think it may apply here; change your passwords occasionally (not necessarily every month) and if you have to, write them down somewhere secure.

Posted by Free Daily Infoformation on Sunday, August 20, 2006 at 10:28 PM

[...] A blog post by Eugene Spafford which examines password security, and the way that detrimental security practices sometimes get propagated because they’re considered by many to be “best practices.”read more | digg story [...]

Posted by Security » Security Myths and Passwords on Thursday, August 31, 2006 at 09:59 PM

[...] Security myths and passwords I like this a lot. http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/  In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration. Some of these get included in policies, and thus may get propagated to environments they were not meant to address. It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change. The result is a stale policy that may no longer be effective…or possibly even dangerous. Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom. From a high-level perspective, let me observe that one problem with any widespread change policy is that it fails to take into account the various threats and other defenses that may be in place. Policies should always be based on a sound understanding of risks, vulnerabilities, and defenses. “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.  Published Sunday, April 30, 2006 9:07 AM by steriley Filed under: identity, authentication, security policies, passwords, security myths [...]

Posted by Steve Riley on Security : Security myths and passw on Tuesday, October 3, 2006 at 01:02 PM

I have a question that I would like someone to address:

Single username/password for a 600 family online church directory vs 600 individual username/passwords generated by church members.

A church directory is a public directory but can be limited to the congregation.

I recommended a single username/password to be distributed to the membership through a letter to each family.

There are others that feel that a single username/password is not sufficient and propose individual username/passwords to each of the 600 familys.

My contention is that with one username/password I can make it a strong password.  With 600 individual username/passwords allowing each to reset their passwords I know there will be weak passwords.

I contend that it is like a door with a combination lock which has one combination to allow ingress as compared to one door with a combination lock with 600 combinations that will ingress into the same room.  Which is the most secure????  With more username/password combinations the security goes down.  Admittedly, neither is high security because all one has to do is place their membership and they will be given the access code.

I certainly would appreciate some outside comments and or suggestions where I might find more information.

Thank you,

Orvis Pigg

Posted by Orvis Pigg on Wednesday, October 18, 2006 at 07:37 AM

Orvis,

Having multiple accounts is definitely better from a management point of view.  If one is compromised or abused, you can deal with it individually rather than shutting off access to everyone (as would be the case with a single account).

—spaf

Posted by Spaf on Thursday, October 19, 2006 at 02:07 PM

I quite agree with the author’s thoughts about passwords. I think it is necessary to change it, to increase the number of characters in a password and allow using not only letters or numbers or symbols, but to use all of them at once, by mixing them. Of course the most sensitive data should be more protected and the password should be changed in shorter periods of time.
I would like very much to have something new to protect my data as soon as posiible.

Posted by Helen on Monday, October 23, 2006 at 11:25 PM

[...] Helen: I quite agree with theSpaf: Orvis, Having multiple accounts is definitelyOrvis Pigg: I have a question thatElizabeth: Nice site… Cool guestbook…I [...]

Posted by CERIAS Weblogs » Now THIS is how to have sec on Tuesday, October 24, 2006 at 11:25 AM

[...] Secondo Microsoft e’ un errore. Secondo spaf una forma estrema di sicurezza.  Share & Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages. [...]

Posted by quasi.dot » Blog Archive » Xtreme Secu on Wednesday, October 25, 2006 at 10:18 AM

[...] As I consider this, which usually happens when I am forced to change a password on a system that really has no reason for it, like company on-line training courses. Who wants to hack in to take my courses. There is no incentive, so there is no need. I do think there are times when it may be good policy, but I think it is used too often and with too short a period before the change is required. Since I was thinking of it, I decided to search on it and found some interesting articles. I found a very thoughtful post on the site of the Center for Education and Research in Information Assurance and Security (CERIAS). He states, very persuasively that password policies should be tailored to the system and the threat that the system faces. The best approach is to determine where the threats are, and choose defenses accordingly. Most important is to realize that all systems are not the same! Some systems with very sensitive data should probably be protected with two-factor authentication: tokens and/or biometrics. Other systems/accounts, with low value, can still be protected by plain passwords with a flexible period for change. [...]

Posted by On Being Secure at Y Not I on Thursday, March 8, 2007 at 11:12 AM

[...] Good blog posting on password rules, with an interesting speculation on how one of them came about: In summary, forcing periodic password changes given today’s resources is unlikely to significantly reduce the overall threat - unless the password is immediately changed after each use. This is precisely the nature of one-time passwords or tokens, and these are clearly the better method to use for authentication, although they do introduce additional cost and, in some cases, increase the chance of certain forms of lost “password.” [...]

Posted by CQ2 » Security Myths and Passwords on Wednesday, April 11, 2007 at 07:19 PM

I agree USER generated passwords are a weak link security.  The use of a secure token removes all of the issues associated with common themes used for passwords (i.e kids/pets names, favorite team, street).

Posted by Bill on Thursday, April 19, 2007 at 02:14 AM

I like the suggestion of creating a strong password by coming up with a sentence/phrase that you are not likely to forget.  It could be a line from a movie you love or a long song title - or whatever.

Use the first letter of each word in your chosen phrase substituting certain letters for their symbolic or numeric counterpart.

For example:

“Is there anybody out there?” could be used to get the password: “!t@ot?”

Posted by credit card researcher on Thursday, May 24, 2007 at 07:01 PM

[...] morning I read a good essay named “Security Myths and Passwords” by Prof. Eugene Spafford. Prof. Eugene told us his doubt on  those  best practices on [...]

Posted by Best practice on password management on Tuesday, July 31, 2007 at 03:34 PM

While I agree with you that there are a lot of persisting security myths, I don’t agree with your stance on frequent password changes, despite the appealing approach of using logic to ‘prove’ that frequent password changes are useless.

In my opinion, frequent password changes may help to prevent that users use the same password everywhere: The average user is inclined to use the same password for authenticating at work as for accessing his/her account on any old online shop, online community, web mail service, chat service, ringtone download business etc…

Many of these online services store user passwords either unencrypted or with reversible encryption.  Those password databases are therefore accessible to hundrerds of people, not all of them equally trustworthy.

If a company’s only authentication scheme is userid / password, then a frequent password change requirement will make sure that the password used to authenticate at work is definitely _not_ identical to the one used on all those systems, because users are not going to change their passwords on all of those services when they need to change it at work.

Kind regards,
  Jan Spooren, CISA, CISSP.

Posted by Jan Spooren on Sunday, April 13, 2008 at 09:28 PM

Leave a comment

Commenting is not available in this section entry.