我们有许多网络服务和网络应用程序以不同方式对用户进行身份验证，其中一些具有不同的密码要求，原因非常糟糕。例如，一个系统拒绝$符号，直到有人“修复”某些Perl脚本中的字符串处理。另一个系统似乎在密码中解析@个标志。另一个系统向用户发出密码，开发人员很自豪地告诉我这是用户名的可逆转换。
我知道密码哈希是首选;但我想知道在向基于浏览器的软件过渡中必须牺牲多少。对于我自己的启发，并提出改变的案例，是否有关于密码处理和管理主题的权威参考，我可以在我的部门和那些负责其他服务的人员中展示？
答案 0 :(得分：9)
您可以对密码中允许的字符设置的限制越少越好 - 它会增加尝试暴力破解的人的搜索空间。理想情况下，没有理由在密码中禁止任何ASCII字符（除了控制字符和backspace / newline之类的东西）。
就长度限制而言，最小限制是好的（例如，不要通过设置最小长度10来惹恼用户），最大限制是不好的。如果有人想要一个50个字符的密码，那就让它们 - 存储不应该是一个问题，只要你进行散列，因为散列的长度是恒定的。
始终以不可逆的哈希形式存储密码 - 理想情况下，密码安全密码。没有理由以可逆的形式存储它们（如果有人忘记了密码，只需为它们设置一个新密码，不要试图“检索”它）。不要编写自己的哈希算法 - 很可能你不是加密专家，并且有很多好的，经验证的哈希算法，只有实现（代码或库形式）才能实现关于任何主流语言。
用足够长度的每用户盐对哈希进行加盐，以防止rainbow table开裂。
第5章及第5章Pro PHP Security中的6处理密码的存储和加密：
一些相关文章：
答案 1 :(得分：3)
我建议您查看OWASP等网站。他们处理更广泛的Web应用程序安全主题，当然密码保护是一个关键特性。我相信你会在那里找到更多的信息。
还有像Foundstone这样的公司可以向您的开发团队讲授最佳实践并审核您现有的应用程序。
答案 2 :(得分：2)
设置短的长度限制和过滤字符是我经常看到的两个错误，这些错误让我感到困扰。正确地散列密码应该完全不需要这样做，这对最终用户来说可能是一个真正的痛苦。
我使用MD5（密钥+关键字）生成我的个人密码 - 例如我的银行密码是MD5（“NotTelling”+“Bank”）。很多网站似乎都会通过强密码来阻止用户，并且从来没有充分的理由。
显然，一个好的盐腌哈希是要走的路。
What algorithm should I use to hash passwords into my database?有一篇关于最佳实践算法的好文章。
答案 3 :(得分：1)
如果您设计一个处理密码的系统，并且可以使用它来获取用户的密码，那么系统就不安全了。
这是更安全的一般必要条件的一部分：设计师不应该破坏系统。