保护通过电子邮件发送给用户的临时密码？
我设置了一个简单的 Web 应用程序，管理员可以在其中创建用户。用户并不创造自己。管理员所要做的就是输入用户名和电子邮件，然后将临时密码发送给用户以供他们登录。该电子邮件以纯文本格式发送。如果用户首次登录，则需要更改密码并输入安全问题和答案。用户显然必须知道他们的临时密码才能第一次登录，这是我知道让他们知道的唯一方法（通过电子邮件）。另一种选择是让管理员致电用户并通过电话或亲自告诉他们临时密码，但这并不实用。我该如何处理这样的情况？
I have a simple web application set up where admins can create users. Users do not create themselves. All an admin has to do is enter a username and an e-mail and a temporary password is sent to the user for them to login. This e-mail is sent in plain text format. If the user is logging on for the first time, they are required to change their password and enter a security question and answer. The user obviously has to know their temporary password in order to login for the first time and this is the only way I know of letting them know (through e-mail). The other option would be to have the admin call the user and tell them over the phone or in person their temporary password, but this is not practical. How could I handle a situation like this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我通常使用基于后端邀请记录的临时 URL。本质上，您创建一个邀请记录并根据一些信息（例如用户的电子邮件地址、时间戳和随机值）生成哈希。将哈希存储为邀请记录的一部分，然后向他们发送一个以哈希作为参数的 url。
当他们单击链接时，会查找邀请并验证它是否存在且尚未使用 - 然后允许他们设置密码并使邀请无效。
它不再需要发送任何类型的密码，如果您愿意，您还可以在邀请记录上设置过期时间。
I typically use a temporary url based on an invite record on the back end. Essentially you create an invite record and generate a hash based on some information perhaps the users email address, a timestamp and a random value. Store the hash as part of the invite record and then send them a url with the hash as the parameter.
When they click the link lookup the invite and validate that it exists and has not been used - then allow them to setup their password and invalidate the invite.
It gets rid of the need to send any sort of password and you can set an expiry on your invite records if you want as well.
您描述的情况很常见 - 通过电子邮件发送临时密码并要求在首次登录时更改它。除非您对该模型有特定的问题，否则我认为没有理由不使用它。让管理员呼叫用户可能会变得复杂 - 我会不惜一切代价避免这种情况。
The scenario you describe is very common- emailing a temporary password and requiring it to be changed on first login. Unless you have a specific problem with this model I see no reason not to use it. Having an admin call users can get complicated- I would avoid this at all costs.
您可以生成一个自定义 url，其中密码和用户哈希作为参数，用户必须自行登录。如果攻击者没有信息，哈希值将很难检索
You can generate a custom url with a password and user hash as argument where the user has to log itself. The hash will be difficult to retrieve if the attacker does not have the information