The password. It’s been used for thousands of years and today represents the key security token in modern computer systems. Despite its ubiquity, the password is not well loved. Attitudes towards passwords vary from apathy to downright contempt. Very few people would ever stand up and argue that the password is a good method of securing a system. IBM predicted back in 2011 that the password would be dead within five years. However, while the giants of the technology industry are rushing to consign passwords to the dustbin of history, nobody seems to be asking whether the problem is with passwords themselves? Or whether our approach to implementing and using them is wrong?
Passwords are used to provide authentication. That is, to validate you have legitimate access to the user ID secured by the password. There are four authentication factors:
- Something you know: These are the simplest factors and include passwords, PIN codes, and pattern identifiers.
- Something you have: These are physical objects, and usually take the form of an electronic device that displays a secondary PIN code.
- Something you are: This covers biometrics – Fingerprints, iris scans, and voiceprints.
- Something you do: This is a newer and more novel field that covers factors such as typing speed and gait analysis.
Two-factor or multi-factor authentication is where authentication requires elements from two or more factors (such as a password and hardware token.)
Our approach to password security is wrong
The current advice for creating a strong password is to use at least eight characters, mix your cases, and then add a couple of symbols. H4x1p£Lo therefore would be considered a strong password. A password like this would be immune to dictionary attacks (Testing words from the dictionary), and if hashed properly (Something we’ll come onto in a minute) would be immune to Rainbow Table attacks. This means the password would have to be brute forced. Let’s consider this:
- There are 97 printable characters on a standard UK keyboard
- Any of these characters can be used in the password
- Probability suggests that a password can be found after evaluating around half the possibilities
An eight character password gives us a complexity therefore of 978. This gives us 7,837,433,594,376,961 possible combinations. This should allow a match to be found in 3,918,716,797,188,481 combinations. Given a billion hashes could be tested per second, a match could be found in around 45 days. For a high-value application, this level of security is likely insufficient.
What happens though if we through out the requirements for complexity and instead ask you to choose five random words that are at least five characters long? Take Cheese Straw Wizard Phone Window. We now have two ways to go about attacking this. We can use the brute force method, as we did previously, or we can use a dictionary attack. Given some words are unlikely to be used, 100,000 words would be a good size for our dictionary including capitalisations plus spaces. Our complexity with a dictionary attack is therefore 1000005. This is 1×1025 possibilities. Given the same processing speed as the previous example, this password would take 158 million years to crack.
What about a brute force attack. Assuming we know that the password will consist only of letters and spaces, our character set is 53 characters. Our namespace is therefore 5332, or 1.5×1055 possibilities. At the same speed as before, we should be able to brute force a match in 2.4×1038 years.
What does all this mean? We’re putting a vast amount of effort into educating users how to create passwords that are both hard to remember, and relatively easy for a computer to solve. When passwords are hard to remember, this provides strong security from attacks against the password itself and instead changes the risk from technological to human:
Bob, you’re the risk… Not your password
Good passwords require good software
As illustrated, it’s easy to generate passwords that are infeasible to cryptographically crack. So why then do we continue to see breach after breach after breach? The answer appears to be twofold:
First, poor user interface design encourages the misuse of passwords. Email software in particular is a prime example of this. Person A is going on holiday, so they give person B who is covering from them the passwords to their accounts. Person B can now do their job, but the security of those passwords has been compromised. On the other hand, if delegating access to another user was made simple, the problem would be solved. Person A can easily delegate access to person B. Person B can log into person A’s email using their own credentials and all is well with the world.
Network design also suffers from this problem, if not designed correctly, network access to resources tends to be assigned to individual users rather than groups of users. Role-based Access Control is the solution to this problem, so that all users requiring access to a resource gain access through being a member of a role group. In short, poor design results in poor user behaviours. It is possible, through ongoing user education to deter some risky behaviours, but so long as the software and systems fail to meet the user’s needs, then a degree of risk acceptance will always need to take place.
The second part of the problem is purely technical. Passwords should be secured using strong hashing algorithms. These generate a one-way hash, or signature of the input. Some software designers decide for various reasons not to do this. In the worst cases, passwords are stored as plain text, making it trivial for an attacker gaining access to a user database to compromise every account. In other situations, passwords are encrypted rather than hashed. This secures the password in almost all cases, however a key will be needed to validate the password. If the database is compromised, there is a risk the key will also be compromised. This creates the same result as not encrypting the password in the first place.
In fairness the above password storage mechanisms are widely acknowledged to be insecure, and are therefore rarely used. A much bigger problem is the use of insecure hashing algorithms, especially when used without salting. The MD5 and SHA-1 algorithms are known to be cryptographically weak, and their use discouraged. Yet many applications continue to use them. This leaves the passwords open to cryptographic attacks (which for MD5 can quickly reveal the password.) Many systems also fail to salt their hashes, which allows for Rainbow tables to yield passwords.
While this latter problem exists, no amount of user education will stop the type of breaches we keep seeing, where large lists of passwords are stolen and then reverse engineered.
What’s the solution to the password problem?
The solution appears to be complex and multi-pronged. Application designers need to take password security seriously, employing modern hashing algorithms such as SHA2-256 or SHA2-512. Salts should be appended to the passwords to deter the use of Rainbow Tables. Applications should be designed with features that avoid use cases where password sharing becomes the easiest option. Users should be taught to use very long passwords that are easy to remember. User awareness should focus on deterring password sharing and highlighting the alternatives.
Multi-factor authentication is a possible solution, but not without its downsides. Authentication schemes that use something you have generally add additional complexity for the developer – requiring additional infrastructure. Companies such as Google offer low-cost solutions, but these come without guarantees. They are also inconvenient for the end user, requiring them to carry around some type of physical token. Authentication using something you are is more convenient for the user if they only log in from a location with an appropriate biometric scanner. The downside to biometrics is that should the identifier be compromised, there is no way to generate a new identifier (You can’t grow new fingerprints). The final type of authentication, something you do could be a solution. Technologies such as typing speed analysis can be implemented in software, with no additional burden on the user beyond having them train the system. This type of authentication is still in its infancy, so it may be a number of years before we see it used in practice.
With stronger password security, we should find ourselves in a much more positive position. Yes, data breaches will continue to occur, but the best the attackers will get will be a useless list of random hashes that are totally worthless.
