网络加密货币
下面详细介绍了客户端(浏览器)javascript 中的加密问题。除了其中一个问题之外,所有问题都不适用于WebCrypto API,它现在得到了相当好的支持。
对于离线应用程序,您仍然必须设计和实施安全密钥库。
另外:如果您使用的是 Node.js,请使用内置的加密API。
本机 Javascript 密码学(WebCrypto 之前)
我认为主要关心的是有人可以物理访问localStorage
为您的站点读取计算机的计算机,并且您希望密码学来帮助防止这种访问。
如果某人有物理访问权限,那么您也很容易受到比阅读更糟糕的攻击。这些包括(但不限于):键盘记录器、离线脚本修改、本地脚本注入、浏览器缓存中毒和 DNS 重定向。这些攻击只有在用户使用机器后才有效。然而,在这种情况下,物理访问意味着你有更大的问题。
因此请记住,本地加密货币有价值的有限情况是机器被盗。
有些库确实实现了所需的功能,例如Stanford Javascript Crypto Library。但是,存在固有的弱点(如@ircmaxell 回答的链接中所述):
- 缺乏熵/随机数生成;
- 缺乏安全的密钥库,即私钥如果存储在本地或存储在服务器上(禁止离线访问),则必须受密码保护;
- 缺乏安全擦除;
- 缺乏时间特性。
这些弱点中的每一个都对应于一类加密妥协。换句话说,虽然你可能有“加密”的名字,但它远低于人们在实践中所渴望的严格程度。
尽管如此,精算评估并不像“Javascript 加密很弱,不要使用它”那么简单。这不是背书,严格来说是警告,它要求您完全了解上述弱点的暴露、您面临的向量的频率和成本,以及您在发生故障时的缓解或保险能力:Javascript crypto,在尽管它有弱点,但可能会减少您的曝光率,但只能针对技术能力有限的盗贼。但是,您应该假设 Javascript 加密对针对该信息的坚定且有能力的攻击者没有任何价值。有些人会认为,当已知有如此多的弱点是实施所固有的时,将数据称为“加密”是一种误导。换句话说,您可以略微减少您的技术风险,但您会因披露而增加您的财务风险。当然,每种情况都是不同的——减少金融风险的技术风险的分析并非微不足道。这是一个说明性的类比:尽管存在固有风险,一些银行仍需要弱密码,因为它们因弱密码而遭受的损失低于最终用户支持强密码的成本。
如果您阅读最后一段并认为“Internet 上某个名叫 Brian 的人说我可以使用 Javascript 加密”,请不要使用 Javascript 加密。
对于问题中描述的用例,用户加密他们的本地分区或主目录并使用强密码似乎更有意义。这种类型的安全性通常经过良好测试、广泛信任并且普遍可用。