Javascript非对称加密和身份验证

boa*_*cow 3 javascript authentication encryption encryption-asymmetric

这里的一些人正在开发一个应用程序,其中包含一些可通过登录访问的"安全区域".过去,登录表单和随后的"安全"页面都是通过http传输的纯文本,因为它是一个应用程序在没有机会使用SSL的共享服务器上使用(想想WordPress等).大多数人只是耸了耸肩,因为这是他们所期望的 - 它几乎不是国家银行.

我们现在考虑使用JavaScript前端编写下一个版本,其优点是加载所有图像和CSS一次,然后使用extJS(或者jQuery)将HTML写入DOM.我们希望在发送到服务器之前在客户端加密用户输入,然后在呈现给HTML之前在浏览器处解密服务器输出,以便为用户引入某种安全性.减少页面加载时间也有所收获,因为我们只是来回发送gzip压缩包.

在玩游戏时,我们意识到我们正在考虑加密基本内容的方法也首先加倍作为登录的身份验证机制.

为简单起见......:

  • 用户通过标准http连接到登录页面,浏览器下载包含散列和加密算法(例如SHA-256和AES)的JavaScript包.
  • 用户输入username,passwordsecret进入一个登录表单.
  • 该浏览器的JavaScript发送的哈希值username,并password通过AJAX服务器.将secret只存储在JavaScript和在互联网上永远不会发送.
  • 服务器查找哈希usernamesecret从数据库中检索.
  • 服务器发送一个哈希(与浏览器相同的算法)usernamesecret返回浏览器.
  • 该浏览器的JavaScript创建的哈希usernamesecret,并将其与从服务器发回的哈希值.
  • 如果它们是相同的,在浏览器的JavaScript加密responsesecret和发送消息回服务器.
  • 服务器解密消息secret以找到预期response并启动新会话.
  • 随后的通信都是双向加密和解密的secret.

这类系统似乎有一些优点,但我们是否正确思考:

  • 如果服务器设法创建哈希username并且secret证明服务器知道并理解username并且用户知道他们正在与他们的服务器通话secret.
  • 服务器知道用户是真正的,如果他们管理加密responsesecret,证明用户知道secret.
  • 在任何时候都secret不会以纯文本传输,或者是否可以secret从散列中确定.
  • 嗅探器只会查找"安全"URL并检测查询字符串中的压缩哈希值和加密值.如果他们向格式错误的URL发送请求,则不会给出响应.如果他们以某种方式设法猜出一个合适的请求,他们仍然必须能够解密它.

这一切看起来都很快,以至于用户难以察觉.任何人都可以看到这一点,因为我们都假设我们不应该使用JavaScript加密!

Sah*_*hoo 7

不要这样做.请使用SSL/TLS.请参阅Javascript Cryptography Considered Harmful.