Trjtdtk

When you hear that passwords got stolen, sometimes companies will report it even if it's just hashed passwords that were stolen. This is so you can take action in the case that they are broken. Unfortunately, there are still companies that store their passwords incorrectly; for example, if you search for the rockyou password breach, you'll find that they were storing their passwords in clear text, which means that they were compromised as soon as they were stolen. In other cases, such as the Adobe password breach, there was mishandling of storing the encrypted passwords in their database. Other times, companies use hashing on their passwords but use insecure hashing algorithms or they don't salt their passwords properly. In short, if a company follows recommended password storage methods, the passwords in theory should be safe in their hashed form, but a good company will still inform their customers of the breach. However, there are plenty of examples where companies do not store passwords correctly leading them to be cracked quite quickly.

You hash a large number of passwords, then check if the output matches any of the stored hashes. Brute force cracking is feasible because people do not usually choose highly unpredictable passwords.

When a password database is stolen, the stolen material includes all the information necessary to do offline cracking. (It's simply a guess and check process. Other methods may be available with less secure hashing or password storage methods.)

Hashing passwords with a preimage resistant functions with a sufficiently unpredictable input is enough to make it impossible recover a password. (An inhumanly strong password.)

However, most people don't do this in the real world, a stolen database of hashes is potentially as worrying as a list of unhashed passwords for a large subset of users on a typical website.

If the password cracker finds candidate password whose hash matches the one stored in the database, then he will have recovered the original (weak) password.

Alternatively, if a hash function is not preimage resistant (including when the output of the hash is too short) a guess-and-check procedure may produce false positives. (Alternative passwords not identical to the original.)

The accounts of users from the company with the data breach are still vulnerable because these passwords will unlock a user's account, even if they aren't identical to the original password. (The server has no way to tell if it's the original password. The hash still matches the one in the stolen database in this case.)

Don't intentionally use an insecure hash function, of course... It's still possible to infer the original password or narrow down the number of possibilities. Which would still make users that reuse passwords on other websites extra vulnerable.

Many possibilities:

1. Even though passwords should be hashed before storage, it's not always the case. Sadly, even today, there are still plenty of passwords stored as cleartext. Steal database, get all passwords.




2. Passwords could be stored somewhere else. Passwords could be included in logs, for instance. Steal logs, get all passwords that were used in those logs.




3. Passwords could be hashed but not salted. So you build a list of password -> hash combinations based on all sorts of passwords. You reverse this table so it becomes hash -> password (lookup table). Get database, convert hashes to passwords, get lots of passwords.




4. Passwords are hashed and salted. But lots of users use very weak passwords (123456, password, letmein, qwerty...). Try lists of passwords against those hashes. Get database, make a dictionary attack on hashes, get lots of passwords.




5. Variation on the previous one, instead of a pre-determined list of passwords, try passwords based on other information you have about the user (username, first name, last name, date of birth, e-mail...).




6. Yet another variation, as many users re-use the same password: try passwords for the same e-mail recovered from other breaches.




7. Yet another variation, when there is a strong password policy in place which requires changing passwords on a regular basis: if you have a previous password for the user, just try changing the final numbers: if user had password "joe12" at one point, try joe13, joe14, joe15... If you have the date the initial password was valid and know the password change interval, it can be quite quick.




8. Passwords are hashed and salted, but use weak (fast) hashes. Same as #4-7, but you can do a lot more attempts a lot more quickly, so you can try a larger dictionary, or even try quite systematically all combinations (brute force attack).




9. Communication between clients and servers are susceptible to man-in-the-middle (MITM) attacks. Passwords are captured on the way.




10. You perform social engineering. "Hello, this is the IT department, there's an issue with your account, we need to reset something, can you give me your password"? You'd be amazed how often that works if properly framed.




11. Mass social engineering, aka phishing: send a mass e-mail campaign asking to log into a site which will capture all those passwords.




12. Hack into the site, and modify it so it sends all passwords received to a remote server (or logs them to a file you'll retrieve later).




13. Ditto, but modify client-side code to do it. Could be as easy as a stored XSS hack.




14. A variation on the above: keyloggers.

There's probably quite a few more methods, but that gives you an idea of how easy it can be to recover tons of passwords.

As we are not discussing how the passwords have been stolen, and more so the aftermath, I'll avoid the many number of factors said companies should implement to help prevent these data breaches.

If you make a website and manage the database, it's down to us to store that information efficiently. If we don't, when there is a data breach attackers can view passwords in what may as well be plain text, as often is the case (depending on the way in which these are stored).

In short, you'd never want this to happen! -- Password cracking is a very common and real thing, just because passwords are hashed does not make them in any way secure.

Let's say a company has 1000 customer passwords, all of which are hashed.

Let's say 600 of those customers had a password, 8 characters long, the likelihood of those passwords being cracked within the first 5 minutes (being generous) is very high.

"5 minutes?! But they were hashed!"....

Yeah, but the passwords of those 600 customers were still poor, along with an equally poor hashing algorithm.

Without going into too much detail in the interest of simplifying the explanation; password cracking works by simply matching the hash to a dictionary file of words, running through each word to see if their hash matches the ones that have been obtained from those 600 customers, for example, your password might be:

Password: Security

MD5 Hashed: 2FAE32629D4EF4FC6341F1751B405E45

I then just run some favorable hacking tools against those hashes to "crack" them.

Should you ever want to store passwords yourself, MD5 should be avoided, above was purely for example purposes. Instead, research the stronger types of hashing algorithms, it makes it much harder for attackers to successfully make use of the passwords they have stolen.

The short answer; hashing, or whatever format you store your passwords has no effect on the ability for hackers to steal these. They are stolen because of a variety of different vulnerabilities. There are a multitude of attacks in which help obtain passwords (hashed or not).

Also take the following attack vector into consideration for web applications:

If the attacker can modify the frontend code, then with a small script the plaintext passwords could be "sniffed" for a while.

If the script can be injected from the backend, then it could be set to only show for visitors from certain countries to better protect against malicious frontend code change detection automations in place running in the same country where the application is being run from.

While storing passwords in hashed form is desirable, it can also pose some difficulties. If it is necessary for one entity to issue a request to another entity on behalf of a user, and the second entity requires submission of plaintext passwords for validation, the first entity will need to hold the user's password in a form that would be convertible to plaintext.

To allow for this, companies may store passwords in various kinds of hardware security modules which audit all attempts to retrieve passwords from them. This approach mitigates many of the dangers involved with plaintext password storage. It can't mitigate all of the dangers, but if an entity is supposed to have authority to access an outside entity on behalf of a user, and the outside entity won't accept anything other than the user's password as evidence of that authority, some of the dangers associated with plain-text passwords will be inescapable no matter what the first entity tries to do.