公开哈希密码(带有盐)有多安全？

Question

我正在开发一个基于块链的分布式应用程序，它存储Client信息。我正在考虑在网络上对Clients进行认证的其他方法。我得到的一个想法是将Username和Password与Client数据结构联系起来--其中Password是一个哈希(salt+password)，其中salt只与我们(区块链操作符)安全地存储在一起。

最明显的安全问题是，所有参与网络的成员现在都可以查看这些密码的散列版本--这有多安全？还有其他我应该考虑的方法吗？

Answer 1

主要问题将是密码策略和用户。如果让用户选择任何密码，那么他们会倾向于使用1234作为密码。系统中的恶意用户可以很容易地强暴所有广泛应用不安全的密码。如果您有一个好的策略，唯一的方法是暴力-强制，因为我们不能扭转哈希和盐防止彩虹表。有关密码的一般指南，请参阅NIST数码身份证指引800-63B。

在考虑攻击风险的同时，我们已经假设攻击者访问用户的数据库，我们设计密码系统作为抵御攻击者的最后一道防线。据此，我们设计我们的系统，而不是通过不透明的安全。所以你已经进入这个阶段了。

实际上，我们不使用简单的哈希技术来存储密码。例如，PBKDF2中的迭代可以将攻击者的时间减少10000倍。此外，您还需要防止大规模并行化，就像在哈希猫的GPU使用中一样。

您应该使用PBKDF2、Bcrypt或更好的argon2，这是密码哈希竞赛的赢家。

此外，有关一般性建议，请参阅信息安全中的如何安全地破解密码？。

Answer 2

这取决于您使用的哈希函数。如果您使用像MD5、SHA 1-、SHA-3这样的快速散列，它是不安全的，因为它们会使野蛮强制变得更容易。

有一组哈希函数(也称为键拉伸或密码派生函数)，如PBKDF2、scrypt、Argon2，它们对每个散列都需要相对较多的计算资源(多CPU、多内存)。单个用户注意到没有差别。但是这些功能使得暴力本质上比正常的快速散列更昂贵。使用这些散列函数是相当安全的。如果有人用这样的哈希访问您的数据库，就不可能从这样的哈希恢复密码。

“还有其他办法吗？”：是的。许多。

1. 使用您或公司颁发的客户端证书对用户进行身份验证。那你根本不需要任何哈希。
2. 使用2因素身份验证。它可以基于SMS，OTP (一次密码)，TAN，包括照片-TAN.想想Yubikey或Titan硬件令牌。
3. 定义用户访问配置文件。它是IP范围、设备数据(笔记本电脑、智能手机模型等)、浏览器数据(浏览器代理、屏幕分辨率等)的组合。这是谷歌使用的东西。对于谷歌来说，你不必强迫用户使用复杂的密码。你不用想太多哈希。如果您输入正确的密码从一个未知的设备或IP，谷歌需要更多的确认是你。

重要:我建议你考虑一下，如果额外的方法足够你保护什么。

如果smb的话，您或您的用户将付出什么代价。找回一些密码？实现其他方法的成本是多少？如果您的应用程序的全部目的是发送定制的贺卡，那么黑客这样的帐户不会导致任何严重的伤害，甚至正常的快速散列，如SHA-3是足够的。但是，如果您的应用程序提供了对银行帐户的访问，您可能需要进行严重的2因素身份验证，因为在恢复密码的情况下，成本要高得多。