05-01-2016, 03:47 PM
"Reversing" hashes is only possible for cryptographically broken hashing algorithms. Hashes being somehow reversible is not the problem you need to care about. But cryptographic hashes are optimized for easy hardware acceleration and high speed - exactly what you don't want for password hashes.
Passwords are cracked by running the used hashing scheme on known plaintexts and compare the output with the attacked hash. The faster you can calculate the password hash the easier it is to crack a password.
You should not worry much about the underlying cryptographic hashing algorithm but only about the used password hashing algorithm. bcrypt, scrypt, yescrypt and argon2 being strong ones as already pointed out by epixoip. All those PHA internally use cryptographic hashing algorithms but make sure to severely slow down attacks and prevent hardware acceleration. They all use salts, too.
Using no salt allows an attacker to crack an (almost) arbitrary number of hashes at the same time without significant performance hit. A salt (of proper size) will slow down an attack by the amount of hashes being attacked. 1 million hashes? -> 1 million times slower. What it does not help much against is attacking one single target hash (except preventing usage of default pre-calculated lookup tables like rainbow tables). But in this case still the other features of a PHA come to play: slowing down the calculation of a hash by all possible means while preventing acceleration through specialized hardware or optimized routines on generic hardware.
Your proposed scheme does prevent nothing of those things.
Passwords are cracked by running the used hashing scheme on known plaintexts and compare the output with the attacked hash. The faster you can calculate the password hash the easier it is to crack a password.
You should not worry much about the underlying cryptographic hashing algorithm but only about the used password hashing algorithm. bcrypt, scrypt, yescrypt and argon2 being strong ones as already pointed out by epixoip. All those PHA internally use cryptographic hashing algorithms but make sure to severely slow down attacks and prevent hardware acceleration. They all use salts, too.
Using no salt allows an attacker to crack an (almost) arbitrary number of hashes at the same time without significant performance hit. A salt (of proper size) will slow down an attack by the amount of hashes being attacked. 1 million hashes? -> 1 million times slower. What it does not help much against is attacking one single target hash (except preventing usage of default pre-calculated lookup tables like rainbow tables). But in this case still the other features of a PHA come to play: slowing down the calculation of a hash by all possible means while preventing acceleration through specialized hardware or optimized routines on generic hardware.
Your proposed scheme does prevent nothing of those things.