SHA-512 unix passwords. How secure are those hashes, really?

Question

I came across this very alarming sounding thread which indicates a GPU with about half the compute capacity of the GPU currently powering the monitor I type this on is capable of 11.5k c/s.

I'm not sure what a c is in this jargon. Does it stand for "crack"?

Does this mean 11.5 thousand passwords tested per second? So if my password uses 5000 round SHA-512, and is a weak enough password that comes in at #11,500 in the attacker's dictionary, I'm pwned in as little as 1.0 second?

the quote is 11.5k c/s at rounds=5000 which is the default number of rounds. I guess it's not too terribly alarming if the password is lengthy and "random" enough as it really should require extraordinary luck to hit upon it in the first several million attempts; however with a small GPU farm you can crunch through several million within a short time. It's bound to get cracked eventually.

Surely the c/s cannot stand for rounds/sec as indicated here; my 500,000 round SHA-512 $6$rounds=500000$... password gets verified by the machine within about 1 second; that amounts to 500K rounds/sec roughly.

To do a little scribbling on the back of an envelope calc.exe:

11,500 * 5000 = 57,500,000 rounds/s

This is an over 100 fold increase compared to my estimated CPU verification speed in rounds/s. I might be able to believe that my GPU can pull that off. It sure can do so with pixels.

Or does it mean on average, 11,500 user accounts can be cracked per second? Now that would be truly impressive.

I'm gonna go update my password now. The root password that I intend on distributing to my VM's through a kickstart script which necessarily happens over HTTP.

Answer 1

The figures you quote are about the number of tried passwords per second. Since this password hashing function is salted, attackers cannot attack more than one hashed password at a time; similarly, they won't be able to build and reuse precomputed tables ("rainbow tables"). Moreover, the function is configurable with a number of iterations ("rounds") so that you can adjust it to a trade-off between the amount of CPU you are willing to spend on each password verification, and the amount of CPU you want the attacker to spend on each cracking attempt. If you double the number of rounds, you make the job twice harder for everybody, you included.

The default number of rounds (5000) was meant to be bearable on average computers of that time; recent PC are faster and increasing that number of rounds for your machine would be a good idea.

Nevertheless, attackers can use special purpose hardware, in particular GPU, to get a boost. The boost depends on how the function is internally computed. SHA-512 consists in a lot of 64-bit arithmetic operations, and GPU are not utterly comfortable with that, so the boost obtained with a GPU (compared with generic CPU, under the same budget) is not as high as it would be with SHA-256 (which uses only 32-bit operations). However, it is expected that a GPU will be a few dozen times faster than a CPU at trying to crack passwords. Exact figures depend a lot on the CPU and the GPU used, but yeah, a 100x speedup is conceivable (I suspect you underestimate your CPU, though: it is multicore, and, furthermore, it has some inherent parallel computation abilities with SSE2 or AVX registers).

Other functions rely on more memory-access operations which make the task harder for a GPU, e.g. bcrypt and scrypt. See this answer for a lot of information on password hashing, and that one for a specific treatment of bcrypt vs PBKDF2 (for the purpose of the discussion here, PBKDF2 is quite comparable to the Unix crypt() function we are talking about).

---

Anyway, the correct defence is not to have a weak password. If your password is #11500 in the attacker's list, then it is very weak. A reasonable password has at least 30 bits of entropy, so on average the attacker will have to try 500 millions of them before cracking it. At 11500 per second, you have a few hours before you. With a little more memory effort, you can get more than 40 bits of entropy, and transform this "a few hours" into "several years".

See this question for discussions on password entropy. Also, remember that password hashing is a second line of defence which enters into action only when a partial breach has already occurred: in a Unix context, /etc/shadow is not supposed to be readable by non-root users, let alone external clients. So don't get too much worried about password hashing, and concentrate on not allowing SQL injection or buffer overflows.

Answer 2

The numbers are correct.

The main point here is that both MD5 and SHA are meant to be fast. They are intended for content checksumming which needs to be as fast as possible. And modern computers even have their own instructions to calculate these on the hardware.

The biggest difference between MD5 and SHA512 is the keyspace and that the likelihood of a collision of hashes in SHA512 is smaller by quite a big margin compared to MD5. See MD5 Collision vulnerabilities.

