SHA 哈希的最佳临时密码长度
创建“忘记密码”机制时，我们可能希望为用户创建一个使用 SHA1 存储的临时密码（请随意建议其他 C# 加密机制）。
临时密码应该设置多长时间？ 太短了，可能会被暴力破解。 太长并且不必要的长度是多余的，因为字符串无论如何都会被散列？ （因为 20 个字符和 50 个字符的字符串无论如何都会产生相同长度的哈希值）
更新
抱歉，如果这有误导性。 当然，我们可以凭空选出一个数字，但我想知道是否有一个很好的数学理由来选择 13 而不是 12。
When creating a "forgotten password" mechanism, we might want to create a tempory password for the user which is stored using SHA1 (feel free to suggest other C# Cryptography mechanism).
How long should we make the tempory password? Too short, it could be brute forced. Too long and the unnecessary length is redundant since the string is hashed anyway? (Since a 20 character and 50 character string results in a hash of the same length anyway)
Update
Sorry if this was misleading. Sure we can pick a number out of the air, but I was wondering if there was a good mathematical reason to pick 13 rather than 12.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我认为这是关于临时密码的好建议：
The权威指南基于表单的网站身份验证
它讨论了避免生成它们，以利于实现用户想要的实际操作。
I think this is good advice regarding temp passwords:
The definitive guide to form-based website authentication
It talks about avoiding generating them in favour of getting to the real action the user wants.
我一般选择 10 个字符。 没有什么特别的原因，只是我猜测用户选择的密码长度高于平均长度。
仅仅因为它是随机生成的，它可能会比用户选择的任何内容更安全且更难以暴力破解。 人们选择愚蠢的密码，例如 myspace1、stackoverflow1、12341234 等。
I generally go with 10 characters. No particular reason for that, just something that I'd guess is above average length for a password chosen by a user.
Just by the fact that it's randomly generated, it'll probably be more secure and more difficult to brute force than anything chosen by your users. People pick stupid passwords such as myspace1, stackoverflow1, 12341234 etc.
如果密码是字母数字字符，那么每个字符只有大约 6 位可用数据，因此您认为密码长度超过 20 个字符是没有意义的，这是错误的。
If the password is in alphanumeric characters you only have about 6 bits of usable data per character and therefore you're wrong that there's no sense making a password longer than 20 characters.
看来您担心临时密码比用户密码更强……而实际上，像 10 个字符的 base-64（或类似的 - 标点符号等）之类的密码将很难破解，而且强度要强得多比用户将生成的密码......
It seems like you are worried about making the temporary password stronger than the user's password... when in reality, something like a 10-character base-64 (or similar - punctuation etc) is going to be very hard to crack and much stronger than the password the user will generate....
也将其设置为可变大小（例如 8-12 个字符），这将使暴力破解变得更加困难...如果攻击者知道您返回 X 字符密码，他们所要做的就是尝试所有带有 N 的密码...假设N 很大，这是不切实际的，但是改变 N 的大小至少会让他们变得更加困难。
Make it a variable size as well (say 8-12 character) that will make it harder to brute force... if the attacker know you return an X character password all they have to do is try all passwords with N... assuming N is large it'll be impractical, but varying the size of N will at least make it that much harder for them.
Steve Gibson 创建了一个“超高安全性密码生成器”。
在该页面上，他在每个页面显示上生成 3 个不同的密码：
他还解释了背后的原因这。 这是一本很好读的书。 希望这可以帮助。
Steve Gibson has created a "Ultra High Security Password Generator".
On that page he generates 3 different passwords on every page display:
He also explains the reasons behind this. It's a nice read. Hope this helps.
按照您的网站为用户推荐的长度进行选择。 当生成随机的 Base64 字符字符串时，我会使用 8 个字符的密码在晚上安全入睡。 但当然，我会将登录尝试限制为每 X 秒一次，并在 Y 次尝试失败后暂时禁用帐户。
请记住在散列之前添加每个用户唯一的salt，以阻止基于数据库的攻击。
Go for whatever length your site specifies as recommended for the users. When generating a random string of base64 chars, I would sleep safely at night with 8-char password. But of course I'd limit login attempts to once every X second, and temporarily disable account after Y failed tries.
And remember to add a per-user unique salt before hashing, to thwart database-based attacks.