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. Last time, I talked about password cracking, the need for long, random, unique passwords, and why users need a password vault of some sort. 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.
About JACOB ANSARI
Jacob Ansari is the Chief Information Security Officer at Schellman & Company, where he develops and manages the company-wide information security program. Jacob oversees the processes for risk and security assessment, vulnerability management, software security, awareness and education, and incident response. Jacob has also performed in a client facing role as the technical lead for Schellman’s PCI services, and represents Schellman to the payments industry. Additionally, Jacob has experience with other Payment Card Industry assessment services, namely Software Security Framework, PA-DSS, P2PE, 3DS, and PIN. Jacob has extensive technical expertise on matters of information security, compliance, application security, and cryptography, and has been performing payment card security assessments since the card brands operated the predecessor standards to PCI DSS. Over the 20 years of his career, Jacob has spoken extensively on PCI-related matters, trained and mentored assessors, and contributed to groups on emerging standards, advisory bodies, and special interest groups.