It just goes to show that in 2016, you really can't be using SHA1/256/512 for password hashing anymore, even salted. Bcrypt/Scrypt or similar is a must.
From what I can tell with reasonable password length SHA512 still seems relatively secure. I'm not saying there is any reason you should use it - but if it does 8624.7Mh/s and your password is JUST numbers, lowercase and uppercase English letters and it's only 10 characters it would still take it (26+26+10)^10 / 8624.7Mh/s ~= 83929936 seconds which is still about 3 years for a single hash.
If it's 12 characters - then you're up to 10,000 years.
True - reasonable password length being the important factor. I was basing my calculations on 8 character passwords.
At my university we were forced to use passwords that are exactly 8 characters long, for some ridiculous reasons. And this was meant to be one of the top universities in Australia...
> Originally, some developer, somewhere, was working on an old Unix system from the previous century, which used the old DES-based "crypt", actually a password hashing function derived from the DES block cipher. In that hashing function, only the first eight characters of the password are used (and only the low 7 bits of each character, as well). Subsequent characters are ignored. That's the banana.
Just a hash or a single salted hash iteration has been on the bad practice list for a very long time. Hashes are designed to be fast, key derivation functions are intended to be slow.
There are a number of KDFs that build on top of the SHA family, from PBKDF2-HMAC-SHA1 to sha512crypt, that are all fine in principle but are often used with iteration counts that are off by 1 or 2 orders of magnitude.
If it's 12 characters - then you're up to 10,000 years.