你会使哪些字符对密码无效?

6 language-agnostic security passwords validation

假设情况:您已经实施了密码处理系统,并且它不会对可以使用的字符施加任何限制.你想建立一些在两件事之间合理妥协的规则 -

  1. 尽可能让用户自由.
  2. 允许您将来可能更改处理密码的方式 - 您不希望排除合理的实施,因为您的用户现有密码将变为无效.

你会施加什么规则?是否有其他因素可能会影响您的选择?

Ant*_*lev 13

永远不要施加任何限制.在我看来,你计划存储密码,而不是哈希.不要这样做.相反,存储和密码和所述盐的哈希组合.

但是,您可以通过对长度(例如,不少于6个字符)和包含密码的字符施加限制来要求您的用户拥有相当强的密码(例如,它应包含大写和小写的字母字符,一个或两个数字和几个非字母字符,如^或#).

  • 不管你做什么,请不要限制最大字符长度;我通过 Keepass 生成了巨大的密码,当我不得不降级为此使用的生成算法时,这让我很恼火。 (2认同)
  • @issy:第一句话很好地回答了你的问题。您不会将密码存储为纯文本的事实并不立即显而易见,因为您正在询问一些晦涩的“密码处理架构更改”。当您存储的只是密码哈希时,可能会出现什么问题? (2认同)

Kev*_*son 9

除非你真的可以为它们辩护,否则最好不受任何限制.

如果您是银行,电子邮件提供商,或者如果用户可以在不提供信用卡的情况下订购某些商品,那么强制用户使用强密码是有道理的.否则,你只是无缘无故地努力.

至于你应该存储什么,我会说禁用控制字符的1024个字符的unicode是关于所有合理的.如果用户无法输入,则应选择不同的密码.您存储的所有内容都是哈希值,因此您可以随时将其缩小到您想要的任何大小.

  • 我使用keepass,它可以选择使用"高ANSI字符,如下所示:`iôhQná"« - óÓSGÉH©EqjË=«ÒquW6> \Jò-§`. (2认同)
  • 我不知道RCIX的评论是否与Kevin所说的相矛盾,但这些不是控制字符,也不会被建议的规则所禁止.它们不是7位ASCII. (2认同)