Passwords: A Game of Pwns – A Hash of Kings
Apparently, someone put World Password Day (May 2) just before Star Wars Day (May 4) and while the most hotly anticipated final season on TV is airing (“Game of Thrones”). This seems inconvenient and ill-timed, which suits passwords rather fittingly.
Whether we like it or not, we remain stuck with passwords for the foreseeable future and need to contend with their shortfalls. Now, in the final season, it’s time to call out site operators and application developers who design and implement password systems and very often perpetuate the situations that allow for large password breaches that can yield a lot of harm to the affected users.
‘What is dead may never die. But kill the b@stards anyway’
Despite the years of information about bad passwords and security incidents, many sites still not only allow users to select bad passwords but preclude users from selecting good ones. Usually this happens because sites restrict the maximum length or the character composition to relatively weak sets of options—often, we suspect, because of legacy system restrictions or very old code that imposes limitations restricting the use of special characters or lengthy passwords. Some sites actually prevent pasting values into the password field, which makes using a password manager to handle that site’s password very difficult. It’s true that more recent NIST guidance suggests that frequently rotating passwords may yield worse security than passwords that change less often but are lengthier and more complex, but this hinges on the idea that human memory is the repository of knowledge. In the case of a password manager, a lengthy, randomly generated password that changes regularly is a matter of convenience rather than recollection. Many sites also continue to not support multi-factor authentication, despite the numerous options available, and the fact that guidance supporting multi-factor authentication, especially for retail banking, was published by the FFIEC in 2001.
‘High in the halls of the kings who are gone, Jenny would dance with her ghosts’
Perhaps the most important part of protecting user credentials for websites or other applications is how those passwords are stored and transmitted. Doing this well requires the right use of cryptography, which is different for both storage and transmission, and both have some tricky elements. Most systems make use of conventional cryptographic hash functions for password storage and haven’t necessarily kept pace with modern password-cracking techniques.
While most operating systems and many applications make use of fairly modern hash functions, there remain a number of user repositories that hash passwords using outdated hash functions, namely MD5 or SHA-1 hashes. These are longstanding hash functions that are relatively computationally fast but have some particular flaws. Specifically, these hashes don’t defend well enough against collisions, which are cases where two plain-text values produce the same hash output. This usually causes more problems in non-password contexts: Hash functions are used to produce verification checks and are used in code signing and similar applications. A collision in this case allows an attacker to produce what seems like a signed application but is actually hostile. The Stuxnet malware used against Iranian nuclear facilities in the late part of the last decade made use of this technique. That said, these situations in which the computing effort necessary to engineer a collision is modest enough for anyone with access to publicly available cloud computing and the money to power that computing infrastructure also mean that the computing effort to crack passwords is also relatively modest. Further, NIST has said that the SHA-1 hash function should no longer be used in another important context: certificate verification. Again, while this isn’t the same as password storage, it reflects a fundamental weakness in this function and should serve as all of the warning necessary for organizations to stop using it to protect passwords.
‘What do we say to the god of death? Not today’
While there are commonly used hash functions superior to MD5 and SHA-1, such as SHA-256 or SHA-512, these are, in many ways, successors to SHA-1 in that they are intended to be relatively fast to compute. They are more complex and require more computing time but follow a similar trend in their structure, and advances in computing power will very likely eventually render these hash functions ineffective in the future along the same trajectory as SHA-1. The optimal situation to prevent password-cracking as it stands is to implement a slow hash function. In this case, slow is a relative term. These functions require more computing effort—both in processor cycles and memory use—than their faster counterparts, such that a password cracker attacking a large number of these hashes has a significantly higher resource utilization than a faster hash such as SHA-256. That said, the individual user experience of authenticating when the system uses a slow hash function isn’t materially different for the user. The differential is measured in tiny fractions of a second, which is insignificant on the scale of human experience, but a few microseconds per guess of a password cracker makes a huge difference on the scale of millions of guessed password attempts.
The most common slow hashes are scrypt and bcrypt, and both are entirely functional and available as part of some cryptographic APIs such as libsodium, as well as in some operating systems. Despite this, relatively few systems make use of these capacities.
‘Everything you did brought you to where you are … home’
Unlike much beloved characters, or even much despised enemies, passwords are harder to kill off than anyone wants, and the replacements aren’t necessarily always better. You can’t issue users new biometric identifiers if their fingerprint or iris data becomes compromised and not every system will easily support a physical token. So we have to figure out how to live with passwords for the foreseeable future. That falls on both the users in selecting good passwords and managing them with a password manager and on-site operators and systems admins to permit users to pick good passwords and to protect them with the best available defenses.
