ssl - 需要使用 https、jwt 和 bcrypt 确认安全性

Question

我对登录/身份验证应用程序的安全性有一些疑问:

• 如果我通过 https 发送密码，他会用我的公钥加密吗？
• 如果是这样，我可以在我的 https 请求中完美地清楚地传输我想要的内容而不用担心吗？这是一个好的做法吗？
• 实际上我是这样使用 jwt 的，可以吗？ :
  • 用户提供用户名和密码
  • 我的前台使用用户名和密码(纯文本)发出一个https post 请求
  • 我后台检查用户是否存在
  • 如果是这种情况，我会生成一个bcrypt.compare，其中包含用户提供的纯文本密码和数据库提供的加密密码
  • 如果可以，我的后台会发送一个 jwt
• 在我的虚拟主机中一个简单的 http 到 https 重定向就足以避免明文传输吗？

Answer 1

HTTPS 不是 Elixir ，更准确地说，它不是与您的问题相关的 TLS 部分。

从某种意义上说，它需要正确配置和部署。

因此，如果一切正常，那么是的，通过 HTTPS 发送(或接收)的所有内容都是加密的，无论是密码、 token 、文本等。不是通过“您的公钥”，因为事情更多比这更复杂，但总而言之:证书在握手开始时用于提供身份验证，之后计算一些 session key 并将用于加密任何交换的数据。

但它必须正确配置:HTTPS 服务器需要有一个适当的有效证书并且客户端需要在每次握手开始时验证它。这通常是当事情开始分崩离析时，就好像它没有正确完成(或者更糟:你只是不验证远程证书并接受任何证书)你基本上是在将一些东西加密到一个未知的(不保证)远程，所以实际上失去了所有TLS 的有用属性。

那么您似乎在混合传输安全性和静态安全性:您可以使用 HTTPS 交换密码，它在传输过程中被加密，太棒了。但是当它到达远端时， Remote 会用它做什么呢？它只是将它用于计算然后丢弃它还是将它存储在其他地方？如果它必须存储密码，那么您需要静态安全:一种存储密码的方法，这样即使有人设法访问它，他们也无法返回到真正的纯文本密码。你如何做到这一点取决于使用什么密码，但如果它是用于经典身份验证需求，那么你确实必须寻找 bcrypt/scrypt/argon 以及更一般的所谓 PBKDF2。不要听别人说你只需要散列密码，问题远不止于此。

至于“我的虚拟主机中的一个简单的 http 到 https 重定向是否足以避免明文传输？”可能不是，但你的问题缺乏细节。客户端必须在知道它是重定向之前发送其查询。如果在查询中某些有效负载中已经包含敏感信息，那么这将以纯文本形式发送，然后在切换到 HTTPS 时可能再次加密。

所以显然不是什么可以做的。如今，您甚至可以完全放弃 HTTP，只监听 HTTPS，特别是如果它用于应用程序到应用程序的流量，则无需维护 HTTP 监听器。