5 properties of passwords that must be managed to reduce risk

Security legend Bruce Schneieropened up a can of worms,” as he himself put it, when he agreed with usability legend Jakob Nielson that applications should not mask passwords as they are being entered. This is surprising from Bruce, who regularly harps on balancing cost against risk reduction, but his follow-up post does a nice job of addressing the pros and cons of password masking.   

For the question of password masking, the obvious security benefit of masking (reducing risk from shoulder surfing) is to some degree counteracted by a less obvious cost (masking may make it harder to enter a password, so it may discourage use of complex passwords).

This is a good reminder that there is in fact a number of password policy issues that on their face increase security, but in fact may actually decrease security when usability is factored into the equation (moreso in most cases I think than does masking):

  1. Password masking
  2. Password complexity is good for protecting against brute force password cracking (but how often does that happen?)
  3. Making passwords regularly expire limits the damage from compromised passwords
  4. Locking out accounts after a certain number of wrong attempts prevents one type of brute force cracking
  5. Rigorous authentication before replacing a forgotten password makes it harder to socially engineer around a simple “secret” like their pet’s name that someone might have to answer

The problem with all of these is that they reduce the usability of passwords.  All of them make a user more likely to do insecure things:

  • Use a weak password
  • Write down their password
  • Use the same password across multiple sites

The best setting for these five properties depends on various factors of each situation, but I think in general security folks worry more than they should about protecting against brute force attacks, and much less than they should about the insecure behaviors above.  In particular, the complexity and reset rules (2&3) are usually taken too far, and more sophisticated alternatives to lock-out (4) where the rate of possible login attempts is decreased with each error are not taken often enough.

Here for example are some data around how often people write down their main corporate login password (N>100,000):


Edited 7/13/09 to add:

Schneier posted today on this subject, referring to an article that concludes that (overly) strong passwords don’t accomplish anything. Unfortunately they seem to endorse a “3 strikes rule” (issue #4 above), rather than a more user-friendly approach of reducing the possible rate of login attempts. This can easily be engineered to prevent brute force cracking without a full lockout. 

One other comment that didn’t make it into the original post: all password complexity is not created equal. Numbers and symbols add a similar amount to password entropy, but create a very different user burden. Maybe Jakob Nielson can do some usability studies to determine the right balance.

Explore posts in the same categories: Awareness, Identity and Access Management, Risk Management

5 Comments on “5 properties of passwords that must be managed to reduce risk”

  1. Bill Wells Says:

    Rules that enforce password complexity would seem to eliminate the risk of a user using a weak password. People will write their password down whether it is masked or not, so I’m not sure masking really plays a strong role here. And masking, by itself, will likely not be the factor that strongly influences their decision to use the same password across multiple sites. I would tend to believe that people will make this decision based more on how many passwords they want to have to remember.

  2. Jeremy Bergsman Says:


    Agreed that masking is likely the least important of these password policy properties that drives users to insecure behavior. (This is why I thought the furor over the minor usability issue of masking deserved comment.)

    I don’t agree about the effectiveness of complexity rules.

    First, while such rules may help, they hardly eliminate the use of weak passwords. You can ensure that passwords have some minimum length, a mix of cases, a minimum number of special characters, etc. But, as is well known (e.g. http://blog.jimmyr.com/Password_analysis_of_databases_that_were_hacked_28_2009.php), people tend to gravitate to certain passwords, and they can do this for most any complexity scheme (“Blink182” is a popular band and a popular password). Again “enforcing complexity” focuses on the security perspective but fails to consider the mindset of the user.

    Second, to the extent enforcing complex passwords is successful at getting users to select truly strong passwords, you are still just falling into the same trap I address in my post, where you are driving users to do something less secure (write it down) than the behavior you’re trying to stop. When *half* of users are writing down passwords, a smart intruder is just going to find a way to look under someone’s keyboard, not try to assemble a supercluster to crack a password.

    Instead of an escalating arms race between security and users, we need to help users do the right thing. Training in how to, say, use anagrams and other simple algorithms to generate strong but memorable passwords is good. Such training that appears on password reset screens is better. And where I again agree with you is that reducing the need for users to remember a lot of passwords is best.

    • Bill Wells Says:

      I guess I wouldn’t consider “Blink182” a strong password. A strong password would be one that requires the use of special characters, in addition to the traditional alphanumeric upper and lower case characters. I also believe we are approaching a time when the long-recommended 8-character length needs to upped to a minimum of 12, though I’m certain the users would find this change “unfriendly”.

      I agree, though, that training is a key element of security and that security can only be successfully implemented with behavior changes in users. That said, there’s a fine line between what is considered “friendly” and “unfriendly”, and the line will move depending on who your audience is, management or operational staff.

      One other thought to add to the conversation…

      Brute force attacks to crack passwords do not seem to be making the headlines like it used to. Instead, we see more phishing and social engineering methods employed to obtain the users’ passwords. Strong passwords will not help in these situations.

      So really, it comes down to raising the bar on what a typical worker needs to know today in order to be a valued protector of information assets while they perform their job responsibilities. This also means that management needs to be educated to the risks and impacts of not educating the users.

      We continue to see further additions to the ever-growing body of evidence that points to the insider threat: people authorized to have access, but doing things–often simply for the lack of knowledge of the potential consequences–that are not secure.

      Training and awareness is the first step to user behavoir change.

  3. I agree to much of the post, but I’m not very enthusiastic about the “more user-friendly approach of reducing the possible rate of login attempts”.

    I see too much of a risk of DoSing the password field, so to speak. If one can’t access a user’s account, what’s to say an attacker wouldn’t just want to disrupt service? With increasing (or just long) login delays in case of bad authentication you’d easily disable much of a user database temporarily.

    But maybe that’s not actually a problem at all, though. Just combining the delays with an IP-check could be a quick solution (“new IP? no delay!”). Even though the tor network spans widely… Also, it’s more work for the programmer and adds an unnecessary load to the system imho.

    With that said, I think its application would be best for non-networked environments.

    • Jeremy Bergsman Says:


      I think DOSing an account is a rare occurence, but in any case the situation is improved, not worsened, by changing from a “three strikes and you’re locked-out” rule to an escalating delay. In the traditional three strikes regime, an attacker can deny service with only three hits.

      The IP check would help against DoS attacks, but allows a distributed attack the potential to brute force the password, so I think that may be too much effort and security loss for a minimal usability gain.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: