Ssl 需要确认https、jwt和bcrypt的安全性

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

如果我通过https发送密码，他是否用我的公钥加密？ 如果是这样的话，我能在https请求中清楚地传输我想要的内容而不必担心吗？这是一种好的做法吗？ 实际上我是这样使用jwt的，可以吗 用户提供用户名和密码 my front使用用户名和密码明文发出https post请求 我的后台检查用户是否存在 如果是这种情况，我的背部会做一个bcrypt.compare，将用户提供的纯文本密码与数据库提供的加密密码进行比较 如果可以的话，我的背部会发一个jwt 在我的virtualhost中，一个简单的http到https重定向足以避免明文传输吗？

---

HTTPS不是银弹，或者更准确地说，它的TLS部分与您的问题相关

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

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

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

然后，您似乎将传输中的安全性与静止时的安全性混为一谈：您可以使用HTTPS交换密码，它在传输过程中是加密的，非常好。但当它到达远程端时，远程端对它做了什么？它是将其仅用于计算，然后将其丢弃，还是将其存储在其他位置？如果它必须存储密码，那么您需要静态安全性：一种存储密码的方法，这样即使有人设法访问它，他们也无法返回到真正的纯文本密码。如何做到这一点取决于密码的使用方式，但如果密码是用于传统身份验证需求，则必须考虑bcrypt/scrypt/argon，更一般地说，就是所谓的PBKDF2。不要听别人说你只需要对密码进行哈希运算，问题更大

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

---

所以很明显，这不是我们要做的事。现在你甚至可以完全抛弃HTTP，只监听HTTPS，特别是对于应用程序到应用程序的通信，不需要维护HTTP侦听器。

我不会将HTTP重定向到HTTPS。最好让请求失败，以便客户机识别使用了错误的协议。请记住，第一个http请求可能已经包含密码，因此重定向它为时已晚，因为密码当时已经以纯文本传输；客户端需要在每次握手开始时进行验证。例如，如果我通过certbot拥有一个https域，它是单独完成的吗？在我的文化中，有没有办法确保这种验证？为了安全起见，我在注册用户时使用bcrypt。任何好的TLS库，希望使用sane默认值，或者至少不使用显式参数调用，以降低安全性，都将通过证书交换处理TLS握手，客户端将检查服务器证书及其内部元数据，如日期，其签名、发行人是谁等。。您可以很容易地测试您的客户机：更改服务器证书，包括一个有效但另一个主机名，并仔细检查客户机部分是否确实检测到问题并阻止访问。