Crthuky

Everywhere I look it says servers store passwords in hashed form, but then you have those breaking news about hackers stealing passwords from large companies. What am I missing?

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

Servers don't store passwords in hashed format, this is something that is implemented by us.

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 anyway 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 more stronger types of hashing algorithms, it makes it much harder for attackers to successfully make use of the passwords they have stolen.

Edit

After re-reading the title you do indeed specify "How are passwords stolen if they only store hashes"

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).

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.

There are two common failings, over an above letting the databases or files get stolen in the first place.

Unfortunately, and against all security recommendations, many systems still store clear text passwords.

Hashed passwords are technically not reversible, but as has been pointed out by others, it's possible to hash millions of password guesses then simply look for matches. In fact, what usually happens is that tables of precomputed passwords and hashes (Rainbow Tables) are available and used to look for matches. A good rainbow table can support a high percentage match in fractions of a second per password hash.

Using a salt (an extra non-secret extension of the password) in the hash prevents the use of pre-computed rainbow tables.

Most compromisers depend upon rainbow tables. Computing their own hash set is certainly possible, but it's extremely time consuming (as in months or longer), so it's generally the vanilla hash that's vulnerable.

Using a salt stops rainbow tables, and a high round count of hashed hashes of hashes can make brute force transition from months to years or longer. Most institutions simply don't implement this level of security.