Html 本地存储可以被认为是安全的吗？

Can local storage ever be considered secure?

提问by user1173706

I'm required to develop a web application that will function offline for long periods. In order for this to be viable I cannot avoid saving sensitive data (personal data but not the kind of data you would only store hashed) in local storage.

我需要开发一个可以长时间脱机运行的 Web 应用程序。为了使其可行，我无法避免在本地存储中保存敏感数据（个人数据，但不是您只能存储散列的数据类型）。

I accept that this is not recommended practice, but given little choice I'm doing the following to secure the data:

我接受这不是推荐的做法，但在没有选择的情况下，我正在执行以下操作来保护数据：

• encyrypting everything going into local storage using the stanford javascript crypto library and AES-256
• the user password is the encryption key and is not stored on the device
• serving all content (when online) from a single trusted server over ssl
• validating all data going to and from local storage on the server using owasp antisamy project
• in the network section of the appcache, not using *, and instead listing only the URIs required for connection with the trusted server
• in general trying to apply the guidelines suggested in the OWASP XSS cheat sheet

• 使用 stanford javascript 加密库和 AES-256 加密进入本地存储的所有内容
• 用户密码是加密密钥，不存储在设备上
• 通过 ssl 从单个可信服务器提供所有内容（在线时）
• 使用 owasp antisamy 项目验证进出服务器本地存储的所有数据
• 在 appcache 的网络部分，不使用 *，而是仅列出与受信任服务器连接所需的 URI
• 通常尝试应用 OWASP XSS 备忘单中建议的指南

I appreciate that the devil is often in the detail, and know there is a lot of scepticism about local storage and javascript-based security in general. Can anyone comment on whether there are:

我很欣赏细节往往是魔鬼，并且知道人们普遍对本地存储和基于 javascript 的安全性持怀疑态度。任何人都可以评论是否有：

• fundamental flaws in the above approach?
• any possible solutions for such flaws?
• any better way to secure local storage when an html 5 application must function offline for long periods?

• 上述方法的根本缺陷是什么？
• 这些缺陷的任何可能的解决方案？
• 当 html 5 应用程序必须长时间脱机运行时，有什么更好的方法来保护本地存储？

Thanks for any help.

谢谢你的帮助。

采纳答案by Brian M. Hunt

WebCrypto

网络加密

The concerns with cryptography in client-side (browser) javascript are detailed below. All but one of these concerns does not apply to the WebCrypto API, which is now reasonably well supported.

下面详细介绍了客户端（浏览器）javascript 中的密码学问题。除了这些问题中的一个之外，所有问题都不适用于WebCrypto API，它现在得到了相当好的支持。

For an offline app, you must still design and implement a secure keystore.

对于离线应用程序，您仍然必须设计和实施安全的密钥库。

Aside: If you are using Node.js, use the builtin cryptoAPI.

旁白：如果您使用 Node.js，请使用内置的加密API。

Native-Javascript Cryptography (pre-WebCrypto)

Native-Javascript Cryptography（pre-WebCrypto）

I presume the primary concern is someone with physical access to the computer reading the localStoragefor your site, and you want cryptography to help prevent that access.

我认为主要问题是有人可以物理访问计算机读取localStorage您的站点，并且您希望加密技术帮助防止这种访问。

If someone has physical access you are also open to attacks other and worse than reading. These include (but are not limited to): keyloggers, offline script modification, local script injection, browser cache poisoning, and DNS redirects. Those attacks only work if the user uses the machine after it has been compromised. Nevertheless, physical access in such a scenario means you have bigger problems.

如果有人可以进行物理访问，那么您也容易受到比阅读更糟糕的攻击。这些包括（但不限于）：键盘记录器、离线脚本修改、本地脚本注入、浏览器缓存中毒和 DNS 重定向。只有当用户在机器受到威胁后使用机器时，这些攻击才有效。然而，在这种情况下的物理访问意味着你有更大的问题。

So keep in mind that the limited scenario where local crypto is valuable would be if the machine is stolen.

因此请记住，本地加密有价值的有限情况是机器被盗。

