电子邮件地址用作密码盐吗? [英] Email address as password salt?
问题描述
使用电子邮件地址作为盐不好吗?密码?
Is it a bad idea to use an email address as the salt for a password?
推荐答案
让我向您介绍此关于安全StackExchange的答案，其中解释了有关密码哈希和密钥派生的很多细节.
Let me refer you to this answer on Security StackExchange which explains a lot of details about password hashing and key derivation.
底线::使用安全的既定密码散列方案，该方案以某种方式占用大量资源来防止暴力攻击，但限制允许的调用次数以防止拒绝服务(DoS )攻击.
Bottom line: Use a secure established password hashing scheme that is somehow resource-intensive to protect against brute-force attacks, but limit the number of permitted invocations to prevent denial-of-service (DoS) attacks.
如果您的语言库具有它的功能，请在升级时验证它是否符合预期的功能，尤其是在PHP的情况下.
If your language library has a function for it, verify on upgrades that it does what it is supposed to do, especially if it's PHP.
下面的答案出于历史原因而保留.
You could use the user's login name as a salt which might be less likely to change than an e-mail address ( 0xA3 correctly pointed out, this is less secure than using the e-mail address because login names tend to be easier to guess, and some are quite commonly used such that rainbow tables may already exist for them, or could be reused for other sites).
或者，在数据库列中保存盐作为密码.
但是随后，您也可以使用随机的用户特定盐，这很难猜测.
Alternatively, have a database column where you save the salt for the password.
But then, you could as well use a random user-specific salt just as well which is harder to guess.
为了获得更好的安全性，您可以使用两种盐:用户特定的盐和系统范围的盐(合并它们，然后使用密码对盐进行哈希处理).
For better security, you could use two salts: A user-specific one and a system-wide one (concat them, then hash the salts with the password).
顺便说一句，盐和密码的简单串联可能不如使用 HMAC 安全. .在PHP 5中，有一个 hash_hmac() 函数可用于这个:
By the way, simple concatenation of salt and passwords might be less secure than using HMAC. In PHP 5, there's the hash_hmac() function you can use for this:
$salt = $systemSalt.$userSalt;
hash_hmac('sha1', $password, $salt);
编辑:系统范围内盐的理由:它可以并且应该存储在数据库外部(但备份.您将无法进行身份验证您的用户(如果您丢失了它).如果攻击者以某种方式能够读取您的数据库记录，则在知道系统范围的盐之前，他仍然无法有效地破解您的密码哈希.
Rationale for a system-wide salt: It can and should be stored outside the database (but back it up. You won't be able to authenticate your users if you lose it). If an attacker somehow gets to read your database records, he still cannot effectively crack your password hashes until he knows the system-wide salt.
编辑(有点题外话):
有关密码散列安全性的进一步说明:您可能还想阅读为什么盐是否会使字典攻击不可能"?多次对哈希进行哈希处理以提供针对蛮力和彩虹表攻击的额外保护(尽管我认为重复哈希可能为拒绝服务攻击带来更多机会，除非您限制每次尝试登录的次数).
EDIT (slightly off-topic):
A further note on the security of password hashes: You might also want to read Why do salts make dictionary attacks 'impossible'? on hashing multiple times for additional protection against brute-forcing and rainbow table attacks (though I think that repeated hashing may introduce additional opportunities for denial-of-service attacks unless you limit the number of login attempts per time).
注意
考虑到多用途多核系统(图形卡，可编程微控制器等)的兴起，可能需要使用具有较高计算能力的算法以及一些盐类来应对暴力破解，例如使用类似PBKDF2的多个哈希.但是，应限制每个时间单位的身份验证尝试次数，以防止DDoS攻击.
Considering the rise of multi-purpose multi-core systems (graphics cards, programmable micro-controllers etc.), it may be worth using algorithms with high computation effort along with salts to counter brute-force cracking, e.g. using multiple hashing like PBKDF2. However, you should limit the number of authentication attempts per time unit to prevent DDoS attacks.
另一件事:使用基于广泛使用的标准而非广泛使用的预构建函数的自定义"哈希的另一个主要原理是PHP本身，事实证明它本身并非如此.在实施与安全相关的内容时，无论是不是那么随机的随机数生成器还是 crypt()函数在某些情况下根本无法工作，从而完全绕过了那些需要计算或内存密集型密码哈希函数的好处带来.
由于其确定性的结果，简单散列函数比键派生函数的输出更有可能经过正确测试，但是您的里程可能会有所不同.
One more thing: Another main rationale for using a "custom" hashing built on widely-used standards rather than a widely-used pre-built function was PHP itself which has proven itself to be not trustworthy at all when it comes to implementing security-related stuff, be it the not-so-random random number generators or a crypt() function that does not work at all under certain circumstances, thereby totally bypassing any benefits that a compute- or memory-intensive password hashing function ought to bring.
Due to their deterministic outcomes, simple hash functions are more likely to be tested properly than the outputs of a key derivation function, but your mileage may vary.
这篇关于电子邮件地址用作密码盐吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
