Are complex passwords a thing of the past?

08/25/2017
G DATA Blog

"Your password does not meet the security guidelines" - this message will not drive people up the wall anymore after password recommendations have been updated. The 14-year-old password guidelines from NIST are facing an overhaul. This article will explain why.

A couple of days ago, a retired official from the US National Institute of Standards and Technology (NIST) has caused some surprise: he publicly apologized for a document he wrote in 2003. This document contained recommendations to improve the security of passwords. Countless organizations and online platforms have followed the recommendations issued by the institute. The catch: people cannot (and do not want to) remember a password which is secure as per the recommendations, such as „yxc^Vo![“$§oAIS@nrvkeu}ih5tK.-n27\fd“. And even if they could, there is still a massive elephant in the room - those passwords do nothing to increase security.

In organizations all over the world, password guidelines are a cause of frustration for employees. They are forced to change their password at regular intervals and are asked to create a new password which often is composed following rules like:

  1. At least 8 characters in length;
    Some platforms also have a maximum password length (e.g. 16 characters) or enforce placement for certain characters, such as "the first character cannot be a special character".
  2. Mixing of upper and lower case letters
  3. Must contain at least one special character and one digit; no blank spaces are allowed
  4. No reuse of a password which was used in the past 12 months

The original purpose of the document was to get rid of password that were too easy to guess and to replace them with stronger, more complex password that are not guessable. Users on the other hand, tend to make life as easy as possible. A user might therefore come up with a password that is "P@$$w0rd". It is 8 characters long, contains upper and lower case letters, three special characters and a digit, fulfilling all of the password guidelines. After three weeks, he is asked to change the password. But, since humans tend to make life easy for themselves, they often just use an iteration such as "P@$$w0rd2". Three weeks later, it's "P@$$w0rd3", and so forth. This procedure, paired with the guidelines mentioned above, have given rise to passwords that are at best difficult for humans to deal with, but easy for a computer to break. If a certain set of criteria is known, a computer can rule out entire groups of potential passwords. If a computer can assume that a password is 16 characters long at max, and the first character is not going to be a special character, then this already rules out a couple of million combinations. If the system knows that there is only one special character present (of which several are excluded, such as a blank space or umlauts), then this reduces the number if  potential password even further. Dictionaries and rainbow tables simplify the task even further for a computer. When factoring in that affordable computing power is steadily increasing, it becomes clear why change to the current rules is needed. 

 

What is new?

The updated publication proposes changes which will sound like music to the ears of people who have been struggling their entire lives with complex passwords. Particular emphasis is placed on the use of passwords that are easy to remember. They should still have at least 8 characters; a maximum length is not specified, but it is recommended to set the maximum length to at least 64 characters. This would eliminate messages such as "Your password cannot be longer than X characters". Some characters which often were not allowed in the past, such as blank spaces, should also be allowed now. Enforcing a password change after a certain time would, according to NIST, also be a thing of the past. Instead, password changes should only ever be enforced if there are indications that a password has been compromised (e.g. through phishing or other means) - or if the user requests a change because he lost his password. In addition to this, multi-factor authentication is favored. In many businesses this is common already, but not on a broad scale. Some online platforms also offer "two-step verification" for logging into an account, consisting of the user name and password and an additional one-time password generated by a specialized app.  In any case, a user always needs several things in order to be able to access a resource or account. The use of text messages (SMS) as a means of transmitting the second authentication factor is discouraged, based on security concerns.
We have covered the topic in the past and are glad to see those recommendations.

What do those recommendations mean for users and providers?

It is important to mention that the NIST publication contains recommendations which are not legally binding. Many service providers tend to follow the NIST recommendations. Until the recommendations have been implemented, users will not notice much of a change. Many service providers and administrators will still rely on the classic authentication with user name and password, but we can expect to see MFA being used more often than it is today - at least when it comes to major service providers. Some of the current (password-)rules may be relaxed a little.

Those who run online services must ensure that passwords are processed in a secure manner. By the way: reputable providers will never store the actual passwords in their databases or store it with a simple encryption. There have been cases in the past where password were stored in plain text. This used to be the case in some one discussion boards. When clicking the "Forgot password" link on the login page, you were sent the password you had set. This is a clear indicator that passwords are not secure properly. Even major platforms have slipped up in the past: in the wake of a major data leak on the career network "LinkedIn", it turned out that passwords were hashed, as is proper practice, but the hashing algorithm used for this is not considered to be secure anymore. The proposed measures may sound overcautious, but recent cases have shown that they are perfectly appropriate: hardware designed to break into encryption and hashing can try out billions of combinations every second until it finds a match.

