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

“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.”

I would submit that very few of us have sufficient data to do an accurate risk assessment from scratch. Cyberworld incidents aren’t as stable and foreseeable as floods and burglaries. Risk assessments that do not take into account changing environments are not accurate. Risk assessments that don’t need to are probably too general to be of much practical value.

Best practices provide a floor to build on. I’m not saying they should be followed blindly and I agree with your comments about password expirations but best practices should not be dismissed lightly.

Posted by gary on Thursday, April 20, 2006 at 02:51 AM

I agree with Gary’s take on best practices—they’re rarely perfect but useful to establish a baseline for a particular organization to tailor to its needs. We’re about to expire passwords for the first time in 10 years and increase their strength. Given that we have sensitive data, and the burden that dual-factor authentication would place on many important workflows, having passwords expire, increasing their length and complexity and restricting password resuse was deemed the best fit for our organization. As Gary points out, risk assessments are incredible difficult and depend on which department does them. If our information security team was the sole gatekeeper of risk assessments, we’d be submitting DNA every morning for authentication.

Posted by Chris on Saturday, April 22, 2006 at 06:16 AM

[...] 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 Myths and Passwords on Saturday, April 22, 2006 at 07:46 AM

Users will respond to such password-change policies with a strategy to compensate for the added complexity. If users are unable to remember passwords - for example, because they have several accounts on different networks and updating the password for all accounts is too time-consuming, then such a strategy would be a piece of paper locked in their desk, or a text file (maybe encrypted) containing all the current passwords. Alternatively, they will use consecutive numbering in their passwords, to the next password can be easily guessed if the previous one is known.

None of these strategies is particularly welcome from the security stand-point. The result of a change-password-every-month policy is a less secure system.

Posted by David Reitter on Saturday, April 22, 2006 at 07:47 AM

[...] Here’s an interesting post about forcing password changes. [...]

Posted by Steve Wills Weblog » Blog Archive » Ma on Saturday, April 22, 2006 at 07:47 AM

“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.”

This is one of the most enlightened statements I have read in the recent past. Thank you for sharing it. I now have a proper defense when someone says, “But you’re not following so-and-so’s best practices! We’re doomed!” Previously, this kind of statement would stop me in my tracks because, even though I found the statement disquieting, I had no proper rebuttal.

Posted by Eric H. Jung on Saturday, April 22, 2006 at 08:05 AM

While you may have a point, I could also tear apart every single security facet similarly. However, when taken as part of a whole, this helps.

I think you’re being ignorant, overly chest-thumping to get attention, and just panic-attacking over having to change passwords in some environment, possibly where you work.

By the way, which is more secure or at least better from a security perspective: changing passwords every month (or regularly) or do as you do, keep them the same for years? That simple question is enough to debunk this entire, poorly organized piece.

What about encryption keys? Should we keep those the same as well, even though the longer you keep them the same, the more data you can collect to try and crack it?

If “any reasonable analysis” shows that password rotation is moot, then do it!

Posted by anonymous on Saturday, April 22, 2006 at 08:23 AM

[...] read more | digg story [...]

Posted by wimac | project » Security Myths and Passwor on Saturday, April 22, 2006 at 09:06 AM

The problem with “best practices” is that they frequently leave out the significant factor that we are dealing with human beings. I work in the heath care industry, and HIPAA has made access control pretty important for us. We also mandate regular password changes, and the policy is that a password cannot be reused until some number of changes has occured. When that number was 3, I could remember the three passwords I used, and keep that information more or less secure in my head. Then someone decided that the number of changes ought to be increased to 8 to provide even more security. What most people did in response to this was to use a base password with a different number that end. I did something slightly different: I typed up a list of my 8 passwords and keep it in my desk. In any case, my estimation is that by increasing the number of changes from 3 to 8, the actual level of security has decreased.

Posted by Kevin O'Brien on Saturday, April 22, 2006 at 09:10 AM

[...] read more | digg story [...]

Posted by r00tware » Security Myths and Passwords on Saturday, April 22, 2006 at 09:41 AM

I agree with most everything you’ve said.  However, expiring passwords on a regular basis will help protect a network against accounts that should be disabled/removed due to staff turnover, but have managed to slip through the cracks.  Granted, accounts that “slip through the cracks” reveal other operational weaknesses, but it does offer at least some protection until an account audit can be performed.

Posted by Court on Saturday, April 22, 2006 at 10:06 AM

[...] In this post Prof. Eugene Spafford of Purdue talks about security and passwords. There are so many buzzwords and scare-tactic marketing in security that most of the non-technical people I know are reduced to the cyber equivalent of burnt offerings: they subscribe to some (often) dysfunctional security product and then cross their fingers. They don’t have the time and energy to understand where the threats are and how to avoid them (like using Firefox instead of IE, for example). This article briefly delineates the major threat modes for passwords and then offers some thoughtful advice. [...]

Posted by StorageMojo » Password Misses and Myths on Saturday, April 22, 2006 at 10:45 AM

In my industry (Healthcare in Alberta) we are struggling with implementation of enhanced security (ISO).  Our move to strong passwords that expire every 45 days has provided some security but has definitely caused most users to has a negative opinion of security efforts in general and a certain percentage of users to write down, share passwords, in some cases never log off rather than going through the process of changing passwords.  We need to find a new way, people have too much to remember as it is, we do not live in a perfect world of integrated authentication and single sign -on.  At the end of the day our policy has led to more breaches, not less.  We are in the process of changing to a 90 day expiration period.  Security is not about rules that never change, it is about responding appropriately to identified threats.

