我刚刚读到有关 Stanford Javascript Crypto Library 的信息( jsfiddle example ) 完全支持 javascript 中的 SHA256、AES 和其他标准加密方案。该库看起来非常漂亮，但我不知道它的合理用例。
作为some questions已经指出，客户端加密不是将安全数据传递到服务器的安全方式。应该改用 HTTPS。那么，是否有任何项目会受益于或需要客户端加密？
最佳答案
用例 1
local storage怎么样？ ？您可能想要存储一些数据，但对其进行加密以使计算机的其他用户无法访问它？
例如:
- 用户通过 HTTPS 连接到服务器。
- 服务器对用户进行身份验证。
- 服务器提供一个特定于该用户的加密密码。
- 用户在本地做一些事情。
- 一些数据存储在本地(使用密码加密)。
- 用户走失
- 用户稍后会返回网站。
- 用户通过 HTTPS 连接。
- 服务器对用户进行身份验证。
- 服务器提供用户的加密密码。
- 客户端JS使用加密密码解密本地数据。
- 用户使用他们现在已解密的内存中本地数据在本地执行某些操作。
如果您有一个胖客户端，需要跨 session 使用大量(敏感)数据，并且由于大小而无法从服务器提供数据，这可能很有用。我想不出有多少这种情况适用...
在应用程序的用户生成敏感数据并且不需要(或不应)将数据发送到(或存储在)服务器上的情况下，它也很有用。
举一个应用示例，您可以将用户的信用卡详细信息存储在本地，加密并使用 JS 将其自动输入到表单中。您可以通过存储数据服务器端并以这种方式提供预先填充的表格来完成此操作，但是使用这种方法您不必将他们的信用卡详细信息存储在服务器上(在某些国家/地区，有严格的有关的法律)。显然，关于在用户机器上加密存储信用卡详细信息是否比在服务器端存储更多或更少的安全风险存在争议。
很可能有一个更好的应用示例...
我不知道有任何现有项目使用这种技术。
用例 2
如何通过密码共享促进 HTTPS 的性能提升？
例如:
- 用户通过 HTTPS 连接到服务器。
- 服务器对用户进行身份验证。
- 服务器提供一个特定于该用户的加密密码。
- 然后服务器重定向到 HTTP(其开销比 HTTPS 少得多，因此在性能方面会好得多)。
- 因为服务器和客户端都有加密密码(并且该密码是通过安全连接共享的)，所以它们现在可以发送和接收安全加密的敏感数据，而无需使用 HTTPS 加密/解密整个请求的开销。这意味着服务器可以提供一个网页，其中只有敏感部分被加密。然后客户端可以解密加密部分。
这个用例可能不是那么值得，因为 HTTPS 通常具有可接受的性能水平，但如果您需要提高一点速度，它会有所帮助。
用例 3
Host proof storage .您可以加密数据客户端，然后将其发送到服务器。服务器可以存储数据并共享数据，但在不知道客户端私钥的情况下无法解密。这被认为是 lastpass 等服务的基础.
关于javascript - 客户端加密的有效用例是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7123511/