Common Sense Passwords

Disclaimer: As with all security operations, always act in accordance with the highest standard of legality and ethics, making sure you have the proper authorization for any security exercises in which you engage.

By Brad O’Hearne

What problem are passwords meant to solve?
Having parented three sons during the youth sports era of the “participation trophy”, I have often thought about how this philosophy pervades technology. For those who have somehow missed this phenomenon, many youth sports leagues have erased the notion of winning, losing, and even keeping score, awarding every player on every team a trophy at the end of the season. It is easy to dismiss it as a Saturday morning amusement, but is it any different back in the technological world on Monday?

Tech initiatives are very often driven by the perception that doing something, anything, and merely participating is equivalent to forwarding progress. It isn’t, and maybe there’s no better example of this in the security field than password management. The mantra “use strong passwords” is as burned into everyone’s brains as is the Nationwide Insurance commercial jingle that one of my sons occasionally breaks into for no reason while playing a game on his iPhone. But does anyone know what having a “strong password” actually means?

Nearly every web site password creation page defines a strong password differently. Many sites show a password-strength progress bar that turns from red-to-green as you type theoretically more complex characters. But try the same password on multiple web sites, and what is considered a strong password on one site may be considered weak on another. Requirements also vary tremendously: lengths vary, some require varying characters be used: lowercase, uppercase, numbers, symbols, or all of them, or only some of them, or some of them but prohibiting others. In fact, I encountered just this week a major credit-card processor which required that passwords be an exact length – and shockingly worse, that length was 12 characters.

Does anyone even remember what problem we are trying to solve with passwords? The way passwords are commonly managed demonstrates a lack of understanding about how passwords can be cracked, and more importantly, it demonstrates a loss of focus on the actual problem at hand. The purpose of a password is to accurately verify the identity of a user. Restated: a password must act as a unique symbol which only the proper user can produce. Therefore, a truly strong password is one which provides maximum resistance to anyone attempting to crack it.

How hackers crack passwords
To understand how to construct a strong password, it is important to understand how hackers crack passwords. In short, the time it takes to crack a password is a function of three primary things:

1. Keyspace: the number of different characters which can be used in the password.
2. Password length: the maximum length of the password.
3. Processing power: the number of passwords which can be generated and attempted within a period of time, determined in large part by hardware capability.

There are additional elements such as hashing algorithms and randomness (called “salting”) which can influence cracking speed. But in general, the three factors above will still primarily govern the time it takes to crack a password. Approaches towards storing passwords vary, but while not recommended, the most common approach I’ve seen is to store the SHA-1 hash (unsalted) of the original password.

Using this approach, I experimented against passwords from an infographic published by the PCI Security Standards Council entitled: “It’s time to change your password”:

https://www.pcisecuritystandards.org/documents/PCI-Password-Letter.pdf?agreement=true&time=1502716087229

In this infographic, nine passwords are shown with their respective time to crack the password. Here’s the list of passwords:

The estimates shown assume a sequential, pure brute-force attack. But that is not how an attacker is going to crack these passwords. Here’s the reality: on a Windows 10 desktop with one graphics card, using a publicly available wordlist, I cracked the first six of the passwords above in less than a minute total for all of them. The others I’d guess could be cracked in less than a day given the same wordlist and a rule-based. So why the mismatch between the estimates above and the reality?

At its core, password cracking is a math problem. The bigger the numbers involved, the longer it will take to compute the answer. If the size of the numbers can be reduced, the math problem can be solved in a shorter amount of time. Rather than brute-force every possible combination of characters, it is much more efficient to reduce possible password combinations using wordlists. Popular wordlists have literally billions of entries, containing:
• Every known dictionary word for common languages around the world.
• Colloquialisms / common phrases.
• Known passwords leaked in prior major security breaches.
• Dates
• Months
• Years
• Holidays
• Common names for people.
• Common names for pets.
• Etc.

In addition to checking the wordlist passwords, new passwords can be generated by applying rules which do the following:
• Combines words.
• Varies capitalization.
• Adds numbers and symbols throughout the password.
• Rolls and wraps-around password characters.
• Converts to Leet (a.k.a. “l337″).
• Uses specific patterns of letters, numbers, and symbols.
• Limits password checks by length and character constraints advertised on the web site.

All of these techniques significantly shrink the keyspace that needs to be checked. Note to app developers – if you are publishing password length and character requirements on your web site, you are providing a recipe for more effectively attacking your passwords.

