November 14, 2014 | 7 Min. Read

Is Your Password….Too Strong?

Memorizing passwords may be the most secure technique for keeping passwords safe, but password managers have many valuable benefits.  One benefit is that a strong, unique password can easily be generated for every login that you use.  Over the last couple months, I have been making an effort to migrate all the passwords I use into a password manager program and allowing the program to generate a new password for me.

As I updated my passwords, I quickly ran into a surprising problem.  On most websites when setting my new password, the password strength bar would go well into the green. Everything would work great until I started to come across sites that my password did not meet the strength requirements for because it was…too strong!

At first I thought the randomly chosen password was missing the use of a number or symbol,  but I realized that it was the website’s definition of a “valid password” that was causing me issues.  I had misread “must not contain symbols” as “must contain” since that is what I typically expected.  I found that most websites would have their own variation on what was acceptable to include in a password, including some of the following:

  • *Must not contain special characters
  • *Only lowercase letters allowed
  • *Must be less than 8 characters long
  • *Cannot contain any of the following characters: !@^*[];:’”.,~
  • *Must start with a capital letter
  • *Only numbers may be used
  • *Password must be exactly 6 characters in length

The list of requirements reads like a bizarre anti-strong password definition.  I noticed a trend in what type of places had these requirements: banks and large businesses not in the tech industry.  It didn’t seem too surprising that non-tech companies were imposing strange / poor security policies, but that the banks did actually surprised me.

Implications of Password Limitations

It would seem like not a week goes by where the topic of banking information or credit card theft is in the news.  Banks obviously have a lot to lose if customers’ accounts are compromised, yet they also seem to have the worst password security.  One of many examples is JP Morgan, recently in the news for security vulnerabilities, who has a password policy that disallows passwords which are more than 10 characters or contain symbols.  Someone who does not have a background in computer security might simply think that it is ironic for banks to choose these kinds of policies, but as a security professional, I immediately start to think of the implications and reasons behind such practices.

From a business perspective, none of the websites with these types of policies posted any description as to why they had decided on their password requirements.  While there are a lot of speculations, a common reason assumed is that many of the companies may have compatibility issues with internal legacy systems.  This would seem to match well with the types of companies that have this issue; banks are notorious for legacy hardware and systems, and non-tech companies are likely not too different.

What Is Dictating Password Limitations

A company with a website that handles passwords will generally have the following internal components:

  • *A web server, running a web application
  • *A database (this may be independent, or managed by a separate application)
  • *A backend application (optional)
  • *A backend authentication server (optional)

n-tier-architecture-2Image Source: http://tutorials.jenkov.com/software-architecture/n-tier-architecture.html

 We can consider how each of these components communicates and interacts with passwords to get a better understanding of how various companies are likely running things internally and what could be dictating the limitations on passwords.

Web Server Running Web Applications

Over the last 20 years, web applications have been written in a huge number of programming languages, and almost all modern web applications will be built on top of some type of framework.  When it comes to password handling, the main consideration will be what character set is supported by the programming language or web framework.  Support for international character sets may not be present in all frameworks, but support for standard ASCII characters definitely is.

Conclusion: All of the items being restricted fall well within the ASCII character set, therefore the limitations must exist elsewhere.  

Databases

The term database brings to mind the thought of mainframes and stacks of servers.  While this is no longer true and your phone is probably running 3 database instances right now, it would match well with the theory that legacy systems or their databases are the cause of the password limitations.  The following are a couple ways how this is possible:

Query Languages:  The means of communicating to a database from other applications and systems is accomplished using a “query language” for storing and retrieving data.  The syntax used with this query language is extremely important, and many characters have special meanings.  A few examples of these “special characters” are quotes, double quotes, and semicolons.  As with any programming language, if you need to use special characters in your database query, the proper procedure is to “escape” them.  Passing data without properly escaping may leave databases vulnerable to SQL injection attacks and a strong chance that an attacker will be able to gain control of the database.

Conclusion: Avoidance of allowing special characters means avoidance of vulnerabilities that result from not escaping data, but this artificially limits passwords.

Storage Space: Many databases can be configured to set a maximum length for a particular field of data for efficiency purposes. However, the space consideration between storing an 8 character password and a 50 character password is insignificant.

Conclusion: Password limitations are not dictated by storage capacity of the characters because the amount of space required is minimal.

Backend Applications

For password limitations to be an issue with backend applications, the architecture in use must require that these backend applications actually store the users’ passwords.  If a company’s website is not simply a frontend to a backend application, it implies that a user’s password is being stored by multiple systems and more likely that the password is not being stored in an appropriately secure manner.

Conclusion: If the password limitations are due to a backend application which has been designed so that it cannot accept passwords that are more than 8 characters, the odds are slim that it has also stored that password as an appropriately strong hash.

Authentication Servers

Authentication systems definitely support the use of strong passwords, so the systems themselves are unlikely to be the issue!  Many authentication systems support a query language similar to databases, so once again, proper escaping of queries could be an issue.

Conclusion: Preventing a user’s choice of passwords instead of properly escaping the data seems quite ironic if a company has gone to the effort of using an authentication server, but this too could be a reason for limitations on passwords.

Frightening Reality

There are an endless set of possibilities beyond these general components on how the passwords are being stored or used to contribute to the limitations on passwords. However, at the end of the day regardless of these reasonings, as long as corporations comply with the widely accepted (demanded even) security practice that passwords not be stored in plaintext this issue should not exist.  When a password is transformed from plaintext into a secure hash, then the output from the hashing algorithm will always be fixed length, and usually converted then to base64 or hexadecimal, so that escaping will no longer be the issue either.

By definition then, if a website cannot handle a password with more than 8 characters, numbers and symbols, it is unlikely they are hashing the password.  This means that if the website in question is ever hacked, chances are good that your password has been fully compromised, no matter how strong you tried to make it.

What Can Be Done

Using a password manager is what led me to realize how common this issue was.  It’s also a great way to limit the impact of companies’ poor security practices.  By using a unique password for every website, the impact of one website being compromised will effectively be contained.  Instead of trying to look up if your password was leaked as part of the latest “insert company name here” compromise, you can be confident that all of your remaining accounts are secure.

The companies which impose these requirements that limit passwords should give serious consideration to the message that they send their users by setting these policies.  With more and more compromises being made public, companies should also investigate what legal liability may result from not only encouraging, but enforcing poor security practices.

Leave a Reply

Your email address will not be published. Required fields are marked *