Last year our team recovered more than 9 billion stolen credentials for online accounts, and data breaches increased by over 50% compared to the previous year. Breach notifications: everyone gets them, in many forms—a blog post, an email, or sometimes in the form of an actual physical letter. These notices typically inform individuals that their personally identifiable information (PII) has been compromised by some unauthorized third-party. Many notices also include an explanation that passwords may have been accessed, but it is okay because they were protected and not stored in plaintext.
Are these passwords really protected? Are my employees or customers or anyone else at risk when criminals get access to these “protected” passwords?
How passwords are protected
Responsible software engineers usually include password storage requirements when designing any application that has an authentication or login process. Software is never perfect and may contain vulnerabilities that attackers can employ to arbitrarily target organizations. Because of this, it has become a best practice to not store user passwords in “plaintext” (their original user-entered form), so that in the event of a breach, the credentials can not immediately be used. This is where password hashing comes in.
Password hashing is the practice of transforming passwords from user-entered plaintext into an irreversible fixed-length string that can be calculated based on what a user inputs for an application login request. The application will calculate the hash from this input to make sure that the password that was entered into the password field matches its hashed counterpart. If the hash doesn’t match what the user enters, then the application will not grant that user a session and will display an incorrect password error.
What are salts when it comes to password hashing?
Salts are part of the password hashing process and force each hash to be unique. If hashing functions do not implement a salt, then two users with the same password will also have the same hash. Because each salted hash will be unique, common hash cracking techniques like reverse lookup or rainbow tables are rendered ineffective.
Users password + hash function = hash
Users password + randomized salt + hash function = unique hash
Are attackers able to use stolen credentials that were hashed?
In theory, stolen hashed passwords are protected passwords. But, there are myriad of factors at play that determine if a criminal can use stolen hashes. Here are the main factors that can determine how easy it is to crack a password hash:
- The users choice of password. Was this randomly generated or is it something guessable in a password dictionary like ‘password123’? Was it a password that the user reused across multiple applications, increasing the likelihood that it’s already been exposed?
- The hashing function that was used. Over time, researchers and criminals find ways to attack hashing functions, so some hashes become susceptible. 53.7% of the breach data we collected last year included credentials that were hashed using outdated MD5 and SHA-1 algorithms. Both have been deemed “broken” for several years, so it’s important not to use these hashing functions and to update away from them where needed.
- Whether the criminal has access to public and potentially private breach data that they can use to guess valid passwords when attacking a password hash. The previously compromised data could have been purchased or acquired by the criminal in some other way.
- The attacker’s access to resources including password lists, time and computational resources. Cracking password hashes requires a lot of processing power. Graphics cards have better performance than cracking with a single processor.
- Whether salt was added. It’s important to note that cracking a large portion of the protected passwords is made easier by the lack of salts. In the data we collected, only a little over half of hashes contained salts, a proportion we hope increases when we compile data for 2020.
How can I protect my employees and customers?
Breaches will continue to happen for the foreseeable future which means that you cannot just rely on organizations to keep passwords out of the hands of the attackers. Stolen data can then be used to target organizations through credential reuse, leading to account takeover for systems that gives attackers further foothold into the organizations that they target.
To protect your employees, customers and business, we recommend that organizations follow NIST guidelines for authentication when making decisions on how to hash and store authentication secrets. Employees should be taught about the risks of reused and generic passwords. And finally, security teams should regularly check existing and newly created passwords against known breach data, to flag any employees who have reused a previously breached password that could be tied to their identity.
Dustin Warren is a Security Researcher at SpyCloud.
Password stock photo by Thomas Andreas/Shutterstock