网络加密货币

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

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

另外：如果您使用的是 Node.js，请使用内置的加密API。

本机 Javascript 密码学（WebCrypto 之前）

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

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

所以请记住，如果机器被盗，本地加密货币有价值的有限情况。

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

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

这些弱点中的每一个都对应于一类加密妥协。换句话说，虽然你可能有“加密”的名字，但它远低于人们在实践中所渴望的严格程度。

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

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

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