本地存储可以被认为是安全的吗？ [英] Can local storage ever be considered secure?

问题描述

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

我接受这不是建议的做法，但给出了一些选择，我正在执行以下操作来保护数据：

• 使用stanford javascript加密库和AES-256加密所有进入本地存储的内容


• 用户密码是加密密钥，不存储在设备


• 通过ssl从单个受信任服务器提供所有内容（当联机时）


• 验证服务器本地存储器上的所有数据和本地存储器上的所有数据在appcache的网络部分使用owasp antisamy项目


• ，而不是使用*，而只列出与可信任服务器连接所需的URI


• 通常尝试应用OWASP XSS备忘单中建议的准则

我明白魔鬼经常是细节的，一般来说，对本地存储和基于JavaScript的安全性有很多怀疑。任何人都可以评论是否存在：

• 上述方法的基本缺陷？
  
• 任何可能的解决这些瑕疵问题？


• 当html5应用程序必须长时间脱机时才能保护本地存储的更好方法

感谢您的帮助。

解决方案

我认为主要关注的是有物理访问权限的人计算机读取您网站的 localStorage ，并且您希望加密技术有助于阻止该访问。

如果有人有身体访问你也可以接受其他攻击，比阅读更糟糕。这些包括（但不限于）：键盘记录器，脱机脚本修改，本地脚本注入，浏览器缓存中毒和DNS重定向。这些攻击仅在用户使用机器受到攻击后才起作用。尽管如此，在这种情况下的物理访问意味着你有更大的问题。所以请记住，如果机器被盗，局部密码有价值的有限情况就是。

有些库可以实现所需的功能，例如斯坦福大学JavaScript加密库。然而，有一些固有的弱点（如@ ircmaxell的回答中提到的那样）：

1. 缺少熵/随机数生成;


2. 缺少安全密钥库，即私钥必须受密码保护，如果存储在本地，或存储在服务器上（禁止离线访问）;


3. 缺乏安全擦除;


4. 缺乏时间特征。

这些弱点中的每一个对应于一类加密折衷。换句话说，虽然你可能有名字的加密，但它会远低于你在实践中所渴望的严格性。

这些问题可能会在 WebCrypto API ，但现在还没有。

所有这一切，精算评估并不像Javascript加密弱，不使用它那样微不足道。这不是一种认可，绝对是一个警告，它需要你完全理解上述弱点的暴露，你所面临媒介的频率和成本，以及你在失败时缓解或保险的能力：Javascript crypto，in尽管它的弱点，可能会减少你的曝光度，但只能对付技术能力有限的盗贼。但是，您应该假定Javascript加密对于定位该信息的坚定且有能力的攻击者没有任何价值。有些人认为在实施过程中存在很多弱点时称这些数据为加密是误导性的。换句话说，您可以稍微减少技术风险，但是您会增加披露的财务风险。当然，每种情况都不一样 - 减少金融风险暴露的技术分析并非微不足道。这是一个说明性的比喻：，因为它们因弱密码而遭受的损失低于支持强密码的最终用户成本。

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.

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

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:

• 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?

Thanks for any help.

解决方案

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

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.

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):

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.

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.

These concerns will likely be addressed in the WebCrypto API, but that is not here yet.

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.

这篇关于本地存储可以被认为是安全的吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！