如何安全地存储盐以及散列密码 [英] How secure is storing salts along with hashed password

问题描述

如果您已查看asp.net成员资格系统的表模式，则会存储原始密码的哈希以及用于生成它的salt。请参阅下面的模式，

dbo.aspnet_Membership

  ApplicationId 
 UserId 
密码
 PasswordFormat 
 PasswordSalt 
 MobilePIN 
电子邮件
。 。 。 
  

• 如果攻击者获取数据库不是它更容易破解从盐和哈希密码打开原始密码？




• 查看一些记录后，似乎为每个密码生成一个新的盐。这是什么意义？



• 您会建议这样的方法，或在代码中硬编码常量盐

相关

解决方案

如果攻击者知道它们是安全的， >

有关ASP.NET密码/散列/ salt存储的详细信息，请参阅例如 http://msdn.microsoft.com/en-us/library/aa478949.aspx

攻击者允许了解盐 - 你的安全性必须以这样一种方式设计，即使有盐的知识，它仍然是安全的。

盐

盐有助于使用预先计算的彩虹表防御暴力攻击。

Salt暴力破解攻击者的时间（内存时间）更昂贵。$ $ $ $
计算这样的表是昂贵的，通常只有当它可以用于多个攻击/密码时才会执行。 />
如果您对所有密码使用相同的盐，攻击者可以预先计算这样的表，然后将您的密码强制强制显示为明文...

只要生成new

如果你想加强安全性
您可以计算哈希几次（哈希哈希等） - 这不会花费你很多，但它使一个暴力攻击/计算彩虹表格更昂贵...请不要发明自己 - 有成熟的标准方法，请参见例如 http://en.wikipedia.org/wiki/PBKDF2 和 http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

注意：

使用这样的机制就是这些天mandatrory ，因为CPU时间像彩虹表/暴力等）越来越广泛应用（例如，亚马逊的云服务是全球最快的超级跑车50强之一，任何人都可以使用相对较少的数量） p>

If you had looked at table schema of asp.net membership system they store the hash of raw password along with salt used to produce it. see the schema below,

dbo.aspnet_Membership

ApplicationId
UserId
Password
PasswordFormat
PasswordSalt
MobilePIN
Email
. . .

• If a attacker gets hold of the datbase isn't it easier for him to crack open the raw password from the salt and hashed password?

• After looking into some records it seems a new salt is generated for each password. What is significance of this?

• Would you recommend such a approach, or hard-code constant salt in the code

Related

Are salts useless for security if the attacker knows them?

解决方案

For the specifics of ASP.NET password/hash/salt storage see for example http://msdn.microsoft.com/en-us/library/aa478949.aspx

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.

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

NOTE:

Using such a mechanism is these days mandatrory since "CPU time" (usable for attacks like rainbow tables/brute force etc.) is getting more and more widely available (see for example the fact that Amazon's Cloud service is among the top 50 of fastest supercomuters worldwide and can be used by anyone for a comparatively small amount)!

这篇关于如何安全地存储盐以及散列密码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！