您通过电子邮件发送的任何内容都可能被监视。这就是电子邮件安全的方式（没有）。因此，通过电子邮件发送机密数据是一个问题。我们仍然偶尔会这样做，但那是因为我们没有更好的选择。但我们应用缓解措施：

• 密码是“一次性”的，这意味着如果它被拦截和使用，要么真正的接收者已经使用它（然后攻击者被挫败），要么真正的接收者在尝试使用它时会注意到问题（然后至少暴露了攻击）。

• 临时密码的唯一允许使用是访问允许注册更永久密码的页面或屏幕，该密码由用户自己选择（即未在电子邮件中传播的密码）。

• 此类密码是随机生成的，因此它们各自具有很强的安全性，即使在观察了很多以前的密码之后，也无法“猜测”下一个临时密码。

无需在任何地方以纯文本形式存储密码，无论是临时的还是永久的。服务器必须存储的是允许验证给定密码的内容，即密码哈希。

电子邮件临时密码通常也称为“密码重置链接”。这是相同的功能，只是有一个额外的功能，https://以便可以通过鼠标单击“输入”临时密码。

你说得对，严格来说这并不安全，但这也是我们能做的最好的。密码应为一次性使用，并要求用户在使用时更改密码。因此，如果用户实际请求它，那么他们将知道是否有其他人在他们之前使用它。

如果他们没有要求，除非有比电子邮件更安全的联系方式，否则电子邮件是联系他们的唯一选择。电子邮件可能被截获，他们不知道攻击者请求更改，但下次他们登录时，他们将无法以这种方式发现漏洞。

这并不理想，但它是大多数时候可用的最佳选择。

有人可能会找出他们用来生成这些密码的算法吗？

那要看。我的方法是简单地从 生成人类可读的输出/dev/urandom，在这种情况下这不太可能？

这些临时密码也必须以纯文本形式存储在某处，对吗？

实际上，没有。如果相关站点使用安全密码存储方案，即加盐慢速散列，例如 bcrypt 或 PBKDF2，他们需要做的是存储密码的派生散列。本质上，这与您指示服务器更改密码相同，但服务器代表您更改密码。

因此，将密码保存在内存中的窗口只要生成密码、在电子邮件中发送、散列和存储密码所需的时间就可以了。

现在，问题的真正实质是，这真的是向某人发送密码的安全方式吗？答案不是真的，但替代方案是：

• 带有用于密码重置的令牌的链接。
• 带外通信（给用户打电话）。
• 将他们的明文密码通过电子邮件发送给他们，就像某个词的最佳网络安全职业网站所做的那样。

第二种选择可能令人望而却步。后者不好存储密码。第一个选项是“一样糟糕”，因为您劫持帐户所需的只是访问该电子邮件。

我认为，结合此密码重置的限时使用窗口，目前对于没有支持其他密码重置方法的基础设施的通用网站来说，这是可能的最佳解决方案。

所有这些答案都假设获取密码重置电子邮件/链接需要了解有关帐户的信息，而不仅仅是电子邮件地址。秘密问题完全是另一种蠕虫，所以让我们假设获得密码重置链接/电子邮件至少比知道电子邮件地址更困难。

我不认为这是安全风险，因为如果您使用像 Gmail 这样的优质电子邮件提供商，它将对其所有通信强制执行 (SSL/TLS) 加密。

只要唯一可以访问电子邮件帐户的人是您，并且在您阅读电子邮件时没有人在看您的肩膀，电子邮件中发送的密码的安全性就等于通过 HTTPS 连接以明文形式提交您的密码。

但是，如果密码是以明文形式发送的，您应该尽快更改它，以明文形式留在电子邮件中的密码可能会在以后带来安全风险。