生成重置密码令牌的最佳实践 [英] Best practice on generating reset password tokens

问题描述

有关如何构造重设密码令牌的任何最佳做法?我在想:

Any best practice on how a reset password token should be constructed? I'm thinking:

随机的17个字符[a-zA-Z0-9] +全局唯一ID +随机的17个字符[a-zA-Z0-9].

random 17 characters [a-zA-Z0-9] + a globally unique id + random 17 characters [a-zA-Z0-9].

是否有更好的解决方案或重置密码令牌的行业标准?

Is there a better solution, or an industry standard on reset password tokens?

推荐答案

需要考虑一些重要点.

1. 该代码应该真正是随机的(从MCRYPT_DEV_URANDOM中读取)，并且不应从其他与用户相关的信息中得出.
2. 理想情况下，代码采用base62编码(A-Z a-z 0-9)，以避免网址出现问题.
3. 仅存储数据库中令牌的哈希值 ，否则具有对数据库的读取访问权限的攻击者可以重置任何帐户.

这导致以下问题:在用户单击链接之后，您必须在数据库中找到令牌的哈希.有两种可能的方式来存储令牌:

This leads to the problem that you have to find the hash of the token in the database, after the user clicked the link. There are two possible ways to store the token:

• 您可以使用SHA512之类的哈希算法对令牌进行哈希处理，而无需添加盐.如果令牌非常强大(最小长度为20，且0-9 a-z A-Z)，则这是安全的.从理论上讲，您必须先检查此类哈希是否已经存在，然后再将其输入数据库，实际上这是可以忽略的.我实现了一个密码重置类，它可以处理此类令牌.
• 您用BCrypt和salt哈希令牌.这允许使用较短的令牌，但是您无法在数据库中搜索哈希令牌.相反，您必须在链接中包含一个行ID才能找到令牌.

• You hash the token with a hash algorithm like SHA512 without a salt. This is secure if the token is very strong (minimum length 20 with 0-9 a-z A-Z). Theoretically you have to check whether such a hash already exists before you enter it in the database, in practise this is negligible. I implemented a password-reset class that can handle such tokens.
• You hash the token with BCrypt and salt. This allows for shorter tokens, but you cannot search for the hashed token in the database. Instead you have to include a row-id in the link to find the token.

这篇关于生成重置密码令牌的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！