The Password is Dead, Long Live the Password!

Overview

In 2016, I have read many articles on the topic of authentication where a common proclamation has been that “The Password is Dead!”. No doubt, the vast number of publicised breaches over the past few years where user passwords have been exposed has tainted people’s views on the efficacy of the password. In addition, there has been an explosion in the use of biometrics as a main authentication factor (which is seemingly easier to use than passwords) and on the surface, along with variable user-focused authentication journeys, one can see why the password’s demise has been forecast. However, in this blog post I aim to set out why I think passwords are not dead, or at least why we shouldn’t cast them away and risk losing the valuable property of “something you know” which passwords have gifted us since ancient times.

Context

The concept of passwords is robust. As one of the main factors of authentication (something you know), passwords allow us to authenticate to systems using secrets that are maintained in our minds (or password managers – see later). Save for advances in telepathy, these secrets remain in our minds unless we choose to disclose or document them in some form. Much of the reasoning around password inadequacy has unfortunately (and inaccurately) focused on the processes and procedures around password management. The examples below hopefully help explain this:

• If a user chooses ‘password123’ to access a resource, this is not a weakness with passwords, it’s an issue with an overly-permissive password policy
• If a user has to choose a long, complex password that is difficult to remember, this is not a weakness with passwords, it’s an issue with an overly-stringent password policy
• If a user cannot remember their password, this is not a weakness with passwords, it’s the inability of the user to recall their password
• If a user writes their password down on a sticky note, this is not a weakness with passwords, this is a careless/risky act by the user
• If a user shares their password, this is not a weakness with passwords, this is a careless/risky act by the user
• If a user is frustrated due to the number of seconds it takes to enter a password, this is not a weakness with passwords, but rather speaks to the impatience of the user
• If an attacker performs a brute-force, password-guessing attack against an online service which results in unauthorised access, this is not an issue with passwords, this is an issue with the online service’s account lockout mechanism
• If a system is hacked and passwords are publicly exposed, this is not a weakness with passwords, this is due to weaknesses in how the passwords were stored and/or a potentially weak password policy on the affected system

The last point above seems to be one of the more common issues we see around password management which often results in the many publicised plaintext password exposures following system breaches. Having used passwords to access electronic resources for several decades we have learned how to create password policies that strike a good balance between security and usability. Additionally, we have learned how to implement robust and secure hashing algorithms, with hash iterations and good choices of salts in order to protect passwords against pre-computed dictionary attacks yet we commonly fail to implement such measures, or are perhaps denied the option to do so due to legacy hardware and/or software that does not support these mechanisms without upgrade or reimplementation. I’ll say it again: this is not an issue with the concept of passwords.

But what about password reuse?

It is true that users commonly reuse passwords across disparate systems; the risk here being that if the passwords of system A are compromised, then this might lead to access to other accounts of affected victims on other systems B, C, D, etc. While the compromise liability in this example lies with the data controller of the original compromised system, liability for any subsequent system compromise due to password reuse lies with the affected user(s) due to their own conscious decision to reuse passwords across different systems, and/or their choice of a weak password.

Note that while not a solution to this problem, a good salting implementation that is different across users and systems can significantly help reduce the risk of offline pre-computed hash cracking of compromised databases, thus affording end-users some level of assurance (or additional time to change their passwords across systems in the event of a known breach) should they have reused the same password on other systems.

Some people like using passwords

There are various studies on the number of passwords that people need to remember as a result of a typical online presence in the 21st century; the results vary per study but average at around 25 passwords. While some might find memorising 25 unique passwords difficult, others won’t have any issue with this and might even feel a level of comfort in successfully authenticating to a system only once their correct password has been entered and verified. Related to this, the use of password managers has become a good way for people to manage and recall passwords for access to different resources. Password managers can distil password recollection down to only one password (for unlocking a password vault), removing the requirement to memorise multiple passwords.
While password managers can present much risk to users should they expose any vulnerabilities; again, this is not an issue with passwords, but rather weaknesses in the secure design and/or implementation of vulnerable password managers.

Authentication as consumer choice?

