这里的一些人正在开发一个应用程序，其中包含一些可通过登录访问的“安全区域”。过去，登录表单和后续的“安全”页面都是通过http传输的纯文本，因为它是一个应用程序，出去在共享服务器上使用，在那里几乎没有机会使用SSL（想想WordPress等）。大多数人只是耸了耸肩，因为这是他们所期望的 - 它几乎不是国家银行。
我们现在正考虑使用JavaScript前端编写下一个版本，其优点是可以加载所有图像＆amp; CSS一次，然后使用extJS（或者jQuery）将HTML写入DOM。我们想在发送到服务器之前在客户端加密用户输入，然后在呈现给HTML之前在浏览器解密服务器输出，以便为用户引入某种安全性。减少页面加载时间也有所收获，因为我们只是来回发送gzip压缩JSON。
在玩游戏时，我们意识到我们正在考虑加密基本内容的方法也首先成为登录的身份验证机制。
为简单起见......：
username，password和secret输入登录表单。username和password的哈希值。 secret仅存储在JavaScript中，不会通过互联网发送。username和secret。username和secret的哈希（与浏览器相同的算法）发送回浏览器。username和secret的哈希值，并将其与服务器发回的哈希值进行比较。response加密secret并将该消息发送回服务器。secret解密邮件以找到预期的response并开始新会话。secret进行加密和解密。这种类型的系统似乎有一些优点，但我们是否正确思考：
username和secret的哈希，则用户知道他们正在与他们的服务器通话，证明服务器知道并了解username和secret response加密secret，则服务器知道该用户是真的，证明用户知道secret。secret在任何时候都没有以纯文本形式传输，或者是否可以从哈希中确定secret。这一切看起来都很快，以至于用户无法察觉。任何人都可以看到这一点，因为我们都假设我们不应该使用JavaScript加密！
答案 0 :(得分：8)
不要这样做。请使用SSL / TLS。请参阅Javascript Cryptography Considered Harmful。
答案 1 :(得分：2)
如果您可以提供单个SSL站点来安全地交付JavaScript（以避免上述攻击），那么您可以使用opensource Forge库在生成自签名证书后提供与其他站点的跨域TLS连接对他们来说如果您选择不同的方向，Forge库还提供其他基本加密功能。 Forge有一个几乎所有JavaScript的XMLHttpRequest包装器，其中一小部分利用Flash的套接字API来实现跨域通信。