Javascript非对称加密和认证 [英] Javascript asymmetric encryption and authentication

问题描述

这里的一些人正在开发一个应用程序，其中包含可以通过登录访问的一些安全区域。以前，登录表单和随后的安全页面都是通过http传输的纯文本，因为它是一个应用程序出来在共享服务器上使用，几乎没有机会使用SSL（认为WordPress等）。大多数人只是耸耸肩，就像他们所期望的那样 - 它几乎不是一个国家银行。

我们正在考虑用JavaScript前端编写下一个版本，加载所有图像的优点& CSS一次，然后用extJS（或者jQuery）将HTML写入DOM。我们希望在发送到服务器之前加密客户端的用户输入，然后在浏览器之前解密服务器输出，然后再呈现给HTML，以便为用户引入某种安全性。还有减少页面加载时间的好处，因为我们只是来回发送gzip JSON。

在玩耍时，我们意识到我们正在寻找加密基本的东西也加倍了身份验证机制，首先登录。

为了简单...：

• 用户通过标准http连接到登录页面，浏览器下载包含散列和加密算法（例如SHA-256和AES）的JavaScript包。 / li>
  
• 用户输入用户名，密码和 secret 进入登录表单。


• 浏览器JavaScript发送一个用户名和密码通过AJAX到服务器。 秘密仅存储在JavaScript中，不会通过互联网发送。


• 服务器查找散列并检索用户名和秘密。


• 服务器发送一个哈希（相同的算法，浏览器） username 和 secret 返回浏览器。


• 浏览器JavaScript创建一个 username 和 secret 的哈希值，并将其与从服务器发回的哈希进行比较。 >
  
• 如果它们相同，浏览器JavaScript会使用 secret 加密响应，并发送


• 服务器使用 secret 解密邮件，以查找预期的响应并启动一个新的会话。


• 随后的通信使用密钥加密和解密。

这种类型的系统似乎有一些优点，b我们正确的思考：

• 如果服务器设法创建一个<$ c的哈希值，用户知道他们正在与他们的服务器通话$ c>用户名和秘密，证明服务器了解并了解 username 和 secret 。


• 服务器知道用户是正确的，如果他们设法加密响应 秘密，证明用户知道秘密。


• 秘密以纯文本形式发送，或者可以从散列中确定 secret 。


• 嗅探器只会找到安全URL，并在查询字符串中检测压缩散列和加密。如果他们向网址发送了一个请求，这个URL格式不正确，那么没有给出任何响应。如果他们以某种方式设法猜到一个适当的请求，他们仍然必须能够解密它。

对用户不了解。任何人都可以看到这一点，因为我们都假设我们不应该使用JavaScript加密！

解决方案

不要这个。请使用SSL / TLS。请参阅 JavaScript加密认证有害的。

Some of the guys here are developing an application which incorporates some 'secure areas' accessible by logging in. In the past, the login form and subsequent 'secure' pages were all plain text transmitted over http, as it's an application that goes out for use on shared servers where there is little chance of being able to use SSL (think WordPress and the like). Most people just shrugged their shoulders as that's all they expected - it's hardly a national bank.

We are now thinking of writing the next version using a JavaScript front end, with the advantage of loading all the images & CSS once, then writing HTML into the DOM thereafter with extJS (or maybe jQuery). We'd like to encrypt user input at the client before being sent to the server, then decrypt server output at the browser before being rendered to HTML so as to introduce some sort of security for users. There are also gains to be had with reducing page loading times, as we're only sending gzipped JSON back and forth.

While playing around, we realised that the method we were looking at to encrypt the basic stuff also doubled up as an authentication mechanism for login in the first place.

For simplicity...:

• The user connects to the login page over standard http, where the browser downloads the JavaScript package containing the hashing and encryption algorithms (SHA-256 and AES for example).
• User enters username, password and secret into a login form.
• The browser JavaScript sends a hash of username and password to the server via AJAX. The secret is only stored in JavaScript and is never sent across the internet.
• The server looks up the hash and retrieves username and secret from the database.
• The server sends a hash (same algorithm as the browser) of username and secret back to the browser.
• The browser JavaScript creates a hash of username and secret and compares it to the hash sent back from the server.
• If they are the same, the browser JavaScript encrypts response with secret and sends the message back to the server.
• The server decrypts the message with secret to find the expected response and starts a new session.
• Subsequent communications are encrypted and decrypted both ways with secret.

There seem to be a few advantages of this type of system, but are we right in thinking:

• The user knows they are talking to their server if the server manages to create a hash of username and secret, proving the server knows and understands username and secret.
• The server knows the user is genuine if they manage to encrypt response with secret, proving the user knows secret.
• At no time is secret ever transmitted in plain text, or is it possible to determine secret from the hash.
• A sniffer will only ever find out the 'secure' URL and detect compressed hashes and encryptions in the query string. If they send a request to to the URL that is malformed, no response is given. If they somehow manage to guess an appropriate request, they still have to be able to decrypt it.

It all seems quick enough as to be imperceptible to the user. Can anyone see through this, as we all just assumed we shouldn't be playing with JavaScript encryption!

解决方案

Don't do this. Please use SSL/TLS. See Javascript Cryptography Considered Harmful.

这篇关于Javascript非对称加密和认证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！