Skip to content
All posts

Passwords Are Dead, Long Live The Password

Passwords as used today have been derided for years as being terrible, both from users and security professionals. Users complain about how hard passwords are to remember, while security professionals complain about how poorly users pick passwords.

Clearly, a better solution is needed, but to date, there hasn’t been an agreement on what that replacement should be. Users would like a more convenient solution like biometrics, but those solutions often end up being even less secure than passwords, because they often favor lower rejection rates to keep user frustration to a minimum and provide the semblance of being easier than a password. Security experts would like to push users towards more secure solutions, like the wider use of multi-factor authentication, or towards one-time pads, which lack the convenience of simple passwords. So why then haven’t we seen anything truly replace passwords yet?

What Was That Again? Or the Headaches of Passwords

Passwords as they exist today are often rather weak, with 17-24% of all passwords existing in a password dictionary, with the top 10 of those passwords matching 1 in 25 accounts, and 2 in 3 being guessable when common letter substitution (like $ for s, 3 for e, etc.) is allowed on top of a password dictionary. Password cracking experts have even been known to have success rates of up to 90% or more when mixing and matching various intuitive guesses and techniques together.

The outlook on passwords is also rather poor, since every year computing power becomes cheaper and faster and password dictionaries improve and specialize. All of which cuts down the overall complexity and time necessary to crack passwords. This has led to a mini arms race where longer, more complex passwords are continually required to keep data secure. Which, when passwords become complex enough that they become harder to keep in a user’s working memory, leads to users relying more on predictable personal identifiable information (which can be datamined) and reusing passwords more often, making password use even more susceptible to cracking.

Password changing policies also generally fail to keep up with current practices. While at one time, a password that was at least 8 characters, used upper- and lower-case letters, numbers, and symbols was considered secure, professional password crackers started to notice habits in how users would pick those passwords which then made them easier to guess, defeating these methods. For instance, if there was a number in a password, it would likely be a prefix or a suffix, and if passwords were required to be rotated, people would widely increment or decrement those numerical values on a request for a password change. Likewise, the body of the password often is a simple dictionary word, or a few dictionary words which tend to be non-creatively chosen among users. Words like password, iloveyou, qwerty, football, or even letmein are then often reused among dissimilar users.

To address this weakness of passwords, administrators and other professionals have also recommended using some common letter substitutions ($ for s, 3 for e, etc.), having a passphrase instead of a password (correcthorsebatterystaple), or even to try to avoid dictionary words altogether (which, given the creative randomness of people as a whole results in passwords like qwerty, qazwsx, asdf or uiop, which are all derived from patterns of keys on common keyboards). All of which have been ineffective in keeping ahead of password cracking techniques. That’s not to say that all techniques are bad practice today (for instance, the Schneier pass phrase scheme (e.g. nggewe^;ngnnalyv for the famous rickroll) still works well), just that most of the enforced password policy requirements used out there have not kept up with modern best practices.

One way users can help mitigate against poor passwords complexity and reuse is to use hashes created by a password manager in place of the insecure password they would have chosen otherwise. While it’s not a real replacement for a truly hard to beat password (due to the use of a master password to access the password keyring in the manager) it still provides a reasonable enough layer of security on top of an average user’s password and helps guard against password reuse, so long as an attacker is unaware of the password manager being used. It then allows password managers to use increasingly complex new passwords transparently, without users needing to become security experts to know if they’re still using secure passwords.

Where’d I Leave My Keys? Or the Promise and Impracticality of One-Time Passwords

Out of all of the methods of authentication, one-time pads are the gold standard. One-time pads also end up being the hardest to implement securely, since what is desired is replicability and not real randomness, which makes the security of such system contingent on low usage, lest the pattern that exists be discoverable over time.

To get as close to a one-time pad as possible, while not completely sacrificing replicability, there are two main methods used: algorithmic and time-based keys. Time based keys tend to have small, but not too unreasonably small, windows in which the validation key will work in, like 30 seconds. Algorithmic solutions tend to fall in two different classes: chained/counter-based passwords and challenge passwords.

