安全无小事

前些天在HIVE开发者群里(MatterMost)看到大佬们在讨论某HIVE APP登录的问题，最初是关于注册方式用种子短语还是主密码哪个更优的探讨，后来又变成了登录过程是否把用户私钥发送到服务器的争论。

(图源：pixabay)

翻看了一些他们的讨论后，我就不太感兴趣了，因为据我所知，一般HIVE APP都应该是在本地签名交易，不应该以任何形式把私钥发送至服务器。所以我认为把私钥发送至服务器，是不会在任何APP上出现的。

说到登录验证（或者单纯地验证），很多人最熟悉的莫过于用户名密码登录，以论坛为例，我们在论坛注册时，除了用户名外，还会设置一个密码。而登录时我们需要提供密码给服务器端程序，程序比对数据库中相应的密码，比对通过则登录成功。

稍微有些安全意识的用户，就会发现一个很大的隐患，如果论坛管理员不怀好意，那么数据库中的用户名密码岂不是任由他来获取呀？或者这个数据链条上任何一个环节（路由节点）都有可能截获密码（明文密码的话）。

所以一些论坛应用不存储用户密码，而是存储密码的哈希值(一般都是md5)，而用哈希值(md5)反向推算出密码，基本上是不可能是事情。（注：是否安全和密码规则、复杂度也有关，设置简单的密码很容易被碰撞）。

这样的话，用户和服务器间通信，以及服务器数据库中存储的密码都是哈希值，安全性大幅提升。但这样是不是就绝对安全了呢？显而易见是不可能的，尤其是服务器端的管理人员，想要干些坏事，有100种方法。

公钥私钥技术的广泛应用极大程度地提高了验证的安全性，以论坛发帖为例，我们需要使用前边所述的密码登录后发帖。

而以HIVE为例，我们根本不需要登录，只需使用私钥对我们要发布的内容进行签名，然后广播给服务器即可。服务器端收到我们广播的数据后，会根据我们的公钥核对签名是否有效，签名有效的话，则把数据加入到区块链中，亦即发帖成功。

可是为什么我们登录HIVE相关的DAPP却都要求“登录”呢，我猜测是为了提供便捷性，以hive.blog为例，如果不登录，那么我们每次发帖、回复、点赞，都需要提供私钥来签名，那得多麻烦呀？

那么所谓的登录需要把私钥发送给服务器吗？显而易见的并不需要，私钥在会话期间可以保存在内存中并进行加密，或者使用短时间过期的 Token 代替私钥等等。

(图源：pixabay)

好了，通过上边的分析，我们知道了HIVE上的“登录”过程不同于传统的论坛登录，抛开具体的技术原理以及实现机制不谈，一个最简单的结论或者说原则就是：无需也不应该以任何形式把私钥发送至服务器。

连我这种半瓶子水准的人都知道的事情，那些实现运营APP的大佬们怎么会不知道呢？怎么可能会犯这样的低级错误呢？！想起抖音中常用的一个BGM——不可能，绝对不可能！

然而有句话咋说来着：这世界是个巨大的草台班子。

再后来某大佬喊我继续去看HIVE开发者群相应频道的聊天记录，然后发现这个APP确实将用户的私钥存储在Cookie中并发送到服务器！

我们假定这个APP并不存在恶意，但是一位大佬评价这事时说的一句话我很赞同：

当用户安全受到威胁时，意图并不重要，结果才重要。(But when user security is on the line, intents do not matter, results do. )

所以事实就是由于设计的原因，之前使用过这个APP并使用私钥直接登录（而不是HIVEAuth或者KeyChain之类的工具）的用户，私钥可能会发送至服务，存在被泄露的风险。安全起见，修改一下相应的私钥，还是比较明智的选择。

当然了，修改私钥或者修改密码，本身就是一件非常危险的事情，尤其是你不得不使用其它DAPP来修改时，谁又能知道修改的过程有没有泄露，有没有引入新风险呢？

安全的做法是自己使用代码生成相应的公私钥对，然后使用命令行钱包或者自己编程来实现账户中关联公钥的替换。但是又有几人能做到这样操作呢？

(图源：pixabay)

好消息是，就算是Posting Key泄露，也不会造成资产损失。所以用过这个应用的用户如何处理，就自己决定吧。毕竟自己才是自己的资产的责任人呀！