我正在设计一个 REST API，但我在验证用户的安全性方面遇到了一些问题。 对于身份验证，我不希望密码以纯文本形式通过网络发送。
为了绕过这个问题，我可以发送密码的 SHA-256 哈希值(用户名作为 salt)，因此密码永远不会以纯文本形式发送。在我的数据库中，我将存储以下哈希值:SHA256(密码 + 盐)，我将比较这两个哈希值是否匹配。
此选项的问题是我将使用快速散列算法计算散列并且盐不是随机的。
在安全方面，最佳做法是使用慢速签名算法和随机盐(如 bcrypt)。
缓慢的算法不是问题，我可以在客户端使用 bcrypt，但对于盐我不知道该怎么做:
- Bcrypt 需要一个定义大小的盐，所以我不能输入用户名
- 如果我使用随机盐，客户端如何在计算密码的哈希值之前知道该盐的值？
所以我可以看到 3 个选项，但没有一个是令人满意的:
- 我以纯文本形式发送密码(我使用的是 SSL)并将 bcrypt 存储在数据库中 => 仍然容易受到中间人的攻击
- 我使用 SHA256 并发送哈希值，其中盐是用户名(仍在使用 SSL)=> 数据库中的哈希值不太安全
- 我使用 bcrypt，我有一个两步过程:我要求给定用户的盐，然后发送该用户的哈希值(仍在使用 ssl)=> 通过尝试使用其他用户名登录，我可以获得他的盐，不太好
有人有更好的解决方案或建议吗？
最佳答案
我认为您可能会混淆/混淆这里的一些问题:
- 如果您将散列(密码 + 用户名)存储在服务器上，并且身份验证涉及发送散列(密码 + 用户名)，那么除了将密码存储在服务器上之外，您还没有真正取得更好的效果。仅长期存储哈希值的目的是，如果发生数据泄露(即攻击者获得了对数据库的访问权限)，他们仍然无法生成正确的值来进行身份验证。但如果你只是做一个简单的比较，这仍然是一个问题。
- hashing+salting 的正确用法是:(1) 服务器存储 (Salt, hash(Password + Salt) 的元组；(2) 用户发送 (claimed Password)；(3) 服务器计算 hash(claimed Password + Salt ); (4) if hash(claimed Password + Salt) == hash(Password + Salt), then they're authentic. 这样，即使攻击者获得了数据库的访问权，他们也无法产生声称的密码这样哈希(声称的密码+盐)是有效的。
- 通过 SSL 发送明文密码不是“明文”。根据@NullUserException 的评论，除非攻击者破坏了 SSL。只有服务器才能获得密码的值(假设服务器的公钥有效，这完全是另一回事)。
希望这对您有所帮助!
关于php - 为 rest api 传输用户密码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13052424/