这里的一些人正在开发一个应用程序，其中包含一些可通过登录访问的“安全区域”。在过去，登录表单和后续的“安全”页面都是通过 http 传输的纯文本，因为它是一个用于访问的应用程序。在几乎不可能使用 SSL 的共享服务器上使用（例如 WordPress 等）。大多数人只是耸耸肩，因为这就是他们所期望的——这根本不是一家国家银行。
我们现在正在考虑使用 JavaScript 前端编写下一个版本，其优点是一次性加载所有图像和 CSS，然后使用 extJS（或者可能是 jQuery）将 HTML 写入 DOM。我们希望在将用户输入发送到服务器之前对客户端的用户输入进行加密，然后在将服务器输出呈现为 HTML 之前在浏览器上解密，以便为用户引入某种安全性。减少页面加载时间也有好处，因为我们只来回发送 gzip 压缩的 JSON。
在尝试过程中，我们意识到我们正在寻找的加密基本内容的方法首先也可以作为登录的身份验证机制。
为简单起见...：
- 用户通过标准 http 连接到登录页面，浏览器在其中下载包含哈希和加密算法（例如 SHA-256 和 AES）的 JavaScript 包。
- 用户输入
username, password and secret进入登录表单。
- 浏览器 JavaScript 发送一个哈希值
username and password通过 AJAX 发送到服务器。这secret仅存储在 JavaScript 中，并且永远不会通过互联网发送。
- 服务器查找哈希并检索
username and secret从数据库中。
- 服务器发送一个哈希值（与浏览器相同的算法）
username and secret返回浏览器。
- 浏览器 JavaScript 创建一个哈希值
username and secret并将其与从服务器发回的哈希值进行比较。
- 如果相同，浏览器 JavaScript 会加密
response with secret并将消息发送回服务器。
- 服务器解密消息
secret来找到预期的response并开始一个新的会话。
- 后续通信均通过以下方式进行加密和解密
secret.
这种类型的系统似乎有一些优点，但我们的想法是否正确：
- 如果服务器设法创建以下内容的哈希值，则用户知道他们正在与服务器通信
username and secret，证明服务器知道并理解username and secret.
- 如果用户成功加密，服务器就知道用户是真实的
response with secret，证明用户知道secret.
- 任何时候都不是
secret曾经以纯文本形式传输过，或者是否可以确定secret来自哈希值。
- 嗅探器只会找出“安全”URL 并检测查询字符串中的压缩散列和加密。如果他们向格式错误的 URL 发送请求，则不会给出任何响应。如果他们以某种方式设法猜测适当的请求，他们仍然必须能够解密它。
这一切看起来足够快，以至于用户无法察觉。任何人都可以看穿这一点，因为我们都认为我们不应该玩 JavaScript 加密！
不要这样做。请使用 SSL/TLS。看Javascript 密码学被认为是有害的.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
