CERIAS - Center for Education and Research in Information Assurance and Security

Skip Navigation
CERIAS Logo
Purdue University - Discovery Park
Center for Education and Research in Information Assurance and Security

Security Myths and Passwords

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

Posted by Security Myths and Passwords at www.gadgetguy.de -
on Friday, April 28, 2006 at 01:44 AM

[...] Excellent article by Gene Spafford about threads regarding password policies. Best article on the topic I’ve seen yet - and lots of wisdom to use for your own security related discussions. “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.” [...]

Posted by Khaled’s Blog » Blog Archive » L
on Friday, April 28, 2006 at 04:04 AM

[...] Security Myths and Passwords [...]

Posted by meneame.net
on Friday, April 28, 2006 at 10:51 AM

<strong>Mitos y contraseñas…</strong>

Interesante texto sobre políticas de cambio de contraseñas , en inglés.Visto en barrapunto : http://barrapunto.com/article.pl?sid=06/04/28/1523213…

Posted by sideline
on Friday, April 28, 2006 at 02:01 PM

This premise seems plausible mainly because it discusses passwords in terms of shell login access, but I do not believe it holds in the modern networking world, where passwords control access to many types of resources.

Where a password is being used for shell or desktop access, there is usually a way for an intruder to establish a long-lasting foothold.  Other types of systems, where shell access is not allowed, do not provide many such opportunities.  For example, on a properly configured IMAP server, there is little chance for an intruder to establish a foothold that will last once the password is changed out from under him.  Likewise for most web apps, VPN access, fileshares, etc.  These are all services which see enhanced protection from frequently changed passwords, as it limits their temporal window of vulnerability.  Most of the passwords in my life only control access to these no-foothold systems.

The points about frequent changes weakening password strength and leading to unsafe storage are well taken.  The period of password change obviously needs to be chosen carefully to balance its benefits against such effects.

Posted by Telecom, Security and P2P
on Friday, April 28, 2006 at 04:03 PM

<strong>Best practice on password management…</strong>

This 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 password management policy, like "monthyly change", based on the i…

Posted by Richard
on Friday, April 28, 2006 at 04:05 PM

The defects and even failures in most of enterprise security defense systems can be root caused into problems in “security execution”, ie. the discrepancy between the policy and the real environment. The security manager just book those best practices into their “policy”, while not considering their staff, their skills, the data to protect, the threats to contain/mitigate…

Posted by Wim L
on Friday, April 28, 2006 at 07:59 PM

I’d always assumed that the password rotation meme came to us from things like military checkpoint passwords, where lots of people would have to know the same password. It can be assumed that the password will leak, given time; but it can also be assumed that Mallory/Eve can’t use the leaked password immediately, but must wait until other factors have come into alignment. Changing the password periodically does seem like it would help in that scenario.

Posted by Amanece, que no es poco — Mitos sobre contra
on Saturday, April 29, 2006 at 01:11 AM

[...] En Security Myths and Passwords se habla de la política de cambio de contraseñas cada cierto periodo de tiempo.  En: Seguridad — Abril 29, 2006 [...]

Posted by IT Security » Blog Archive » Security
on Saturday, April 29, 2006 at 10:22 AM

[...] Security Myths and Passwords: An excellent article discussing why changing passwords all the time isn’t security. If you read the “safe book”, read this. [...]

Posted by ablog » The Mythology of Periodical Password
on Saturday, April 29, 2006 at 05:43 PM

[...] One of my favourite topics is security mythology - that

Posted by Steve Riley on Security : Security myths and passw
on Sunday, April 30, 2006 at 06:09 AM

[...] 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 [...]

Posted by Off Campus : Password policies
on Sunday, April 30, 2006 at 07:49 PM

[...] Password policies   This was already written up earlier today on another TechNet blog but I wanted to make note anyway in case subscribers don’t digest the entire TechNet feed. Prof. Eugene Stafford posted an interesting write-up on password policy myths.  Especially relevant to HE where passwords very often span longer periods of time. http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ [...]

Posted by sturner0430
on Monday, May 1, 2006 at 06:47 AM

How many people do I know who write down their password so they won’t forget it, as they rotate through the “change every x months” changes?

Well, let’s just say that the number is greater than the number of fingers and toes that I have. And that number does include me. So is it really more secure, or did we just socially engineer a security hole?

Additionally, the more random the password and the longer it is, the more secure it is. But who can reliably remember a 26-character alpha-numeric and symbol password?

Posted by Random Bits from the net.. »
on Tuesday, May 2, 2006 at 02:11 AM

[...] http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ [...]

Posted by ::- Essential Security -:: » ‘SpafR
on Tuesday, May 2, 2006 at 06:31 AM

