使用JavaScript对密码进行非对称加密是否可行？

我想使用JavaScript加密用户登录时的密码和用户名（使用Ajax）。我知道存在几个用于JavaScript的非对称加密库。这是安全通信密码的可行策略吗

---

我知道SSL存在，但这不是问题所在。

否。如果攻击者获得密码或加密密码，两者都会“未加密”发送到服务器，那么加密密码可以用于登录

---

JavaScript不能用于安全性。您必须使用HTTPS。

我认为这样做不会给您带来太多好处，当然不会比一段数学密集型JavaScript所带来的性能损失更大。如果您在通过HTTP将数据发送到服务器之前使用此功能对数据进行加密，那么虽然您可以保护黑客不被发现密码的确切内容，但您不会通过简单地对您发送的加密数据进行重播攻击来阻止他们访问

---

保护表单提交的唯一可行方法是使用HTTPS。我知道设置HTTPS很麻烦，因为证书只能在一个域中工作，等等，但是如果信息真的很关键，那么它比尝试用JavaScript进行加密更好

此模型仍然存在问题，因为您仍然只是通过连接传递文本。在加密/解密/比较过程中，如果没有某种日期度量，最终仍然可能发生重播攻击

---

即使在中间人攻击仍然盛行的情况下，您仍然可以知道加密和公钥算法仍然存在。如果有人获得了一个加密密码，那么他们就会有一个永久的来源，从中可以同样轻松地强制使用该密码。

第一步：不要信任互联网上的人，我将提出一个弱算法，以确保我可以破解它

第二步：在获得计算机安全博士学位之前，不要设计自己的算法，或者在生产系统中实现其他人的算法

加密不足以防止重播攻击，如果攻击者获得加密密码，则它对他们的作用与未加密密码（如果足以进行身份验证）一样大

我建议：

用户在那里输入密码

客户端从服务器请求令牌

服务器返回一个唯一的随机令牌，并根据用户会话存储该令牌（由存储在服务器上的cookie设置密钥）

客户端使用您的公钥加密密码+令牌，并将其传递给服务器

服务器使用您的私钥对此进行解密，并检查令牌是否与此会话匹配，之前未使用过，并且不早于30秒

服务器检查密码的哈希值是否与存储在数据存储中的用户密码的哈希值匹配

传输的所有数据仍然可见，因此用户将不会获得任何隐私（就像在https中一样）。您的加密算法、加密实现和公钥将是公开的。这是当前大量密码的情况，大量算法都是为了安全而设计的，攻击者知道这一点

这不会防止任何键盘记录器或间谍软件攻击，因为它们会在密码加密之前锁定目标

---

我不知道在javascript中实现的非对称加密的实现，但这种方法从根本上讲没有什么不安全的地方。

您可以使用诸如的算法来提供您知道密码的零知识证明。窃听者将无法使用此复制您的登录。但是，请注意，如果有主动攻击者将Javascript代码替换为直接向其传输密码的代码，则会引起攻击

SRP有几种Javascript实现：

---

如果你是从非认证通信开始的，你总是处于中间人的危险之中

无论如何，传输加密和哈希密码总是比传输普通密码好。因为您的登录系统可能很弱，但至少您没有共享用户密码（可以与其他系统共享，可能用于银行帐户）

另外，不要存储该值，而是再次对其进行salt和hash处理

---

如果您还使用非对称加密，则可以增加对窃听的保护。不过，这也不是针对中间人。

谢谢你的校对，迈克尔·彼得罗塔；我猜我的拼写检查器毕竟没有打开：）你为什么不直接使用HTTPS？@Alin Purcaru:Question updated你可以免费获得一个自签名SSL证书。还有一个可怕的例子：（见source；yuk，它甚至不接受超过8字节的密码）。如果加密算法是用私有化的方法保存的呢？为什么一定是这样？如果我安装了一个SHA1库（像这样：），并且只通过网络发送密码散列，会怎么样？如果这是不安全的，那么在数据库中存储SHA1散列不是不安全吗？@Greg Agnew:不管你如何分类它。必须在用户的客户端计算机上使用加密算法。这意味着它是公开可读的。即使您通过混淆过程发送方法，您也无法停止该操作。@Zach Rattner-如果该方法接受已哈希的密码并将其与数据库中的密码进行比较，则该方法容易受到重播攻击。在数据库中存储散列并不是不安全的，因为输入是经过散列处理的，然后进行比较。在OPs情况下，哈希值按原样接受并进行比较。@扎克·拉特纳：如果您每次都向服务器传递相同的令牌，那么攻击者是否拥有您的密码并不重要