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

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

July 24Hits:2
Advertisement

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.

Answers

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.

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

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.

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)

Related Articles

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

    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 "

  • "SHA-256" vs "any 256 bits of SHA-512", which is more secure?July 6

    In terms of security strength, Is there any difference in using the SHA-256 algorithm vs using any random 256 bits of the output of the SHA-512 algorithm? Similarly, what is the security difference between using SHA-224 and using any random 224 bits

  • moving from MD5 to SHA-512June 24

    This question is more of a security policy than a technical security question. Many years ago I developed an asp.net site, implemented Forms Authentication, and stored the user passwords as MD5 hashs. From following basic security news it's pretty ob

  • Does sending two different hashes of the same password reduce security?January 19

    I'm updating a login system. The password is sent to the server as SHA512(password + long_string). I want to switch this to something like SHA512(username + password) in the future. By doing that I don't need to add "please login again" dialogs

  • Are there sha 512 rainbow tables available? October 21

    Are there sha 512 rainbow tables available for download or what kind of dimensions and processing power would be required to generate them? --------------Solutions------------- Possibly, but given their size - much more likely to download a generatio

  • Why is EdDSA collision-resilient with SHA-512?January 12

    In the Bernstein et al. paper about EdDSA, the authors claim EdDSA is resilient against collisions (i.e. it can still be secure even if the hash function used isn't collision-resistant), drawing on a result from Neven et al. that says that Schnorr si

  • Why should I choose SHA (such as SHa-512), instead of bcrypt or PBKDF2, for FIPS-compliance?August 31

    Due to regulation, my company needs to be FIPS-compliant. I was looking at the current list of FIPS-approved cryptographical methods and I notice that neither bcrypt or PBKDF2 are in this list. Does that mean I should use salted SHA-512 for password

  • How to create an SHA-512 hashed password for shadow?November 11

    The previous SF questions I've seen have lead to answers that produce MD5 hashed password. Does anyone have a suggestion on to produce an SHA-512 hashed password? I'd prefer a one liner instead of a script but, if a script is the only solution, that'

  • Is using SHA-512 for storing passwords tolerable?February 22

    I know that the best options to use for storing passwords are bcrypt/PBKDF2/scrypt. However, suppose you have to audit a system and it uses SHA-512 with salt. Is that "fine"? Or it is a vulnerability that must be addressed, even thought your sit

  • Does SHA-512 become suitable to store a password if we use salting and iteration with it?August 10

    Today I have read this discussion about SHA-256 and SHA-512 and that we should not use any of them to store a password securely. And I have read here that instead we can use the PBKDF2 hashing function, because we can use salt and specify the number

  • Same 64-bit preimage resistance security for SipHash and SHA-512/64?August 14

    If I have to chose a 64 bit preimage resistant hash function; will there be any difference in security between SipHash and SHA-512/64 (SHA-512 truncated to 64 bits)? How long will it take an attacker to find a 64 bit preimage (e.g., minutes, weeks or

  • What is the meaning of the term "simple string" for the SALT string in Unix crypt using SHA-256 and SHA-512?July 23

    In Unix crypt using SHA-256 and SHA-512 the author, Ulrich Drepper, introduces the SALT string as the following (highlight by me): For the SHA-based methods the SALT string can be a simple string of which up to 16 characters are used. What is the rat

  • How to assure users that website and passwords are secure August 20

    On reliable websites I always see claims such as "All data is encrypted" or "All passwords are encrypted using 128bit encryption" and etc. However I have never come across a claim such as "All passwords are hashed." On my web

  • Would it be possible to generate the original data from a SHA-512 checksum?October 23

    So, I have a file that is XY Exabytes big. I create a SHA-512 hash from it. Are there any theoretical chances that I can retrieve the original data just from the sha512 hash? Also, are there any better hashes then sha512? --------------Solutions-----

  • Hashing SHA-512 1000 timesFebruary 19

    SageMathCloud security (http://goo.gl/dCujW1) is as follows: Only the hash of your password is stored by the server, which uses 1000 iterations of the sha-512 hash function, with a salt length of 32. While that does sound like a nice salt, I am a bit

  • Will repeated rounds of SHA-512 provide random numbers?April 9

    If I hash a keyword with SHA-512 and then feed the output as the key for the next round ....and keep repeating this process, will I gather a stream of random numbers? --------------Solutions------------- For an adversary not knowing the definition of

  • Hashing password for secure storage (generating salt)April 16

    I wanted to check if the following means of generating a hash for storage of a password was secure. I have an username and password combo. In order to generate a secure hash, I am doing the following: gen_password = SHA256(password + "my_site_name&qu

  • Is Rfc2898DeriveBytes using HMAC SHA1 still considered "secure enough" for hashing passwords?July 8

    I've been told by a CISSP that the .NET class Rfc2898DeriveBytes would not pass a security audit today because it still uses SHA1. It's reliance on SHA1 - even with the iterations - leaves it too vulnerable to brute-force cracking. For my own underst

  • Unix Password Management KeyringDecember 21

    I am looking for a password manager for a command-line Unix environment. So far all I can find are keyring applications for Windows, Linux, and Mac. But no command-line Unix interfaces. My main goal is to be able to access a password keyring through

  • TrueCrypt, RIPEMD-160 vs SHA-512 vs WhirlpoolJanuary 28

    I am encrypting a volume with TrueCrypt. I have decided to use AES as the encryption algorithm, seeing as it is the government standard. But which hash algorithm is better (more secure)? RIPEMD-160 or SHA-512 or Whirlpool? I am using Mac. -----------

Copyright (C) 2017 ceus-now.com, All Rights Reserved. webmaster#ceus-now.com 14 q. 0.317 s.