They keyspace does not play a particularly big role in how secure your password is.

For cryptographic security you should be employing a slow function like scrypt.

And to answer your other question:

Or does it mean on average, 11,500 user accounts can be cracked per second? Now that would be truly impressive.

Well the 'cracking' depends on the passwords and whether or not salts are used.

What the number means is 'how many hashes can this thing computer per second'.

So if you have no salt and the cracker finds that the 5000 round hash for the plaintext 'foobar' is 'abc123def' it can then check if this hash is found in the /etc/shadow file. The problem with not having a salt is that two different users might have the same password and they both would get discovered at the same time since their hashes would be the same.

When you use salted passwords the attacker cannot use pre-calculated rainbow tables but needs to attack each user separately with their own salts.

Answer 3

I believe c/s in this case stands for calculations/second. When a salt is employed you need to recalculate everything for every single hash. If no salt is used, you can calculate everything within one run.

Here's a table from recent benchmarks on different GPUs. As you can see those numbers are similarly high (I know SHA-512 isn't in there but it should give you an indication). Those are the amount of hashes calculated per hash. If you add rounds then you need every round counts as a single hash calculation. More and more people are moving towards Bcrypt and Scrypt which were designed to be rather very unfriendly to run on a GPU as they require substantial amounts of memory. Scrypt is even better than Bcrypt, but I'd like to refer you to this answer here Do any security experts recommend bcrypt for password storage?

Now the fastest GPU in that list can calculate about 2 656 000 000 hashes per second (not crack, calculate!). A normal ASCII password can have 95 characters (ASCII only has 95 printable characters). To calculate the amount of possible characters and assuming normally a password would be around 8 characters we come at 95^8 = 6.6 quadrillion (6 634 204 312 890 625) possibilities. To crack all of these, if they are using 5000 rounds we come at: 2 656 000 000/5000 = 531 200 c/s. which is significantly less than your example, but let's assume they are running a GPU farm and they can actually calculate at 11 500 000 c/s at 5000 rounds. We come at 6.6 quadrillion/11 500 000 = 573 913 043 seconds to calculate all those hashes.

There are 3600 seconds in an hour, 24 hours in a day so: 573 913 043 seconds / (24 * 3600) = 6642 days. That's still 18 years(!) a long time to crack those passwords and we are just accounting for ASCII which doesn't have so many special characters. Throw in a salt and things go way slower. Make the password one character long and it gets 100 times slower. Make it 12 characters longer (which I always advice to use as a minimum for administrative accounts like root) and well that's 540 sextillion for you. So even

Answer 4

I'm gonna take a stab at answering the question by pointing out that the hash and salt should be in a file which is very well-guarded by the operating system.

A reasonable security policy should limit incoming authentication requests to a rate that could not possibly allow more than, say, 100 password entry attempts per day.

If the attacker owns your /etc/shadow contents, one pretty much has to have bigger things to be worried about. This would ordinarily be an extremely contrived situation to be in.

This is likely why not too many folks are overly concerned with configuring maximally bulletproof password hashing schemes: Don't reveal the hash and salt. If there is any risk of doing so, abort. Should work just fine even for that old MD5 stuff; it's just that with that, the hash, if compromised, is a lot more revealing.

I might be wrong about that point, this is pretty important (as in crypto all the bits have to function well or it's all useless), I just consider the security of something like SSL to be a bit higher on the priority list.

That said, my real life example is that I am distributing my machine's initial root password over HTTP due to limitations with the installer boot media. Why don't I do it in a way that is safer? Because I'm crazy like that.

The solution? Come up with a damn long password, and change it after the machine comes online. This reduces the chances of a successful attack to effectively nil.

I actually can't see a straightforward way to skirt around the issue by using an encryption based on scrypt for instance, which is very slow to attack: One must set up a root password in order to gain access in order to be able to type in that scrypt encryption passphrase. So, it may not be possible till the OS comes packaged with an encryption module that supports it.

I do see the possibility of getting the new machine to compile scrypt on its own and automatically setting up a separate authentication layer based on that. There will surely be many pieces to get wrong with such an endeavor.

(I do intend, however, to package an SSH private key encrypted with scrypt so that it can be safe for a somewhat longer period than the password hash)