The need for Public Password Policies

After reading the Dashlane report on “The Illusion of Personal Data Security in E-Commerce”, I kept thinking about how developers replicate common security mistakes and that real progress in security rarely occurs.

The industry’s current password policies are a disaster. It seems every week a new company has been hacked. There are services that will check if your password has been leaked. There are dozens of tools that can take “encrypted” passwords and crack them. DEFCON has a password cracking contest every year, and I believe 90% of the companies don’t know how bad their password policies are. There is a more fundamental problem here. A dozen password managers and a dozen reports won’t fix the problem.

In simple terms, we – the users of the Internet – need all web services to have a Public Password Policy with the following characteristics:

  • Each server/service needs to have a well defined password policy.
  • This policy needs to be able to be parsed (and enforced) by computer programs.
  • This policy needs to be available to other computers on the network.

This will provide immense benefits end users, companies, business partners, software developers, and security service organizations.

Let me describe why.

What are the advantages of a Public Password Policy to an end user?

Let’s say I’m a user who wants to create an account to some web service, which could be a bank, a store, or a social network, etc. Perhaps I have a choice of stores or banks. As a security-minded individual, I have lots of questions about security, but let’s focus on just the password I need to create. Here are my questions:

  1. How confident can I be that my password will resist attacks?
  2. How can I use an automated tool to automatically generate a very secure password?

First of all, I have the right to know how my password is protected on a web site. Is the password stored in plaintext? Is is encrypted or hashed? What is the algorithm? What is the strength of the algorithm? Is it salted with some randomness? Does the web site  truncate my password, and if so, what is the maximum number of characters I can type?

If I know that a site has poor password policies, I might change my mind, and pick a different store, bank or service, or product.

In addition, I want to know how I can generate a really strong password. I want to know the minimum and maximum password length. I want to know the characters I can use. And I want to know automatically.

I use automated tools to generate passwords

I currently use Lastpass to automatically generate passwords. While it has a lot of features, LastPass and the other password managers like  KeePass, DashLane etc. can be improved dramatically if the site had a Public Password Policy. Currently I have to manually specify the  character set, and password length when I generate a new password. I have  to look at the web site, and then tweak the settings of the tool to match the requirements of the web site. And do you know what’s really sad? I often can’t tell  the maximum password length I am allowed to use.

For those who don’t understand password storage, here’s a short summary. Security sensitive web sites often perform a one-way cryptographic hash on a password before they store it in a database. These functions can take a large block of data and convert it into a smaller block of a fixed size. Therefore limiting the length of a password doesn’t reduce the amount of data stored – it’s constant. And the longer the password, the harder it is to guess.  Yet I often don’t know what the maximum length is when I create a new password.

For instance, I may want to use 4 randomly chosen English words, like “plugging thunderless homicidal jackleg” instead of a 20-character string  like “mJ4m#ronLP75kGadFRho”. Typing special characters on a smartphone can be awkward, and it’s much easier to remember 4 words for a one-time use than 20 random characters.

If I used the 4 words above, and the password was truncated to 8 characters, then my “strong” password would be “plugging” – which can be discovered easily with a password cracking tool. I’d be upset if I thought I picked a strong password that became trivial to guess because the web site hid their policy from me.

Yes, I can pick a default pattern that works for 95% of the web sites, but then I’d be using the lowest common password policy. And how often would I tweak my rules when I visit a different site?

Therefore we need password generation tools that can (a) get the password policy from a web site, and (b) use this information to automatically pick a really strong password, while (c) making it easy to use.

Better software integration between the web site and the end user will promote better password managers, and a seamless experience may actually reduce the dangers of password leakage.

But let’s not stop here. Let’s look at it from the perspective of the asset owner:

But a Public Password Policy will let my web site be hacked!!

Yes. It will. But as Dashlane demonstrated, the password policy can be discovered anyway. Trying to hide the policy is security through obscurity, and I always tell people

“Security through obscurity provides temporary security that weakens over time.”

As long as we hide systems instead of using open systems based on Kerchhoff’s Principle, we will be forever in the Dark Ages of computing. We have to evolve to new secure frameworks, and a Public Password Policy will be a step in that direction.

What are the advantages of a Public Password Policy to web site owner?

