如果我理解正确的话，通过电子邮件发送密码最大的问题是需要将密码以明文形式存储在数据库中。如果数据库遭到破坏，攻击者将获得对所有帐户的访问权限。
有解决这个问题的方法吗？
如何使通过电子邮件向用户发送密码尽可能安全？
简单的答案是：不要。如果你认为你的数据库不安全，那么电子邮件就少得多了。
如果你的意思是，你想在他们注册时向他们发送密码，那么你可以在将其存储在数据库中之前这样做。
如果你的意思是，在他们注册后，唯一的选择是以明文形式存储（同样，不要这样做），或者制作一个新的随机密码并发送给他们。不可能从哈希中获取他们的密码，这就是为什么它使密码存储更安全的原因。最好的选择是生成您发送给他们的新（临时）密码，或者生成一个令牌，让他们访问密码更改系统。
您可能需要考虑一个好的哈希算法，如BCrypt，其中包含一个salt。
我不知道我的建议是否适用于您的场景，但您应该更好地对数据进行哈希或加密，并发送密码重置链接，而不是纯文本密码。
当密码在电子邮件中以明文形式出现时，它本身就不安全。
因此，没有一种安全的方式可以安全地在明文中发送密码。
您不应该将密码以明文形式存储在数据库中，而应该使用带盐的散列。当用户输入他们的密码时，你用salt对其进行散列，并与存储的散列进行比较。
当人们忘记密码时，您应该发送由过期令牌备份的重置链接，而不是通过电子邮件发送密码。这将生成一个临时的新密码（将在几分钟内过期）。
您应该对数据库中的所有密码进行哈希处理。
sha1($_POST['password'].$salt.$username);
如果密码丢失
用户请求一个密码重置链接，该链接包含在"user_meta"表中生成的哈希。当用户收到此链接时，会将哈希与数据库中的哈希进行比较，用户将能够使用新密码更新当前密码。
密码的PTXT是neverreviled。
您只比较哈希
是的，有一个常见的解决方法。
假设您的数据库中有您的用户。
您发送包含一些"密钥"信息（如guid）的"密码重置链接"。一个示例链接是一个表单：
http://your.site.com/setpassword?id=5b070092-4be8-4f4d-99952-1b915837d10f
在您的数据库中，您存储已发送指南和电子邮件之间的映射。
当有人打开你的链接时，你会检查你的数据库，然后你就可以找到谁想要这个页面——因为任何有效的guid都会映射到一封电子邮件。然后，假设用户的电子邮件未被泄露，您可以安全地让用户更改其密码。
当要存储密码时，您永远不会将其存储为纯文本，您总是对密码进行散列，当有人闯入您的数据库时，使用额外的随机盐使字典攻击更加困难。
有一种变通方法，它的安全性不如密码重置，但如果要求向用户发送密码，而不是重置链接，则可以使用。
你要做的是生成一个新密码，它包含足够的随机性，很难猜测，但格式也很容易让他们记住和读出（比如通过电话）。
类似于：xyz-xyz-xyz-nnnn，其中xyz是一个易于拼写但不常见的单词，nnnn是一个四位数。
然后设置它，使其成为第一次登录时需要更改的临时密码。
使用与设置普通密码相同的逻辑设置密码，以便对其进行正确的加盐和哈希处理，然后通过电子邮件发送密码明文，就像这样。
尊敬的FirstName LastName，
您请求我们重置您的密码。
您的新密码为：
insipid-mirth-nonplus-9174您可以使用此密码登录系统一次，然后需要输入新密码。
重要注意事项
该系统存在一些严重的漏洞，不适合数据安全至关重要的网站。有不止这些，但这些是我知道/能想到的：
- 与使用密码重置链接的系统不同，该系统可以用于将某人锁定在系统之外（假设你按原样使用），除非你要求某人在发出密码重置之前填写可识别信息，或者先发送一封"你确定要重置密码吗？"电子邮件。这将需要他们点击指向服务器的GUID链接；在那一点上，它们也可以被发送到密码重置表单
- 由于密码是通过电子邮件纯文本发送的，因此存在被拦截和密码被使用的危险。尽管公平地说，这与发送密码重置链接的风险没有太大区别
- 如果你忽略了步骤#1中的风险，并且你没有使用足够随机的方式来生成密码（比如你使用的单词列表少于1000个项目），那么入侵你的服务器的人将能够检索到盐水密码哈希，然后编写一个算法来生成所有可能的密码，并将其与哈希密码进行核对。如果你使用密码复杂的哈希算法，问题就不大了
如果您想通过明文形式的电子邮件向用户发送密码，并希望将这些密码以哈希或任何其他格式存储到数据库中。这将是可能的。。。。。。。
只是你必须遵循一些简单的方法。。。。
1.您必须将这些密码作为将从用户发送的变量
2.当您存储数据库时，只需将其转换为您希望的格式即可
3.但当你通过邮件发送给用户时，那次只是发送了那些可变密码。。。
我认为这将有助于建立你对WAY…的概念。。。。。。。