The new regulations make it clear that proper account security is not only the task of the user. Providers are also obliged to make an effort. Instead of forcing users to put up with ever more complex password guidelines (which not only don't increase security but are also circumvented through password reuse and the use of  password iterations), securing online accounts effectively can only be achieved by upping server-side security and introducing alternative or additional authentication methods. If a password is compromised through phishing, it does not matter how good and complex the password is. A reinforced door is also of little use if it is either open all the time or if everybody knows where the key is hidden. What can be said for sure is that in the long run, passwords alone are not going to be a sufficient for securing a resource. As computing capacity becomes more affordable and hardware becomes more potent, it is only a matter of time and money for a determined attacker to compromise a password successfully. Having and additional authentication method raises the bar and substantially improves security.

Recipe for (password) security: „Hashing, salting, stretching“

Hashing is not the same as encryption, even though sometimes the two are used interchangeably by the media. Encryption is always reversible, i.e. the clear text can always be reliably decrypted and retrieved through defined mathematical functions.  Hashing on the other hand is a mathematical one-way road, where it is not possible to compute and reconstruct the clear text from the result of the hashing process. While there are things like "Hash collisions", where a character sequence produces the same hash as the original clear text, this is by no means identical to retrieving the password itself. This is where service providers can step in. To facilitate password retrieval, attackers use so called rainbow tables. Those contain (in simplified terms) the hashes of known password such as "123456" or "asdfghjkl". This makes an attack computationally cheaper, because all the computer needs to do is compare lists of hashes. To stay in the picture, the use of rainbow tables makes this mathematical one-way road crumble in on itself. Because of this, in modern systems hashes are "salted" -  a random set of characters (the "salt") is added to the password. The salt is also different for every hash. This already makes the use of rainbow tables economically impractical or even impossible.  A salted hash can then be "stretched" by running it through a mathematical processes called "PBKDF2" several thousand times, which further complicates an attack on a hashed password.The more often the output of the process is run through it, the more difficult it becomes to get a password. The beauty of this is, that this approach also counters the ever-increasing computational power of systems. You just increase the number of times the PBKDF2 function is run and do not have to redesign the entire system. Salt- and password hashing should only use methods which are considered secure at the moment, such as HMAC, CMAC or SHA-3. The only objective of all these measures is to make any attack on a password as uneconomic as possible. If an attacker needs to make a disproportionate effort just to compromise a single password, he will abstain from it in at least 99% of cases and resort to other methods like phishing.

What password do I use then?

If you have grown so accustomed to complex passwords that you feel uncomfortable using anything else, then you do not necessarily need to go out of your way - but at least you would not have to change it on a regular basis. For everyone else the sky is the limit. If you want, you could use entire sentences, including  blank spaces and other special characters - in other words, you could use a passphrase. There are no composition rules for those. Still, a password or passphrase should not be easy to guess. A passphrase that is particularly hard to guess is of course as long as possible, but not too long to remember easily. The length is still one of the defining factors of a safe password. Still, a password should never be shorter than 8 characters.

For those who already rejoice and think "Finally, no more gibberish passwords", there is still one little fly in the ointment: Passwords such as your birthday, „123456“, „abcdef“, "aaaaaaa" or „qwertzuiop“ are still a bad choice for a password and can be blacklisted by a service provider or administrator. The rule not to reuse the same password for multiple purposes (e.g. for E-Mail, social media and online shops) is still in effect. Every service should still have its own password or passphrase. If available, it would be a good idea to enable a second authentication method. To keep track of all passwords, a password manager remains a highly useful tool.

Four tips for securing your accounts

If a platform has implemented the new recommendations, there are a few simple tips that help you increase the security of your account:

  • Use a sufficiently long passphrase
    (e.g. "aStrangeGame - the1WinningMove is NotToPlay!" - note that this is 44 characters long, contains special characters and is easy to remember)
  • Enable multi-step authentication (multi-factor authentication), if available
  • Never reuse a passphrase for multiple accounts
  • Use a password manager