There are several:

  1. A Public Password Policy forces the business owner to document their policy. They can no longer claim ignorance. A formal description will force organizations to agree to a real, documented policy. People who do risk assessment often get blank looks to questions like “What is your security policy?” so requiring a documented policy is already an improvement.
  2. With the right software, the policy can be used to configure the system. Changes in the policy (like requiring a special character), can cause cause new behaviors in the system (i.e. rejecting new passwords that don’t have a special character). Therefore the securtiy policy can be used to change the security posture of the web site.
  3. The policy becomes a product specification, which can be used to select a suitable system  and/or configuration.  If a product cannot meet certain minimum requirements, it can be discarded early in the design process. RFP‘s can be sent out with the desired password policy, and vendors can select components that can meet the desired objectives.
  4. Managing multiple policies becomes easier. Having to deal with a dozen web servers with different policies becomes easier because they can be collected, compared, and managed. It becomes easier to find services that have the weakest policy, of those that lack a certain feature. Security management becomes easier.
  5. Business partnerships become easier. If businesses interact, policy mismatch becomes obvious. Suppose one division requires special characters, while another does not allow them. If this occurs, then you can’t merge  two systems into a new service without requiring one group from resetting everyone’s password.
  6. Audits become easier. Not only can outside agencies examine policies and offer recommendations using automated tools, outside experts can use tools that validate that the policy is enforced. Better tools will simplify this task.

So end users benefit, and web site owners benefit. But there’s more.

How does a Public Password Policy affect software developers?

  1. Software developers can be given a formal specification that will guide in the development and configuration of the software used to approve/reject passwords, along with the storage mechanism, algorithm etc.
  2. A formal specification will encourage modular and replaceable components used to manage passwords. A company can state what their policy is, and then shop around for components that can meet the specification.
  3. Using the specification to control the configuration encourages software developers  to develop flexible password management systems that can be configured for varying degrees of protection.
  4. If the language describes features that the software developer doesn’t support (i.e. a salt is used before hashing), the software developer will be encouraged to add new capability to keep up with evolving requirements. This would also encourage drop-in replacements for existing systems that need to be compatible with existing usage, but provide the capability to ramp up the protection over time, i.e. replacing MD5-based passwords with SHA-1, SHA-256, or PBKDF2.

What’s next?

The first step is realizing that there is a need. I hope this encourages others to discuss the need for Public Password Policies.

I realize this won’t have a major impact – it’s not going to make a big dent in all of the security problems. But it’s a step to a more secure framework. We need to have a security policy that can control the configuration, which controls the implementation.

How could this be implemented? There are several ways. A simple text file can be stored on a web serve at a specific URL, or a special port and service can be used. The information can be stored in YAML, JSON or XML. Prototypes need to be build and proven. The IETF can generate a RFC.

Perhaps a better solution is to have a formal language and use the Semantic Web as a mechanism to specify and verify the language. This would not only allow syntactic and semantic errors to to identified, but rules could be created that examine and evaluate policies, which can provide metrics, recommendations, warnings, etc..

But to be really successful, a language has to be developed that can be understood by policy holders (i.e. not geeks) while being understandable by computers. I’ve used SADL and perhaps this can be used.

I’m looking forward to your thoughts.

This entry was posted in Security, Technology and tagged , , , , , , , , , , , , . Bookmark the permalink.

2 Responses to The need for Public Password Policies

  1. grymoire says:

    As en example, I just spend 5-10 minutes trying to generate a strong password with LastPass at a former employer’s site. The site listed 5 requirements for a new password. However, after following their rules, my password was rejected. Here were the reasons:
    * The maximum password size is 15. 16 is not acceptable.
    * A special characters is required, but only “@” and “_” are considered special. “#” and “%” are not
    * Numbers cannot be at the end of a password.

    None of these rules were listed. I only discovered them after I generates a new password, filled out 6 other fields, and pressed submit. And every time my password was rejected, it erased all of the fields, so I had to start from scratch each time.

  2. grymoire says:

    Nick Selby @nselby noted that when he registered for the Blackhat conference, it rejected his password because the web site said his password, which was “q=k$Z<arYc%55", wasn't strong enough. In reality it was because it had a "=". This is obviously a flawed decision for rejecting a password, because it actually encourages people to use weaker passwords. In addition, it can only be discovered because a strong password was rejected. This sort of bone-headed choice could be discovered very easily by a simple search engine if the policy was public.

Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s