javascript - 如何保护客户端上使用的 AES 密码？

Question

我想在这里使用斯坦福的 AES 实现：

http://crypto.stanford.edu/sjcl/

但是，如果我按照他们的建议使用它，它基本上是没用的

SJCL 易于使用：只需运行 sjcl.encrypt("password", "data") 来加密数据，或运行 sjcl.decrypt("password", "encrypted-data")。

由于任何人都可以简单地加载我的网站，因此请查看 java 脚本并使用密码以与我相同的方式解密数据。

我如何使这个解决方案有用？

Answer 1

With a bit more back-and-forth I think I understand what you want to know better enough to give you an answer. Let me know if this is what you were looking for.

In general, managing symmetric keys is very difficult. There are two primary uses for symmetric ciphers:

• Protecting the privacy of stored data for later use by the same person. If you use an online backup service, you really hope that your data is encrypted on the client before being uploaded to the online service -- you do not want them to have access to your data in plaintext. But when you go to decrypt the data in the future, you're the one to supply the key. This means you could store the key on offline media (CD-R, USB memory stick, SD card, little notebook next to the monitor...) or online (browser cookie, OS-supplied keychain of some sort, or standard file...).

• Protecting the privacy of data while in transit between two parties. One party encrypts the data and the other party decrypts the data. This is how spies communicate, how TLS provides HTTPS client-to-server security, how SSH provides client-to-server security. In this case, both parties need to agree to the key that will be used, and this can be done with Diffie-Hellman-Merkle Key Exchange or using a public-key encryption algorithm such as RSA to allow one party to encrypt a randomly-generated session key in a way that it can only be decrypted by the other party.

The library you have found looks like it is highly optimized for the first case -- allowing users to encrypt their data for you to store and then retrieve for them later. Because they use a password based key derivation function it is prepared to handle the poor passwords that are available through simply typing on a keyboard -- the function will allow building safer keys out of just what a human can (or will) type on a keyboard.

Of course, it could be used for the second case, but presumably you're using this in a browser that has full TLS support, which can provide for end-to-end security in case you choose to use both client certificates and server certificates.

If you chose to allow the user to store encrypted data through your software, you should definitely make clear where the decryption key is being stored. I could see a use case for having a cookie on the browser store the key -- so that the user does not need to re-type it when they want their data. But if they change machines or browsers, they'll need to know the password so they can again retrieve their data.

However, if a user thinks their data is "secure", perhaps they should re-type their key every time they want to use their data. That way, the user alone is responsible for the security of the key; browser flaws that allow exposure of cookie data -- or locally-running malicious code -- cannot simply read the key off disk.

The downside of all this, of course, is that there isn't an easy answer available: you have to decide between the simplicity of storing passwords or the safety of not storing passwords.