散列和腌制密码字段 [英] Hashing and salting a password field

问题描述

我一直在讨论如何将密码存储在我的数据库中一段时间​​。这是我第一次用网络登录创建一个安全的应用程序，所以我想建立一些良好的实践。

首先，我阅读哈希和腌制。这似乎是... ...
$ b

1. 获取散列算法
   
2. 从用户


3. 将$ salt添加到用户的纯文本密码中
   
4. 对整个密码进行哈希（包括salt）
   
5. 将salt存储在数据库中，以便稍后可以检索它（用于验证PSWD）
   

这让我想到了......如果黑客知道你的盐（因为它存储在数据库的某个地方，可能是一个名为 this_is_not_the_salt_ur_looking_for 或类似含糊不清的列），他们可以重新生成密码字典并获得访问权限。

然后我有个想法。如果您将salt 存储在哈希密码字段中，该怎么办？因此，按照步骤1-4（随机生成盐），然后在步骤5中，将盐放入密码解释类或服务已知的密码中：

xxxxxsaltvaluexxxxxxxxxxxxxxxx

其中x是散列字符串值。任何人都可以看到这个问题吗？这完全没有必要吗？

答案：

没有理由不这样做。正如Yahia所说，保护密码的其他方法包括双（或n）散列。在另一个说明中，BCrypt看起来像是一种几乎完全停止暴力攻击的好方法，但我无法为C＃找到一个可信任的库

谢谢！

TTD

解决方案

从安全角度来看，只要您只存储哈希密码（ NEVER <存储明文密码！）加上盐......攻击者可以知道盐 - 你的安全必须设计成即使知道盐也是如此仍然安全。

盐做什么？

盐帮助防守
使用预先计算好的彩虹表对暴力攻击进行攻击。

Salt对暴力攻击者造成了更高的价格（时间/内存）$
b $ b计算这样一个表是昂贵的，通常只有当它可以用于多个攻击/密码时才能完成。

如果你使用相同的盐来表示攻击者的所有密码c应该预先计算这样的一张表，然后将你的密码强行转换为明文...

只要你为每个你想存储hash的密码生成一个新的（最好的cryptogrpahically强）随机盐没有问题

的。
$ b

至于你在伪装盐的想法
这应该是避免的安全通过隐晦。

虽然在这种情况下，我看不出任何积极的消极影响。

如果您想进一步加强安全性

你可以计算散列几次（散列散列等）这并不会让你付出太多的代价，但它会导致暴力攻击/计算彩虹表更加昂贵......请不要发明自己 - 有成熟的标准方法可以做到这一点，例如 http://en.wikipedia.org/wiki/PBKDF2 和 http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

I have been tossing around the question of how to store the passwords in my DB for some time now. This is my first time at making a secure application with a web login, so i wanted to set up some good practices.

First, i read up on hashing and salting. It seems that the idea is...

1. Get hashing algorithm
2. Get password from user
3. Add 'salt' to plain text password from user
4. hash the entire password (including salt)
5. Store the salt in the db so that you can retrieve it later (for verification of PSWD)

And that got me thinking... If a hacker knows your salt (because it is stored in the DB somewhere, maybe a column called this_is_not_the_salt_ur_looking_for or something equally ambiguous) they can re-generate the password dictionary and gain access.

Then i had an idea. What if you stored your salt inside the hashed password field. So follow steps 1-4 (randomly generating the salt), then in step 5, insert the salt in the password somewhere known by the password interpreting class or service:

xxxxxsaltvaluexxxxxxxxxxxxxxxx

where x is the hashed string values. Can anyone see any issues with this? is it just completely unnecessary?

Answer:
There is no reason why this couldnt be done. As Yahia states, other methods of securing a password include double (or n) hashing. On another note, BCrypt looks like a good method of stopping brute force attacks almost entirely, but I couldnt find a trusted library for C#

Thanks!
TTD

解决方案

From a security standpoint that is not necessary as long you only store the hashed password (NEVER store the cleartext password!) plus the salt... an attacker is "allowed" to know the salt - your security must be designed in a way that even with the knowledge of the salt it is still secure.

What does the salt do ?

Salt aids in defending against brute-force attacks using pre-computed "rainbow-tables".
Salt makes brute-force much more expensive (in time/memory terms) for the attacker.
Calculating such a table is expensive and usually only done when it can be used for more than one attack/password.
IF you use the same salt for all password an attacker could pre-compute such a table and then brute-force your passwords into cleartext...
As long as you generate a new (best cryptogrpahically strong) random salt for every password you want to store the hash of there is no problem.

As for your idea in "disguising" the salt
That is more of "security by obscurity" which should be avoided.
Although in this case I neither see any positive nor negative effect.

IF you want to strengthen the security further
You could calculate the hash several times over (hash the hash etc.) - this doesn't cost you much but it makes a brute-force attack / calculating "rainbow-tables" even more expensive... please don't invent yourself - there are proven standard methods to do so, see for example http://en.wikipedia.org/wiki/PBKDF2 and http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

这篇关于散列和腌制密码字段的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！