Posted by pcjohnson on Saturday, April 22, 2006 at 11:04 AM

I believe the author’s conclusion is still probably valid, but I think the author is missing an argument which favors periodic password changes.

If a password is compromised, that security breach gives the attacker access to sensitive data and services for that moment.  If the user’s account grants access to historical information (saved emails, older documents, etc.) then the attacker would gain access to those sensitive items as well.  The attacker only gains access to FUTURE documents and services for as long as the login credentials are still valid.

If the user leaves the company, those credentials aren’t valid for the attacker any longer.  If the user doesn’t leave the company for many years, those credentials are valid for many years, and the attacker will have access to many years of documents and/or services.

If the company requires users change their password every month, the attacker would lose access to future information for the same period of time the user doesn’t use the same password again.  If the user changes their password monthly, and NEVER reuses old passwords, an undetected attacker would not have any future access to this account without exploiting a new security vulnerability.  If the user never changes their password, the attacker would conceivably maintain access to the user’s account indefinitely.

Requiring users change their passwords at intervals limits the impact of some kinds of security vulnerabilities.  A password-changing policy is still likely to do more harm than good, but this kind of policy is not without merit.

—Michael Spencer

Posted by Michael Spencer on Saturday, April 22, 2006 at 11:24 AM

anonymous at April 22nd, 2006 at 1:23 pm posted a comment that is amazingly wrong. Changing a password does not change the probability that it will be guessed at all. Do the math! Assuming passwords are randomly distributed in the keyspace, the probablity that a guess matches a password is the same independent of how often the password changes. (The above assumes an online attack. If you have an offline copy of a list of encrypted passwords then you need to guess them before they become stale.)

Posted by David Phillip Oster on Saturday, April 22, 2006 at 11:30 AM

Entropy. 
You can consider regular password changes as a way to artificially increase the entropy of a password, making brute forcing the password more difficult in a given period of time (yes, assuming the change interval is smaller).  Same function as complexity requirements.

Posted by jimmy on Saturday, April 22, 2006 at 11:58 AM

As a multi-hat (admin,pgmr,user,etc…who isn’t these days?) with dozens of systems to maintain, I have some 70-80 different ids/passwords for the systems I have to access. These are typically all different (though similar) due to password aging and complexity differences, and range from 4 digit PINs to 20+ chr “pass phrases” and secure card tokens. 

So forget the piece of paper, I have to use a “little black book” to keep them all. With a dozen or so changes per month, it gets full of permetations and erasures fast! 

Obviously, this security control method does a pretty good job of mainly keeping me out of the system, but probably not that great against someone interested in hacking. 

I suspect most successful hacks are not by attacking passwords, but exploits or social engineering.  You could change your password every day, but if your system is unpatched, who needs the password!

Posted by Russell on Saturday, April 22, 2006 at 12:49 PM

Password are, and will always be a weak form of security. To have a secure system, corporations (or individuals) must use a system with multiple level of security. A combination of Password and Secure ID tag is a perfect exemple of this. ANY password can be cracked fairly quickly by using cracking software that uses rainbow tables to break down even the most complex password.  Even if you are using complex password with special charater, your password will be easily cracked with software like Ophcrack 2. <a>. In the article we’ve only been using the standard alphanumerical character set, but the cracking process can easily be done via a full charset.</a>

Posted by [GEEKS ARE SEXY] Tech. News on Saturday, April 22, 2006 at 04:53 PM

Sorry, the commenting system removed the link to the article. here it is: http://geeksaresexy.blogspot.com/2006/04/cracking-your-windows-sam-database-in.html

Posted by [GEEKS ARE SEXY] Tech. News on Saturday, April 22, 2006 at 04:54 PM

[...] read more | digg story [...]

Posted by my weblog » Security Myths and Passwords on Saturday, April 22, 2006 at 10:17 PM

Taken alone, forcing monthly password changes is not effective.  Any good information security officer should enforce other password security schemes such as:
- minimum password lengths
- force a combinaton of letters (a,b,c…) and numbers (1,2,3…)
- password is rendered inactive after a defined number of tries
- ID owner is alerted if several wrong password attempts

Posted by Monsolo on Sunday, April 23, 2006 at 12:49 AM

[...] I was quite surprised at a blog from CERIA (Security Myths and Passwords, written by Purdue professor) as well as its corresponding Digg article. [...]

Posted by Techno Pinoy on Sunday, April 23, 2006 at 02:01 AM

[...] link [...]

Posted by MogBlog » Security myths & passwords on Sunday, April 23, 2006 at 11:50 AM

[...] Articles/Features FBI’s Top 11 Deaths of the Year Lost Levels - Pescatore Top 10 Windows XP Tips Of All Time Security Myths and Passwords The World of Final Fantasy Seanbaby’s Worst NES Games of All Time [...]

Posted by The World of Jakanden » Weekend Linkage on Sunday, April 23, 2006 at 02:45 PM

[...] Spaf: Security Myths and Passwords [...]

Posted by Security Wonk - Periodic Password Changes a Waste on Monday, April 24, 2006 at 07:57 AM

Leave a comment

Commenting is not available in this section entry.