What keeps these types of passwords secure is not knowing how they are generated. If it was publicly known how the passwords were seeded, then they’d be brute forceable. This is why knowing what password manager a user is using can lead to opening them up to an attack on their less secure master password, and why time-based keys should periodically be reseeded, to prevent the pattern over time from becoming too obvious, and to keep the internal clocks in sync.

Likewise, chained or counter based solutions are only as secure as the algorithm that generates the one time key or pin, with the best algorithms having a long number of uses before replicability and derive their key with a large enough amount of entropy. The downside to this type of solution is falling out of sync with the validating server. To deal with this, the validating server might send a device a token seed to hash with its internal key to get it back in sync, which can turn a chained system into a challenge system.

However, when attacking such systems, it is best to attack the weakest link in the chain itself: the user. Because algorithmic solutions aren’t friendly to hand computation, they require the use of a token passkey that the user carries along with them. If you can obtain the token, then you defeat one layer of their security, potentially opening the door to brute force attacking.

Why Isn’t This Working? Or the Problems and Allures of Biometrics

Biometrics have become an attractive alternative to users because of their promises of ease of use to secure their data without the need to remember or bring along anything that they wouldn’t have on them in order to log into their devices. Outside of shows like CSI where they can pinpoint suspects with 100% accuracy, the reality is rather different. Fingerprinting using current detection methods often have error rates like 1 in 1000, meaning that when a reader processes 1,000 different fingerprints one time in a thousand will falsely match. Even worse, computer generated prints can have up to a one in 5 chance of matching on one print in worst case scenarios, and with 5 attempts, there is up to a 2 in 3 or better success rate. But even excluding master prints, there are other ways of fooling fingerprint sensors like using gummy bears, superglue copies of prints, or even pieces of tin foil on optical sensors. With fingerprints being this easy to break, can we really expect fingerprints to be a replacement for passwords?

Even facial scanning isn’t better. When all it takes is a look to unlock your phone, all it takes is an attacker pointing your phone at you, using the face of someone genetically close to you like a child or a twin, or even in some cases, just using a photograph of you. Different sampling angles or changes in facial characteristics, like growing facial hair, getting a tattoo, or wearing a mask might also interfere with accurate detection. And compared to fingerprinting, facial recognition is a rather new biometric without a long history of study to back up its effectiveness, since it has only recently become feasible to test it because of the large amount of data that it has to collect to ensure a match. Even then, recognition has been poor for women and those of non-European descent. So, while it may be marketed as the next best method of authentication, the truth is that it is still a field in its infancy.

The convenience of biometrics is also what makes it a weaker form of authentication. Like with password managers, when used in combination with passwords, they can add a minimal extra layer of security on top of an existing password solution, but unlike with password managers, are nonrevocable, so if an issue is found with the underlying tools or biometric being tested, we can’t just request a new biometric signature to replace our less than secure one, leading to biometrics as a whole being an even less than desirable method for securing our data. Testing some biometric like typing patterns to decide whether to trigger a second method of authentication is still better than relying on a password alone, as can be seen through sites which use various captcha checks, but by themselves, they just aren’t secure enough to rely on them on their own.

How’d I Get Here? or the Spoofability of Geolocation and How I Learned to Love the Tailgate

There’s a lot to be said about good old-fashioned physical security. Sometimes, one of the best ways to prevent access to data that you don’t want to be public is to keep it on an intranet not exposed to the wider web, or in some cases, whitelist which IP addresses can access the network infrastructure. Maybe your GPS location is checked on a fob key or through a phone app as part of authentication. All of which can be circumvented by backdoors or VPNs, IP address or GPS spoofing, or even defeating physical security through social engineering techniques.

Oftentimes, if a business can manage to keep their resources physically locked down to only allow local access, with a good physical security process in place to access it, they can keep reasonably secure. Even in locked down situations though, there’s always the human factor at play which can compromise even the best of security setups. For instance, let’s say we’re a bank who communicates financial data on an independent, point to point intranetwork, which is only accessible in a secured room accessible through an employee identification card. One could potentially break into such a network using a variety of methods, like random USB drive loaded with a trojan dropped around where employees gather, in the hopes that one of the employees will pick it up and plug it into a computer on their intranet and collect any interesting data that they might have. Likewise, an attacker could even tailgate or forge an ID and pose as a support contractor coming in to fix a computer issue they’re having. And while there are a variety of other social engineering scenarios that might come up, all of them revolve around trying to defeat the physical barrier put in place in some form or another.

