SHA1 is completely insecure and should be replaced.

This question is 8+ years old and times have changed: https://arstechnica.com/information-technology/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/

For passwords: https://en.wikipedia.org/wiki/PBKDF2

For data: SHA3

SHA512 is more complex than SHA1, but how much security am I losing by hashing a salted password with SHA1 compared to hashing it with 512? in terms of the time it would take for someone who has the db to crack a single password. I'm using a framework that doesn't give me easy access to SHA512, I'd have to override stuff to make it work, so I'm thinki开发者_Go百科ng to just use SHA1, though in the past I've always used SHA512.

The currently known weaknesses on SHA-1 do not impact the security of what you are trying to do. Impossibility to recover the password from its hashed version relies on "preimage resistance" which is, as far as we know, still fully infeasible with SHA-1. It is also fully infeasible with SHA-512, SHA-256, or even MD4 or MD5. A Sci-Fi oriented mind may envision computers achieving the power to find preimages for MD4 or MD5 around year 2050; it will take much longer for SHA-1.

Now it so happens that while there is no known shortcut to computing preimages on SHA-1, there is little security proof either. In mathematical words, if the compression function used in SHA-1 is indistinguishable from a "random oracle" then it is secure against preimages. But the known weaknesses on SHA-1, which (theoretically) leads to collisions, also show that its compression function is not a random oracle. Therefore, the security of SHA-1 against preimages is no longer of the "there's good mathematical reason why it does not break" persuasion. It is more of the "meh, haven't found how to break it yet" kind.

In more mundane words, if you use SHA-1 then you will probably have to justify yourselves. Even if you do nothing wrong, your choice of SHA-1 will be questioned. Whereas nobody would question using SHA-256 or SHA-512, even if it implies some development overhead. Briefly stated, using SHA-1 is bad public relations.

Note that salting is fully orthogonal to that question. Salting is meant to prevent cost sharing between attacks on distinct password instances. Precomputed tables (including so-called "rainbow tables") are a kind of sharing (the table building is expensive but can be used to attack 2, 10, 10000 passwords at minor extra cost per attacked password). Salting defeats sharing. Salting is good. Defeating sharing is important because attacking one password is possible: not because of the hash function, but because a password is something which fits in a human brain, and therefore is amenable to brute force (a "dictionary attack"). With anything related to passwords, you will not get problems due to weaknesses in hash functions, but because you use passwords in the first place.

There has been proof of security vulnerabilities in the algorithm of SHA1, that could possibly lead to an attack. I would recommend using a variant of SHA2 (SHA 256 or SHA 512).

As far as how long it would take someone to crack a password stored in the varying hashes, it's difficult to say without knowing the processing power of the attacker, how long the passwords are, if they employ rainbow tables, how random the salts are, etc. However, if there is something wrong with the algorithm, it could possibly lead to a much easier way to find the hashed value or a different value that equates to the same hash (called a collision), as is the case of MD5.

(Source and more information: http://en.wikipedia.org/wiki/SHA-1)

If you have to overwrite stuff to get anything other than SHA1 to work, you will have to balance complexity of overriding stuff (and the increased chance of bugs) against algorithm strength.

If you decide to go for another hashing algorithm, you should take a look a BCrypt. It is an adaptable cost hashing algorithm, designed to be 'as slow as needed'. This would provide a bigger increase in required cracking time than SHA512. SHA512 is designed as a general purpose cryptographic hash, with speed as one of the design goals.

There are known vulnerabilities in SHA1, but no preimage attack has yet been found. So if the overriding stuff is difficult, you could be better of by generating high entropy random salts.

Having said that, it is of course better to use the best available algorithm.

SHA1 and SH512 are message digests, they were never meant to be password-hashing (or key-derivation) functions. (Although a message digest could be used a building block for a KDF, such as in PBKDF2 with HMAC-SHA1.)

A password-hashing function should defend against dictionary attacks and rainbow tables.

Currently, the only standard (as in sanctioned by NIST) password-hashing or key-derivation function is PBKDF2. Better choices, if using a standard is not required, are bcrypt and the newer scrypt. Wikipedia has pages for all three functions:

• https://en.wikipedia.org/wiki/PBKDF2
• https://en.wikipedia.org/wiki/Bcrypt
• https://en.wikipedia.org/wiki/Scrypt

The page at https://crackstation.net/hashing-security.htm contains an extensive discussion of password security.