The keyspace reduction principle was demonstrated gloriously in the 2014 movie “The Imitation Game”, about Alan Turing’s role in the cracking of the German World War II Enigma code. The critical scene of the movie takes place at a British pub where a military radio operator remarks that the beginning and end of all German transmissions had common characteristics. Upon hearing this Turing suddenly realizes that these common patterns may be the key to cracking Enigma, and he exclaims that it “…just lost Germany the whole bloody war!”

Turing was right. What was true then is just as true now – reducing the keyspace can transform a pragmatically undecipherable code to something that can be readily cracked. Any mnemonic, personal detail, pattern, name, object, phrase, etc. used in a password can be used to reduce the key space and can be the weakness which allows a password to be cracked.

Why passwords fail
If the approach to password education by security professionals is any indication, security professionals need to reorient their thinking: not using strong passwords isn’t the cause of the problem – it is a symptom. What password a user chooses may be more of a function of pragmatic use, than it is a problem with understanding or willingness to cooperate. Knowledge of a strong password recommendation probably isn’t going to be the primary determining factor in password choice, but here are the factors that will determine it:

• Passwords have to be remembered.
• Passwords have to be repeatedly entered into data entry fields.
• Users have to manage many accounts.
• Passwords usually have to be changed with some frequency.

If a user has a lot of account passwords that they need to remember, type, and change frequently, it quite obviously encourages the creation of short, simple passwords, and password reuse wherever possible. If password education goes no further than “use strong passwords”, then it might as well be restated as “complicate your life.” Password education must provide a better answer than this, or user behavior will remain the same.

Correcting the mistake of security questions
Before getting to the solution for the password problem, a mention needs to be made of one password-related issue: security questions. Predefining a series of questions and answers based on personal details of a user’s real-life as a means to enhance security is an absolutely awful idea. I’m not exactly sure how this was ever deemed a good idea. Security professionals are constantly telling users to keep a tight hold on their personal information, not to choose passwords that are easy to guess, and not to reuse passwords across accounts. Enter security questions, which give third party organizations unnecessary additional private information about users, have answers that cannot only be guessed but are in many cases are freely available with a Google search, and have questions/answers that are reused everywhere. It is the antithesis of everything security professionals preach.

As a user, you can turn this around to your advantage. Choose any security questions, or make them up, and provide an unintelligible stream of characters for the answers. Provide different answers for the same questions on different web sites. Do not provide any authentic answer or private information whatsoever. If you are an app developer with security questions in your app – get rid of them. Depending on your implementation, these may actually be lessening the security of your app and increasing the amount of private personal information you are storing.

Common sense to the rescue
The good news is that when common sense is applied to the real problem, a viable alternative isn’t hard to identify. Every password should present the most difficult math problem possible to compute. Therefore, it should have the following characteristics:
• The length should be as long as possible (64 characters recommended, though if you attempt this you will learn immediately how many apps/web sites don’t allow lengthy passwords).
• It should incorporate as large a keyspace as possible: lowercase letters, an uppercase letter, numbers, and special characters.
• It should involve no mnemonics, words, dates, or any discernible or meaningful information.
• It should be completely random; no patterns should be used.

This establishes the password complexity, but there are some additional requirements which govern its pragmatic use:

• The password should not have to be remembered – better yet if it isn’t even known by the user.
• The password should only be used for one account only.
• The password should not have to be typed.

When all of these requirements are taken into account, then the clear answer is the use of a password manager. A password manager allows lengthy, random passwords to be generated, stored, and used, without a user having to remember them, reuse them, or type them.

Password managers are not new, but at this point, I’ll part with the casual tone which usually accompanies the typical security recommendation. Absolutely everyone on the planet, without exception, should be using a password manager. Every organization should have a policy which provides password managers and makes their use mandatory for every employee. All organization system/service account passwords should be stored in a password management app. Once the challenge of remembering and typing lengthy, complex passwords is eliminated, truly strong password usage across an infinite number of accounts becomes a trivial matter.

There are several fine alternatives out there, such as LastPass (https://www.lastpass.com) and 1Password (https://1password.com). For the management of shared system/service accounts within organizations, Thycotic Secret Server (https://thycotic.com/products/secret-server) is an option. There are others, but the regardless of the password management app chosen, the goal is the same: solve the real problem, and don’t deal any longer with passwords that can be easily cracked. It’s all just a matter of common sense.

About the Author
Brad O’Hearne is a 25-year career software architect/developer, application security expert, and independent security researcher.
He resides in Gilbert, AZ and enjoys cycling, soccer, reading, and spending time with his family. He is available for consultation and can be contacted at [email protected].