There are libraries that do implement the desired functionality, e.g. Stanford Javascript Crypto Library. There are inherent weaknesses, though (as referred to in the link from @ircmaxell's answer):

有些库确实实现了所需的功能，例如Stanford Javascript Crypto Library。但是，存在固有的弱点（如@ircmaxell 回答中的链接所述）：

1. Lack of entropy / random number generation;
2. Lack of a secure keystore i.e. the private key must be password-protected if stored locally, or stored on the server (which bars offline access);
3. Lack of secure-erase;
4. Lack of timing characteristics.

1. 缺乏熵/随机数生成；
2. 缺乏安全的密钥库，即如果存储在本地或存储在服务器上（禁止离线访问），则私钥必须受密码保护；
3. 缺乏安全擦除；
4. 缺乏时序特性。

Each of these weaknesses corresponds with a category of cryptographic compromise. In other words, while you may have "crypto" by name, it will be well below the rigour one aspires to in practice.

这些弱点中的每一个都对应于一类密码泄露。换句话说，虽然你可能有“加密”的名字，但它远低于人们在实践中所追求的严谨性。

All that being said, the actuarial assessment is not as trivial as "Javascript crypto is weak, do not use it". This is not an endorsement, strictly a caveat and it requires you to completely understand the exposure of the above weaknesses, the frequency and cost of the vectors you face, and your capacity for mitigation or insurance in the event of failure: Javascript crypto, in spite of its weaknesses, may reduce your exposure but only against thieves with limited technical capacity. However, you should presume Javascript crypto has no value against a determined and capable attacker who is targeting that information. Some would consider it misleading to call the data "encrypted" when so many weaknesses are known to be inherent to the implementation. In other words, you can marginally decrease your technical exposure but you increase your financial exposure from disclosure. Each situation is different, of course - and the analysis of reducing the technical exposure to financial exposure is non-trivial. Here is an illustrative analogy: Some banks require weak passwords, in spite of the inherent risk, because their exposure to losses from weak passwords is less than the end-user costs of supporting strong passwords.

尽管如此，精算评估并不像“Javascript 加密很弱，不要使用它”那样微不足道。这不是背书，严格来说是警告，它要求您完全了解上述弱点的暴露情况、您面临的向量的频率和成本，以及您在发生故障时的缓解或保险能力：Javascript 加密，在尽管它有弱点，但可能会减少您的曝光率，但只能对抗技术能力有限的盗贼。但是，您应该假设 Javascript 加密对于以该信息为目标的坚定而有能力的攻击者没有价值。有些人会认为，当已知实施中存在如此多的弱点时，将数据称为“加密”是一种误导。换句话说，您可以略微减少您的技术风险，但您会因披露而增加您的财务风险。当然，每种情况都是不同的——减少技术风险对金融风险的分析是不平凡的。这是一个说明性的类比：尽管存在固有风险，但一些银行仍需要弱密码，因为它们因弱密码而遭受的损失低于支持强密码的最终用户成本。

If you read the last paragraph and thought "Some guy on the Internet named Brian says I can use Javascript crypto", do not use Javascript crypto.

如果您阅读最后一段并认为“互联网上有个叫 Brian 的人说我可以使用 Javascript 加密”，请不要使用 Javascript 加密。

For the use case described in the question it would seem to make more sense for users to encrypt their local partition or home directory and use a strong password. That type of security is generally well tested, widely trusted, and commonly available.

对于问题中描述的用例，用户加密其本地分区或主目录并使用强密码似乎更有意义。这种类型的安全性通常经过充分测试、广泛信任且普遍可用。

回答by ircmaxell

Well, the basic premise here is: no, it is not secure yet.

嗯，这里的基本前提是：不，它还不安全。

Basically, you can't run crypto in JavaScript: JavaScript Crypto Considered Harmful.

基本上，您不能在 JavaScript 中运行加密：JavaScript Crypto Considered Harmful。

The problem is that you can't reliably get the crypto code into the browser, and even if you could, JS isn't designed to let you run it securely. So until browsers have a cryptographic container (which Encrypted Media Extensions provide, but are being rallied against for their DRM purposes), it will not be possible to do securely.

问题是您无法可靠地将加密代码输入浏览器，即使可以，JS 也不是为了让您安全地运行它而设计的。因此，除非浏览器拥有加密容器（加密媒体扩展提供，但由于其 DRM 目的而遭到反对），否则不可能安全地进行。

As far as a "Better way", there isn't one right now. Your only alternative is to store the data in plain text, and hope for the best. Or don't store the information at all. Either way.

至于“更好的方法”，现在还没有。您唯一的选择是以纯文本形式存储数据，并希望最好。或者根本不存储信息。无论哪种方式。

Either that, or if you needthat sort of security, and you need local storage, create a custom application...

或者，或者如果您需要那种安全性，并且需要本地存储，请创建自定义应用程序...

回答by Kevin Hakanson

As an exploration of this topic, I have a presentation titled "Securing TodoMVC Using the Web Cryptography API" (video, code).

作为对这个主题的探索，我有一个标题为“使用 Web 加密 API 保护 TodoMVC”的演示文稿（视频、代码）。

It uses the Web Cryptography APIto store the todo list encrypted in localStorage by password protecting the application and using a password derived key for encryption. If you forget or lose the password, there is no recovery. (Disclaimer - it was a POC and not intended for production use.)

它使用Web Cryptography API通过密码保护应用程序并使用密码派生密钥进行加密来存储在 localStorage 中加密的待办事项列表。如果您忘记或丢失密码，则无法恢复。（免责声明 - 这是一个 POC，不用于生产用途。）

As the other answers state, this is still susceptible to XSS or malware installed on the client computer. However, any sensitive data would also be in memory when the data is stored on the server and the application is in use. I suggest that offline support may be the compelling use case.

正如其他答案所述，这仍然容易受到客户端计算机上安装的 XSS 或恶意软件的影响。但是，当数据存储在服务器上并且应用程序正在使用时，任何敏感数据也将在内存中。我建议离线支持可能是引人注目的用例。

In the end, encrypting localStorage probably only protects the data from attackers that have read only access to the system or its backups. It adds a small amount of defense in depth for OWASP Top 10 item A6-Sensitive Data Exposure, and allows you to answer "Is any of this data stored in clear text long term?" correctly.

最后，加密 localStorage 可能只会保护数据免受对系统或其备份具有只读访问权限的攻击者的攻击。它为 OWASP Top 10 项目A6-Sensitive Data Exposure增加了少量的纵深防御，并允许您回答“这些数据中是否有任何长期以明文形式存储？” 正确。

回答by Paul S

This is a really interesting article here. I'm considering implementing JS encryption for offering security when using local storage. It's absolutely clear that this will only offer protection if the device is stolen (and is implemented correctly). It won't offer protection against keyloggers etc. However this is not a JS issue as the keylogger threat is a problem of all applications, regardless of their execution platform (browser, native). As to the article "JavaScript Crypto Considered Harmful" referenced in the first answer, I have one criticism; it states "You could use SSL/TLS to solve this problem, but that's expensive and complicated". I think this is a very ambitious claim (and possibly rather biased). Yes, SSL has a cost, but if you look at the cost of developing native applications for multiple OS, rather than web-based due to this issue alone, the cost of SSL becomes insignificant.

这是一篇非常有趣的文章。我正在考虑实施 JS 加密以在使用本地存储时提供安全性。很明显，这只会在设备被盗（并正确实施）时提供保护。它不会提供针对键盘记录器等的保护。然而，这不是 JS 问题，因为键盘记录器威胁是所有应用程序的问题，无论它们的执行平台（浏览器、本机）如何。对于第一个答案中引用的文章“JavaScript Crypto Considered Harmful”，我有一个批评；它指出“您可以使用 SSL/TLS 来解决这个问题，但这既昂贵又复杂”。我认为这是一个非常雄心勃勃的主张（并且可能相当有偏见）。是的，SSL 是有成本的，

My conclusion - There is a place for client-side encryption code, however as with all applications the developers must recognise it's limitations and implement if suitable for their needs, and ensuring there are ways of mitigating it's risks.

我的结论 - 客户端加密代码有一席之地，但是与所有应用程序一样，开发人员必须认识到它的局限性并在适合他们的需求时实施，并确保有减轻其风险的方法。

回答by rockmo

Not accessible to any webpage (true) but is easily accessible and easily editible via dev tools, such as chrome (ctl-shift-J). Therefore, custom crypto required before storing the value.

任何网页都无法访问（真实），但可以通过开发工具轻松访问和编辑，例如 chrome (ctl-shift-J)。因此，在存储值之前需要自定义加密。

But, if javascript needs to decrypt (to validate) then the decrypt algorithm is exposed and can be manipulated.

但是，如果 javascript 需要解密（验证），那么解密算法就会暴露出来并且可以被操纵。

Javascript needs a fully secure container and the ability to properly implement private variables and functions that are available only to the js interpreter. But, this violates user security - since tracking data can be used with impunity.

Javascript 需要一个完全安全的容器，并能够正确实现仅对 js 解释器可用的私有变量和函数。但是，这违反了用户安全——因为跟踪数据可以不受惩罚地使用。

Consequently, javascript will never be fully secure.

因此，javascript 永远不会完全安全。

回答by hellol11

No.

不。

localStorage is accessible by any webpage, and if you have the key, you can change whatever data you want.

localStorage 可以通过任何网页访问，如果您有密钥，您可以更改您想要的任何数据。

That being said, if you can devise a way to safely encrypt the keys, it doesn't matter how you transfer the data, if you can contain the data within a closure, then the data is (somewhat) safe.

话虽如此，如果您可以设计出一种安全加密密钥的方法，那么您如何传输数据并不重要，如果您可以将数据包含在一个闭包中，那么数据就是（在某种程度上）安全的。