CODEWITHSUNDEEP
phpsecurityhash
webnat0
webnat0

Reputation: 2716

How secure is this hash? (PHP)

function oneWayEncrypt($string) { 
    $salt = md5($string."yHuJ@8&6%4#%([@d-]"); 
    $salt2 = md5($string."@!#&+-)jU@[yT$@%"); 

    $string = hash('sha512',"$salt$string$salt2"); 

    return $string; 
}

Upvotes: 3

Views: 264

Answers (3)

Zed
Zed

Reputation: 3385

How secure for what?

For storing hashed passwords? - Use random salts, different for every password.

For signing cookies? - Use HMAC, a Hash-based Message Authentication Code.

You're saying that you want to use it for storing passwords in DB and cookies, both of which should be done using other proved techniques, see above. Don't try to reinvent the wheel.

When you ask how secure something is, you have to know not only what way are you going to use it but also what kind of attack do you want it to be secure against. Things are not secure in a vacuum.

Also, don't assume that SHA-512 is better for your application just because it has more bits. Read the paper Preimage Attacks on 41-Step SHA-256 and 46-Step SHA-512 by Yu Sasaki, Lei Wang, and Kazumaro Aoki (PDF) to see that for certain applications some shorter hashes can be actually more secure than SHA-256 and SHA-512 because there are no known preimage attacks that would brake so many rounds as for SHA-256 and SHA-512.

Upvotes: 4

Gumbo
Gumbo

Reputation: 655239

Although SHA-512 is a good choice for a cryptographic hash function in general, it still might be too easy to compute: SHA-512 is computationally fast enough to process 154 MB/s. You should better choose a cryptographic hash function that is computationally slower like bcrypt that can be slowed down with a cost factor.

Additionally, use a random and unique salt for each hash operation and store it together with the hash to be able to reproduce the hash for comparison.

Upvotes: 2

templatetypedef
templatetypedef

Reputation: 372794

Using SHA-512 is a good idea to get a cryptographically strong hash, but your choice of a salt does not add much extra security. In particular, a salt is only good if its value is random and cannot be predicted in advance. This prevents an attacker from precomputing a table of known hashes with which to try to attack your database. If the salt is known, then the attacker can just precompute a table of hash values with the salt hardcoded in.

In your case, the salt is essentially known to the attacker because it's deterministically computed from the input string. If I wanted to attack your system, I could iterate across a bunch of known strings, (deterministically) compute the salt for each string, then compute the SHA-512 hash of the salted string and store it in a table. From this, I could invert a hash to a password for any string I happened to precompute.

If you want a better security system, instead consider using a salt that's randomly-generated and then stored alongside the resulting hash. That way, no matter what tables I precompute, there's a slim chance that the table will be useful because I won't necessarily have computed the tables for all possible salts. Essentially, each random bit in your salt doubles the amount of work I have to do, so if you pick a good random salt (say, 128 bits) then there's no feasible way I could do a precomputation attack. I'd have to attack SHA-512, a hash assumed to be cryptographically secure (the name means "Secure Hash Algorithm"), to break your system.

Upvotes: 15

Related Questions