fie*_*d_b 5 .net hash cryptography salt
我了解散列和加盐的必要性,但是我不明白如何将盐存储在相同(可能受到威胁)的数据库中,因为整个散列是安全的。例如,我正在研究的一本书指示通过随机生成一个整数并使用RNGCryptoServiceProvider创建一个byte []来为每个用户(良好)创建唯一的哈希。很好,但是为了在登录时验证用户密码,有必要从数据库(或其他文件)中读取唯一的盐。这是储存盐的安全方法吗?
假设您是一个坏人,并且可以访问密码数据库。那里有很多信息,情况已经够糟了。对于我们其他人来说,唯一的好消息是这最终将是死数据。您真正想要的是访问正在运行的系统,并使该系统能够执行您想做的任何事情……特别是如果没人知道您在其中。
这是窍门。要获得访问权限,您实际上不需要发现真实的密码:您只需要查找一些导致相同哈希值的文本值即可。更糟糕的是,您无需强求结果。那里有有用的表格,可让您快速查找将产生所需哈希的文本。
因此,盐的目的是在这些预先计算的表格上增加皱纹。您可能有一个可以产生特定哈希值的值,但是预先计算的“彩虹表”并没有考虑盐。盐完全改变了哈希。现在,您又回到了蛮力地使用单个密码的地步,并且如果系统设计人员使用了可能花费数年的良好加密算法。
这里的好处是,即使您知道它的价值,盐也会产生这种影响。即使盐是公开的,仅按用户添加盐也会破坏攻击者使用您的密码数据库进行彩虹表攻击的能力。
(不过,共享盐会使攻击者开始使用通用密码等运行破解解决方案,然后开始将其扔在墙上……将散列结果与所有用户进行比较,看看会发生什么)。
这是安全的,因为访问盐并不会使攻击者更容易逆转哈希过程。给定密码、盐和哈希值,您可以快速检查三元组是否正确。但是,您无法使用盐的知识来帮助您获取密码。
回想一下,首先需要盐的原因是为了避免相同的密码产生相同的哈希值。如果没有盐,攻击者将能够对“彩虹表”进行哈希处理,并根据编码字典检查哈希值。
| 归档时间: |
|
| 查看次数: |
1042 次 |
| 最近记录: |