如何保证以太坊DApp本地存储localStorage的安全性
这篇文章给大家介绍如何保证以太坊DApp本地存储localStorage的安全性，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
部署去中心化应用程序dapp会引入一些有趣的安全性考虑因素，这些因素可能不会出现在更传统的开发中。我们如何保证dApp本地存储的安全性？
提出这个问题的原因是我们在使用Colony dApp时遇到的一个重要障碍，那就是如何应对在使用IPFS或Swarm等分布式存储系统保持本地存储的dApp数据安全挑战。
我将从dApp开发人员的角度来看一下这个问题，然后研究一些可能的解决方案。
共享本地存储localStorage的问题
IPFS运行本地节点node，它与Web服务器捆绑在一起。捆绑的Web服务器使节点可以轻松地相互连接并共享网络中其他位置可能需要的数据。
作为一个去中心化的应用程序构建器，你将依赖该Web服务器将你的内容从一个节点推送到另一个节点，从而使其可以根据需要立即供最终用户使用。
假设你正在完全去中心化full decentralized并且正在避免使用DNS或Web代理等任何内容来跟踪你的内容在网络上的位置，那么访问dApp的方式通常是通过浏览器使用其查询本地节点哈希，如：
http://localhost:8080/QmcefGgoVLMEPyVKZU48XB91T3zmtpLowbMK6TBM1q4Dw/
现在，假设在正常使用期间，你的应用程序将在浏览器的localStorage保存数据：可能需要传递一些数据，或者保持本地用户交互的队列，以最大限度地减少链上交易并节省gas成本。
浏览器中的本地存储仅限于特定的地址上下文（域和端口）。IPFS节点是获取此上下文的，这意味着通过IPFS Web服务器运行的任何去中心化应用程序将使用具有读写访问权限的相同localStorage。
这可能是一个大问题。
默认情况下，dApp的某些helper依赖项使用localStorage临时将密钥保存在纯文本中。这些数据不应该被看到的一天。
另一个潜在的泄漏问题是保存其内存状态的软件包，以便以后可以恢复。类似Flux-like的库通常（相对）安全，因为它们只在内存中运行，但启用持久性状态会将该内存状态放入localStorage，从而将其打开给潜在的攻击者。
缓解问题的策略
不幸的是，安全没有灵丹妙药：作为一名dApp开发人员，为安全起见所做的任何调整都可能需要在开发的其他方面做出一些让步。
以下是你可以做出的一些妥协：
不存储任何数据
这当然是最安全的方法，但它有点像烧毁你的房子来摆脱蟑螂。在本地存储数据的dApp中有许多功能和基本行为，删除太多后可能没有应用程序存在的意义了。
此外，有许多库默认使用localStorage，你必须手动检查每个依赖项并删除任何需要它的库，否则就得自己修改库。
加密一切这在理论上更有前途，特别是因为大多数dApp开发人员已经在看板上保持默认加密。
加密的local storage值
实际上，加密所有本地存储有点麻烦。要加密数据，必须有一个密钥：但是用户不能将该密钥存储在dApp中，因为它将被放在localStorage，这样做你就将回到原点。
一种解决方案是使用钱包：你的dApp可能会以某种方式与区块链进行交互，要求用户解锁其钱包以发送和签署交易。由于无论如何都需要钱包与dApp交互，因此可以使用每个帐户的私钥privatekey来加密本地存储。
然而，这也有一些缺点：
每次想要与
localStorage交互时，您都必须询问用户的纯文本私钥。像MetaMask这样的密钥管理软件不起作用，因为它永远不会暴露用户的私钥。
使用Swarm和Mist
Mist是作为dApp和以太坊浏览器构建的，因此它为该问题提供了一些特殊优势。
默认情况下，Mist支持Swarm的bzz协议，因此你可以设置一个ens地址指向dApp的哈希值，然后使用Mist无需担心地浏览你的dApp。
不幸的是，这只会解决通过Mist访问dApp的用户的问题。
运行本地Swarm节点的用户仍然必须通过localhost访问，localhost仍然（可能）将数据泄露给其他dApp。
为你的dApp创建一个浏览器扩展
通过浏览器扩展程序运行你的应用程序将导致它获得单独的上下文（它将不再在localhost:8080），但它有点减弱了去中心化应用程序的目的，必须要依赖于像Chrome网络商店这样的中央权威机构用于管理和分配。
此外，现在你必须为要支持的每个浏览器创建和维护单独的扩展，并通过其自己的特定集中式应用商店进行更新。不爽。
创建一个独立的桌面应用程序
和以前一样，创建独立应用程序是将dApp分离到自己的上下文的一种方式，这意味着它将获得自己的包装器（在本例中为electron）。
独立的桌面应用程序具有额外的好处，可以捆绑外部库和你可能需要的任何其他内容，包括IPFS本身的单独实例。
和以前说的一样，要有一些让步：
除非你想要专门在bittorrent上分发应用程序，否则你需要找到一个集中托管的解决方案来进行分发和维护。
你必须为electron桌面应用程序维护一个单独的存储库。
如果你想将IPFS用于任何其他服务，你可能最终会在同一台计算机上运行多个节点，这可能会变得混乱。
将你的应用代理到域名
通过使用其他Web服务器代理本地节点，有两个优点：
首先，现在你的dApp有一个友好的友好的人类可读地址，而不是一个冗长的哈希。其次，你的应用程序将拥有自己的上下文，并且不会共享localStorage。
然而，代理确实跨越了"真正的"去中心化，用户将再次不得不依靠中央服务器来访问去中心化的服务。哎。
对于去中心化的应用程序开发人员来说，现在还处于早期阶段。这种问题在新兴的"去中心化协议栈"中无处不在"：而且在我们提出更优雅的解决方案之前可能还需要一段时间。
将来，在浏览器中支持本机IPFS或Swarm节点可以解决这个问题，并且无需将Web服务器与去中心化的文件存储捆绑在一起。用户可以输入类似ipfs://QmcefGgoVLMEPyVKZU48XB91T3zmtpLowbMK6TBM1q4Dw/并直接访问dApp，并为每个唯一的哈希分配自己的上下文。
关于如何保证以太坊DApp本地存储localStorage的安全性就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
