Question

我们目前正在为我们拥有的网络应用存储纯文本密码。

我一直主张转移到密码哈希，但另一位开发人员表示这样做不太安全 - 更多的密码可以匹配哈希，字典/哈希攻击会更快。

这个论点有什么道理吗？

Answer 1

绝对没有。但没关系。我之前发布了类似的回复：

这很不幸，但是人们，甚至是程序员，都太情绪化了，不容易被争论所左右。一旦他投入了他的职位（如果你在这里发帖，他就是这样），你不可能仅凭事实来说服他。你需要做的是改变举证责任。你需要让他找出他希望能说服你的数据，这样才能了解真相。不幸的是，他有现状的好处，所以你在那里有一条艰难的道路。

Answer 2

来自Wikipedia

某些计算机系统存储用户   密码，用于比较   用户登录尝试，如明文。如果   攻击者获得访问权限   内部密码存储，所有密码   所以所有用户帐户都将是   损害。如果有些用户使用   帐户的密码相同   不同的系统，那些将是   也妥协了。

更安全的系统存储每个   密码以加密方式   受保护的形式，所以访问   实际密码仍然是   收获的傻瓜很难   内部访问系统，而   验证用户访问尝试   仍有可能。

常见的方法只存储一个   明文的“哈希”形式   密码。当用户输入时   在这样一个系统上的密码   密码处理软件运行   通过加密哈希   算法，如果是哈希值   从用户的条目生成   匹配存储在中的哈希   密码数据库，用户是   允许访问。哈希值是   通过应用加密创建   哈希函数到一个字符串组成   提交的密码和，   通常，另一个值称为a   盐。盐防止攻击者   为。建立哈希值列表   常用密码。 MD5和SHA1是   经常使用的加密哈希   功能

您可以在该页面上阅读有关该主题的更多内容。在我看来，在我阅读和使用的所有内容中，散列是一个更好的场景，除非你使用一个非常小的（<256位）算法。

Answer 3

绝对没有理由在网络应用上保留纯文本密码。使用具有salt值的标准散列算法（SHA-1，而不是MD5！），以便无法进行彩虹攻击。

Answer 4

如果您没有加密密码，则会怀疑Rainbow Table攻击（预编译的字典对于给定的哈希具有有效输入）

如果您以明文存储密码并开始阅读安全性，那么其他开发人员应该停止谈论安全性。

碰撞是可能的，但通常不是密码应用程序的大问题（它们主要是在使用哈希作为验证文件完整性的方式的区域中的问题）。

所以：给你的密码加盐（通过在密码的右侧添加Salt *）并使用一个好的哈希算法，如SHA-1或最好是SHA-256或SHA-512。

PS：关于哈希here的更多细节。

*我有点不确定Salt是否应该到字符串的开头或结尾。问题是如果你有一个冲突（两个输入具有相同的哈希值），将Salt添加到“错误”端将不会改变产生的哈希值。无论如何，Rainbow Tables不会出现大问题，只有碰撞

Answer 5

我不明白你的其他开发者的东西是什么'更多的密码可以匹配哈希'。

有一种说法是'哈希攻击会更快'，但前提是你没有对密码进行腌制，因为它们是哈希值。通常，散列函数允许您提供一个盐，这使得使用已知散列表浪费时间。

就个人而言，我会说'不'。基于以上所述，以及如果你以某种方式获得明文暴露的事实，盐渍的散列值对于试图进入的人来说没什么价值。散列还提供了使所有密码“看起来”的好处相同的长度。

即，如果散列任何字符串总是导致20个字符的散列，那么如果你只有要查看的散列，则无法判断原始密码是8个字符还是16个字符。

Answer 6

我在工作场所遇到了同样的问题。我用它来说服哈希更安全的是写一个SQL注入，它从我们站点的公共部分返回用户和密码列表。它立即升级为一个主要的安全问题：）

为了防止字典/散列攻击，请确保对每个用户唯一的标记进行散列并且静态（用户名/加入日期/用户组合运行良好）

Answer 7

关于假装成密码学的程序员有一句古老的说法：）

Jeff Atwood在这个主题上有一篇好文章：You're Probably Storing Passwords Incorrectly

为了更广泛地回复，我同意上述所有内容，由于多个密码匹配相同的哈希，哈希使理论更容易获取用户的密码。然而，与访问您的数据库的人相比，这种情况发生的可能性要小得多。

Answer 8

有一个事实是，如果您对某些内容进行哈希处理，是的，就会发生冲突，因此可以使用两个不同的密码来解锁同一个帐户。

从实际的角度来看，这是一个不好的论点 - 一个好的散列函数（md5或sha1会很好）几乎可以保证对于所有有意义的字符串，特别是短字符串，不会发生冲突。即使有，两个密码匹配一个帐户也不是一个大问题 - 如果有人能够足够快地随机猜测密码以至于他们很可能进入，那么你就会遇到更大的问题。 / p>

我认为以明文形式存储密码比密码匹配中的哈希冲突存在更大的安全风险。

Answer 9

我不是安全专家，但我觉得如果纯文本更安全，哈希就不会存在。

Answer 10

理论上，是的。密码可以比散列更长（更多信息），因此存在散列冲突的可能性。但是，大多数攻击都是基于字典的，并且冲突的概率比成功的直接匹配要小得多。

Answer 11

这取决于你正在防守的是什么。如果是攻击者拉下你的数据库（或欺骗你的应用程序显示数据库），那么明文密码就没用了。有许多攻击依赖于说服应用程序泄露它的私有数据 - SQL注入，会话劫持等。通常最好不要保留数据，但要保持散列版本这么糟糕的人不能轻易使用它

正如你的同事建议的那样，通过对字典运行相同的哈希算法并使用彩虹表来提取信息，可以轻而易举地解决这个问题。通常的解决方案是使用秘密盐加上额外的用户信息来使散列结果独特 - 例如：

String hashedPass=CryptUtils.MD5("alsdl;ksahglhkjfsdkjhkjhkfsdlsdf" + user.getCreateDate().toString() +  user.getPassword);

只要您的盐是秘密的，或者您的攻击者不知道用户记录的确切创建日期，字典攻击就会失败 - 即使他们能够下拉密码字段。

Answer 12

没有比存储纯文本密码更安全的了。如果你正在使用一个像样的哈希算法（至少SHA-256，但是甚至SHA-1总比没有好）那么是的，冲突是可能的，但是没关系，因为给定一个哈希，它是不可能的*计算什么字符串哈希到它。如果您使用密码对用户名进行哈希处理，那么这种可能性也会消失。

* - 技术上并非不可能，但“计算上不可行”

如果用户名为“graeme”且密码为“stackoverflow”，则创建一个字符串“graeme-stackoverflow-1234”，其中1234是一个随机数，然后哈希并存储“ hashoutput 1234“在数据库中。在验证密码时，请使用用户名，提供的密码和存储值末尾的数字（散列具有固定长度以便您始终可以执行此操作）并将它们一起散列，并将其与散列进行比较部分储值。

Answer 13

更多密码可以匹配哈希，字典/哈希攻击会更快。

是和否。使用现代哈希算法，如SHA变体，并且该参数非常非常周。如果蛮力攻击只需要352年而不是467年，你真的需要担心吗？（那里有轶事的笑话。）获得的价值（没有密码存储在系统上的纯文本中）远远超过了你同事的担忧。

Answer 14

希望您原谅我插入我在此处写的解决方案，使用客户端JavaScript在密码传输之前对其进行哈希处理：http://blog.asgeirnilsen.com/2005/11/password-authentication-without.html

替换app的纯文本密码

14 个答案: