How could our passwords be cracked so easily?

Question

We are saving password in a database using PHP:

return hash('sha256', PASSWORD_SALT . $password);

Recently a (fortunately) good hacker SQL-injected us and cracked some passwords including the admin one.

The story did not ended dramatically or terribly like in Hollywood movies, because he was kind enough to point us the holes. (We "thanked" him accordingly.)

Now that the holes have been patched, we are afraid that there might be some holes somewhere else as the code base is large. The questions are:

• How on earth did he crack the password so fast (few hours to less than a day)? PASSWORD_SALT is quite long, stored in the source code and he did not have it. Also, a blank password is not accepted in the PHP code.
• We assume we should change the hash/encryption for existing and future passwords. Which encryption do you recommend so that the exposed password is more secured?

He told us that he use some software and dozen of desktop machines available to him in his company. He said he is a bored security expert in some large firm, so he has the means to do stuff.

Answer 1

First of all, what you call PASSWORD_SALT isn't really a salt. A salt is different for every password, and stored in the database. What you have is something that is shared by all passwords, and stored in the source code. That is commonly called a pepper.

So how did the attacker crack your passwords so fast, without knowing the pepper? He probably created a new user for himself, so he has one user for which he knows the password. He can then try to brute force the pepper on that user, since he knows what password he should concatenate it to. The key here is that he does not have to crack the pepper and a password at the same time. He can first crack the pepper, and then crack passwords. This is much, much simpler.

A single iteration of SHA-256 is not a good password hashing algorithm. It is way to fast. According to these benchmarks for a 8x Nvidia GTX 1080 setup, you can try around 2 billion hashes per second. If we give the attacker 12 hours, that's almost 10¹⁴ hashes. On average, that's enough to crack a pepper with log₂(10¹⁴) - 1 = 45 bits of entropy. That corresponds to, for instance, 10 random lower case letters.

Once you have the pepper, you can start cracking passwords. Since they probably have lower entropy than the pepper it should be much quicker.

For how to do password hashing right, see this question.

Answer 2

How on earth did he crack the password so fast ( few hours to less than a day), PASSWORD_SALT is quite long, stored in the in source code and he did not have it. Also, blank pwd is not accepted in php code

Well, i'am sure that he used one or more computers with build in GPU's. Maybe he is running multiple GPU's in CLI Mode. What that means is, that multiple GPU's like the GTX1080 accomplish the same task for one operation. In this case hashing strings in SHA256 from a password list and compare it with the hashed password strings he found in your database.

To give you an example how many passwords the GTX1070 can hash and compare in a second, i will refer you to this blog I found: https://hashcat.net/forum/thread-5440-post-31067.html

In this example the tester used a EVGA GeForce GTX 1070 SC GAMING ACX 3.0 on a Windows 7 system. The GPU managed to 'crack' 2117.4 MH/s for the SHA256 algorithim.

Then he try to crack at least a few passwords, compare them to each other and where able to determine the salt. With the knowledge how the salt looks like he created a new passwordlist. Starting with the salt followed by his normal passwordlist.

---

We suppose we should change the hash/encryption for existing and future passwords. Which encryption do you recommend so that the exposed pwd is more secured ?

When a hacker where able to gain hashed passwords it's a matter of time depending on the hash algorithm how long it takes to decrypt most of the passwords. I don't want to recommend a algorithm, because it strongly depents on your computational capability and the loading time. But if you want to get a idea which algorithm is stronger than the SHA256 take a look at password cracking benchmarks: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40

Stronger password policys where another way to delay a cracking process or make it impossible for the hacker to guess the correct password.

Answer 3

I am skeptical that your description of the circumstances is accurate and reliable. In particular I find it really hard to believe this bit:

PASSWORD_SALT is quite long, stored in the source code and he did not have it.

I read this as a claim that PASSWORD_SALT was secret and impossible for an attacker to guess in any practical amount of time (in technical terms, that it has high entropy). But if we granted this claim we'd have to conclude that the attacker defeated the preimage resistance of SHA-256—that, given nothing but an effectively random output value for the hash function, they were able to find an input that yields that output. And not just any one such input—one that just happens to be prefixed by your supposedly secret, long and unpredictable PASSWORD_SALT.

But of course your hacker did not in fact discover a catastrophic break in SHA-256. So I think your understanding of the circumstances has to be inaccurate. Either:

1. The hacker actually managed to see your code and learned the value of PASSWORD_SALT;
2. Your value for PASSWORD_SALT actually is easy to guess by applying the same methods as normally applied for password cracking. Anders' answer's suggestion that the attacker may have created an account with a known password is a plausible method for doing this—cracking a low-entropy salt given knowledge of the password is the same problem as cracking a low-entropy password given knowledge of the salt.

We assume we should change the hash/encryption for existing and future passwords. Which encryption do you recommend so that the exposed password is more secured?

If you're using PHP, recent versions have excellent built-in password storage functionality.