A fully self-contained intranet is also rather rare. It’s far more likely for businesses to have their intranets mixed in with the actual Internet, so that even if some of the computers can’t be reached to the outside world, there is some gateway that can reach the outside world which can access their internal network. Defeating this sort of setup then revolves around some sort of compromise to the gateway, which can involve directly compromising the gateway, or indirectly by learning the access scheme that the gateway uses (like IP, MAC, or geolocation addresses) and spoofing or stealing the access credentials to the internal network. Basically, if there’s a way to view data, there’s a way to spoof it as well.

Developing a Multi-Factor Authentication Solution

So, if passwords are bad, biometrics nonrevocable and relatively easy to fool, tokens easy to lose or steal, and location-based access breakable, what should someone do to better secure themselves in this digital age? Enter multi-factor authentication. While one form of authentication on its own may be terrible, when using multiple forms together, you can effectively make it harder to fool authentication by creating a broader identification profile which is harder to match as a whole than its individual parts are.

The most effective forms of multi-factor authentication rely on using two or more strong implementations of the following:

  1. Where you are (e.g. physical access, an IP address, or geolocation)

  2. What you have (e.g. RSA key fobs, or password managers)

  3. What you know (e.g. passwords, PINs, or security questions)

  4. What you are (e.g. captchas or biometrics)

The more different types of authentication you use, the harder an attack is to pull off, since a successful attack then revolves around needing to compromise multiple layers in a secured environment, with each layer slowing down adding another potential roadblock to access. Even then, no system which allows for access can be expected to be fully secured, but whether it’s practical to do so or not is another story. And that can make all the difference in the world on whether your practices are safe or not.

Conclusion, or Meet the New Password, Same As the Old Password

While we gather around today seeking to give a eulogy for the password and herald in its successor, the truth is that they will continue to be with us for the foreseeable future. Because so far nothing better has come along which is as easily implementable as a password while keeping the same sort of balance of security and ease of access. Practices may change, new authentication systems may come and go, but so far nothing yet has had the momentum necessary to truly kill off the password. And it likely won’t ever happen either, due to security, functionality, and accessibility being opposing forces. Any new method of authentication seeking to replace passwords is going to have to be more functional, opening more side channels to attacks. That’s not to say that password authentication won’t change in response to the ever-growing need for better security, but that such extra checks don’t have to be visible to the end user.

This is the key to successfully supplanting the password. The trend is clear that we are headed towards a multi-factored authenticating world, where we are matching broader authentication profiles against users. While some may grumble and moan about how hard passwords are to manage, the truth is that we can implement measures now to supplement passwords using processes that check a broader authentication profile without the user always knowing about it. This makes it so that the password as we know it is dying but is not quite dead yet.

~~~~~~~~

Author: Ira Rice
Senior Security Consultant, Prescient Security

~~~~~~~

Further Reading

https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html

https://online.maryville.edu/blog/to-password-manager-or-not-to-password-manager/

https://arxiv.org/pdf/1705.07386.pdf

https://www.nytimes.com/2017/04/10/technology/fingerprint-security-smartphones-apple-google-samsung.html

https://www.theregister.co.uk/2002/05/16/gummi_bears_defeat_fingerprint_sensors/

https://www.tomsguide.com/us/in-screen-fingerprint-tinfoil-flaw,news-28574.html

https://www.wired.com/story/10-year-old-face-id-unlocks-mothers-iphone-x/

https://www.marketwatch.com/story/your-facial-recognition-software-may-be-racist-and-sexist-2018-02-13

https://www.cgai.ca/replacing_something_bad_with_something_worse

https://www.blackhat.com/docs/us-15/materials/us-15-Keenan-Hidden-Risks-Of-Biometric-Identifiers-And-How-To-Avoid-Them.pdf

https://scholarworks.uno.edu/cgi/viewcontent.cgi?article=1145&context=td