[...] A great article from Eugene Spafford on “best practices” regarding passwords. As I’ve stated a million times, passwords and the policies surrounding their use are nearly useless. OTP, biometrics, proximity, etc should be the standard we drives ourselves too rather than constantly thinking passwords are a safe form of authentication. Changing a password every 30 days does not make it secure! Check out Dr. Spafford’s article when you get a chance.  Published in: [...]

Posted by The Lone Sysadmin » links for 2006-05-04
on Wednesday, May 3, 2006 at 08:20 PM

[...] CERIAS Weblogs » Security Myths and Passwords (tags: password security sysadmin) [...]

Posted by Julius
on Thursday, May 4, 2006 at 12:41 AM

Murphy was an optimist: It is never so bad that it cannot get worse.

Posted by Steve Mullen’s Blog » Security Mythns
on Thursday, May 4, 2006 at 03:46 AM

[...] Last week Bruce Schneier and others blogged about the Security Myths and Passwords paper written by Professor Eugene H. Spafford concerning the best practices or “rules of thumb” that many people accept without careful consideration, particularly policies requiring regular password changes (e.g., monthly). As someone developing a password policy requiring regular password changes, in my case 90 days, I understand his logic but also disagree to some degree. Until we can move folks to using, and also requiring, long passwords as a norm, requiring period password changes, not 30 days mind you, will still be necessary. [...]

Posted by Microsoft Switzerland Security Blog : Security Myt
on Thursday, May 4, 2006 at 04:33 AM

[...] Security Myths and Passwords   ...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. http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/ Urs   [...]

Posted by CERIAS Weblogs » Passwords and Myth
on Wednesday, May 10, 2006 at 07:09 PM

[...] Passwords and MythSecurity Myths and PasswordsWhat is Secure Software Engineering?ID Theft Resource [...]

Posted by Security Wonk - Blindly Applying ‘Best Pract
on Thursday, May 11, 2006 at 06:24 AM

[...] Professor Spafford expounds on his previous article we talked about to say that we should examine all best practices to see which ones make since for a given application. My favorite example of this: [...]

Posted by JG
on Monday, May 15, 2006 at 12:49 AM

Thanks for bringing this up. 

This whole area of ‘best practice’ for passwords disgusts me, because it is ‘our’ (IT inc’s) failure to provide a safe environment for passwords that requires users to jump through all these password hoops!  The majority of the “...must be 12 characters long, with upper and lower case, etc, etc” requirement is because we haven’t been very successful in preventing attackers from managing to sniff comms, hijack protocols and snatch stored copies of the password. The other types of attacks, for instance, keystroke sniffers, social engineering, etc, are barely affected by doubling the size of the passwords or whether they get changed every month.  Just because an admin (who has unrestricted access to the SAM/Shadow file) can break a password in ten minutes shouldn’t mean squat if the system has appropriate controls around that file to stop others getting direct acces to it plus a limit on the number of failed attempts through the legitimate interface.

In short, I think the policies we keep pushing are solving the wrong problem and, as you rightly pointed out, end up causing our ‘solutions’ to break in another place. 

Bank ATMs are an example of this working.  With a 4 digit PIN they still are still effective at blocking an impersonater, even if the attacker has managed to copy or steal the card, since they still don’t have a means to brute force the PIN (all bets are off if they are skimming, shoulder surfing, or torturing for the PIN regardless of whether its a 4 or 40 digit PIN. That’s a different problem).

Posted by Software Nerd
on Monday, May 15, 2006 at 01:00 AM

I have my own password rules: http://softwarenerd.blogspot.com/2005/08/safeguarding-passwords.html

Posted by Dan
on Monday, May 15, 2006 at 05:59 AM

I would just add a note about all the passwords we have to create and memorize that have nothing to do with security - at least, not OUR security. My password to the NY Times web site protects THEIR economic interest - either through ensuring all users have paid some fee or subscribed to some other paid service (the actual newspaper) - or theu targeted marketing based on my demographics - why I probably lied about anyway.

Posted by Exothermicus
on Monday, May 15, 2006 at 04:07 PM

My thoughts exacly, The policy setting that forces passwords to contain at least 3 of 4 types of characters in windows at best only adds 3 bits of added entropy against a brute force attack assuming that only one character in each of the three categories is used.  while simply increasing the minimum password length by 1 character will increase the entropy by 6 bits.

One can argue that it helps prevent a dictionary attack, as well as obfuscate the password a bit more for sholder surfers.

I contend that the added security of requiring shift modified characters in the password, does not equate the added keystrokes needed when typing it compare to lengthening a password by the same number of keystrokes.

Exo

Leave a comment

Commenting is not available in this section entry.