-1

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

  • 如果我通过发送密码，https他是否被我的公钥加密？
  • 如果是这样的话，我可以在我的 https 请求中完美地传输我想要的内容而不必担心吗？这是一个好习惯吗？
  • 实际上我像这样使用jwt，可以吗？：
    • 用户提供用户名和密码
    • 我的前台https使用用户名和密码（纯文本）发出帖子请求
    • 我的背部检查用户是否存在
    • 如果是这种情况，我的背部会bcrypt.compare影响用户提供的纯文本密码和数据库提供的加密密码
    • 如果可以的话，我回来发一个 jwt
  • 在我的虚拟主机中进行简单http的https重定向就足以避免明文传输？
4

1 回答 1

1

HTTPS 不是灵丹妙药，或者更准确地说，它不是与您的问题相关的 TLS 部分。

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

所以，如果一切都是正确的，那么是的，通过 HTTPS 发送（或接收）的所有内容都是加密的，无论是密码、令牌、文本等。不是通过“你的公钥”，因为事情比这更复杂，但总结一下：在握手开始时使用证书来提供身份验证，之后计算一些会话密钥并将用于加密任何交换的数据。

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

然后，您似乎将传输中的安全性与静态安全性混合在一起：您可以使用 HTTPS 交换密码，它在传输过程中被加密，太好了。但是当它到达远端时，遥控器用它做什么呢？它是仅将其用于计算然后将其丢弃还是将其存储在其他地方？如果它必须存储密码，那么你需要安全性：一种存储密码的方法，这样即使有人设法访问它，他们也无法返回真正的纯文本密码。你如何做到这一点取决于密码的使用，但如果它是为了经典的身份验证需求，你确实必须关注 bcrypt/scrypt/argon 以及更普遍的称为 PBKDF2 的东西。不要听人说你只需要对密码进行哈希处理，问题远不止于此。

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

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

于 2019-09-19T19:50:56.427 回答