这个问题已有 8 年以上的历史，而且时代已经改变： https ://arstechnica.com/information-technology/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-死的/
密码：https ://en.wikipedia.org/wiki/PBKDF2
数据：SHA3
SHA512 比 SHA1 更复杂，但是与使用 512 散列相比，使用 SHA1 散列加盐密码会损失多少安全性？就拥有数据库的人破解单个密码所需的时间而言。我使用的框架不能让我轻松访问 SHA512，我必须重写一些东西才能使其工作，所以我想只使用 SHA1，尽管过去我一直使用 SHA512。
目前已知的 SHA-1 弱点不会影响您尝试执行的操作的安全性。无法从其散列版本中恢复密码依赖于“原像抗性”，据我们所知，使用 SHA-1 仍然完全不可行。使用 SHA-512、SHA-256 甚至 MD4 或 MD5 也是完全不可行的。以科幻为导向的头脑可能会设想计算机在 2050 年左右实现为 MD4 或 MD5 寻找原像的能力；SHA-1 需要更长的时间。
现在碰巧的是，虽然在 SHA-1 上计算原像没有已知的捷径，但也几乎没有安全证据。用数学术语来说，如果 SHA-1 中使用的压缩函数与“随机预言”无法区分，那么它对原像是安全的。但是 SHA-1 的已知弱点（理论上）会导致冲突，这也表明它的压缩功能不是随机预言机。因此，SHA-1 对原像的安全性不再是“它不会破坏有很好的数学理由”的说服力。它更像是“嗯，还没有找到如何破解它”的那种。
用更普通的话来说，如果您使用 SHA-1，那么您可能不得不为自己辩护。即使您没有做错任何事情，您对 SHA-1 的选择也会受到质疑。而没有人会质疑使用 SHA-256 或 SHA-512，即使这意味着一些开发开销。简而言之，使用 SHA-1 是不好的公共关系。
请注意，加盐与该问题完全正交。加盐旨在防止对不同密码实例的攻击之间的成本分摊。预计算表（包括所谓的“彩虹表”）是一种共享（建表成本高，但可用于攻击 2、10、10000 个密码，每个被攻击密码的额外成本很小）。盐渍打败了分享。加盐很好。击败共享很重要，因为攻击一个密码是可能的：不是因为散列函数，而是因为密码是适合人脑的东西，因此可以暴力破解（“字典攻击”）。对于与密码相关的任何事情，您不会因为散列函数的弱点而遇到问题，而是因为您首先使用密码。
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)
如果你必须重写东西来获得除SHA1工作之外的任何东西，你将不得不平衡重写东西的复杂性（以及增加的错误机会）与算法强度。
如果您决定使用另一种散列算法，您应该看一下BCrypt. 它是一种适应性成本散列算法，旨在“尽可能慢”。这将提供比 更大的所需开裂时间增加SHA512。SHA512被设计为通用加密哈希，以速度作为设计目标之一。
中存在已知漏洞SHA1，但尚未发现原像攻击。因此，如果压倒一切的东西很困难，则最好通过生成高熵随机盐来实现。
话虽如此，使用最好的可用算法当然更好。
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:
The page at https://crackstation.net/hashing-security.htm contains an extensive discussion of password security.