Consumer choice has become a key selling point for many businesses – the more choice offered to customers, the more likely the consumer base will widen while customers will also appreciate the ability to tailor or home-in on a specific product of choice that is to their tastes. Taking Starbucks as an example, the number of possible drink combinations available at outlets exceeds 80,000. Why should authentication mechanisms not be a choice for consumers? As we see app developers moving to the use of biometrics within apps to authenticate and perform transactions, while this is seemingly rendering the end-to-end transaction process more efficient, it is taking away the user’s choice on how they might actually want to authenticate and authorise actions. Why not allow consumers the choice of which authentication factors they would like to use and in which combination?
Perhaps users would like the option of enabling passwords in addition to biometrics for authorising certain transactions, perhaps also even leveraging time-based One-Time-Passwords (OTP). Such choice would facilitate privacy by design from a consumer perspective and surely appeal to those users who want to maximise the level of security available for protecting their electronic resources.

Why Biometrics is not the panacea to authentication

I’ve written a lot on biometrics and have persistently made the point that biometrics are not secret. Fingerprints are left lying around on surfaces, pictures of faces and irises can be taken while recordings can be made of voices. The techniques involved in spoofing most (if not all) biometric modes are well-documented online. However, the facsimile of biometrics is not a weakness, but rather a property.

An additional complication with biometric template storage is the fact that biometrics cannot be cryptographically hashed. Each time a user presents their biometric to a sensor this will be done in a different way – different angle, environmental factors affecting the sensor, change in biometric due to ageing or injury etc. As such, should biometric templates be stored in a database and that database at some point is compromised, then attackers may be able to utilise the stored template data (and image(s) if also stored) to recreate spoof artefacts that can be used to masquerade as the database victims. Similar to the issue of password reuse, suppose a user’s biometrics are used in multiple systems – conceivably the compromise of one biometric data store could result in production of spoof artefacts that can be used against all other systems where the user has registered their biometric – a compromised password doesn’t compromise ones’ identity, whereas a compromised biometric might.

Work is being done on the concept of cancellable biometrics whereby biometric data is encoded with a level of distortion such that its compromise should not result in reuse on other systems and that the biometric can be revoked and re-enrolled with a new distortion . Such implementations, however, are not that common and further research and development around cancellable biometrics is needed.

Note also that the General Data Protection Regulation (GDPR), Article 9, requires a high-level of (explicit) consent for the processing of special categories of personal data – one of these categories is biometric data. Large scale processing of biometric data will trigger a requirement for data controllers to undertake a data protection impact assessment to identify potential risks involved in processing this data and measures taken to ensure compliance. Implementing biometrics within systems is not therefore a drag-and-drop action; there is much more to consider around compliance and regulation than with passwords.

The cost of bypassing 4 numerical digits vs. 1 finger digit?

Consider the controversial events of February 2016 around the FBI’s request for Apple to create new software that would allow for unlocking of one of the iPhones recovered from one of the shooters in the December 2015 alleged terrorist attack in San Bernardino, California. The recovered handset was locked with a four-digit password and set to erase all data following ten failed password attempts. Taking The FBI and Apple’s opinions aside, this is a good example of password effectiveness, coupled with an account lockout mechanism that was only bypassed via a third party solution reportedly costing the FBI in excess of $1 million (£805,000).

Contrast this to the hypothetical situation where the iPhone in question was protected by fingerprint recognition (one finger digit). Although a sinister concept, the FBI might have been able use the deceased shooter’s finger or create a fake finger from the shooter’s cadaver to unlock the phone, at a cost of no more than $10.

Passwords are secret, whereas biometrics are not.

Conclusion

Many of the issues attributed to passwords are not issues with the concept of the password, but rather issues around the management and use of passwords – solutions, or best practices, exist for these management issues so perhaps we should be investing time and effort in exploring and implementing these, rather than simply discarding passwords as inadequate. We must not forget the powerful property of passwords that allow us to maintain secrets. Newer, more popular authentication mechanisms such as biometrics are great for convenience and efficiency of authentication and authorisation; they are not, however, without their risks and potential for vulnerability in implementation.

There is much potential for multi-factor authentication, whereby in unison we can leverage the properties of:

• Something you know (password)
• Something you have (token, physical device such as a smartphone etc.)
• Something you are (biometrics)
• Somewhere you are (GPS)

While some sectors may look to move beyond passwords as a form of identity, using all available authentication factors in the right combination and in the appropriate application can help make it significantly more difficult for attackers to gain unauthorised access to systems. Taking away the password from this mix endangers the potential for maximum assurance available to end-users.

The password is dead, long live the password.

Written by Matt Lewis
First published on 10/10/16