【提案】authn.std.dweb

提案背景

目前的 biometrics.sys.dweb 模块过于简单，只是提供了生物身份识别的功能，只能提供 true or false 的功能。开发者只能机遇这个 true or false 字段，从而作为一个简单的判断，从而保护接下里的操作流程。

但我们需要看到几点客观现象，然后重新作出设计决策：

在现实生活中，大部分中低端手机对于生物识别的硬件安全性并不够高，因此每间隔一段时间，操作系统还是得定时让用户手动输入一串依赖于记忆的秘密，来规避硬件上的缺陷。
1. 一方面减少记忆密码的输入可以降低密码输入的频率，从而降低密码被盗取的频率；
2. 另一方面，记忆密码作为兜底的最可信方案，不应该被遗忘，所以定期输入可以避免记忆衰退。
  - 如果只是为了减缓记忆衰退，那么可以用“计算挑战”来解决这个问题，就是让用户做一些推理不可逆的计算题，比如：“密码的第三第四位数字向 5 取余后余数多少？”类似这样的问题，让用户本能地回忆整串密码，然后通过一些模糊的挑战来完成验证。这样旁边的人即便看到了答案，对他来说，也无法进行完全的可逆推理。
  - 但是，收集一定次数的计算挑战过后，暴力破解的难度就会大幅度下降，对于一些个别场景来说，这种不安全性就会有很大的问题。这时候我们往往需要要求用户在一定次数的计算挑战后，重新设置记忆密码，这也就意味着对用户的记忆发出了较大的挑战。
  - 这时候有一种取舍方案，就是不要求用户修改记忆密码，但是由底层的密码管理器给一个非常容易记忆的“遮罩码”，比如记住“遮罩码=7”，那么在所有的计算挑战中，使用遮罩码进一步对结果进行加工即可。那么我们只需要定期更换遮罩码即可。
我们可以将生物信息看作为一串密码，比如将人脸特征坐标数字化、将指纹特征坐标数字化。
1. 假如说：将人脸信息的特征直接作为密码来使用，这意味着直接暴露了用户的隐私。
2. 因此底层技术人员的设计思路是避免这串与生物特征直接关联的密码暴露给开发者，而是作为更加底层的加密技术存在，将生物信息只与单台设备进行关联；从而对应用层的数据进一步进行加密，来避免用户底层的生物信息泄露。
  - 因此 dweb-browser 这边的思路也是类似的，将应用级别的密钥进一步作为底层密钥，从而为每个模块分发不同的密钥
一直以来，社区一直存在密钥盗取的事件，我们即便告知他们要谨慎使用密钥，输入密钥和支付密码的时候要确保身边不要有其它人。但是这类的事情还是会发生，毕竟墨菲定理。本身我们的技术就意味着用户需要频繁跟这些密钥打交道，根本做不到完全的环境安全，总不能要求用户要像棱镜门中的爱德华·斯诺登那样，每次输入密码都要用一块布盖着头和计算机吧。
1. 因为用户的密钥难以记忆，他们通常的做法是从微信收藏里找到密钥、或者是手机内置的笔记软件，然后复制粘贴到应用内。这个过程中只需要有心之人在旁边拍个照，很有可能就会将其密钥盗走，即便照片模糊，但是单词本身就是具有图像特征的，所以多试几次总能找到适合的单词。
2. 而支付密码就更好盗取了，它往往是容易记忆的数字，有心之人看一遍基本就记下了。
  - 我们的支付密码的设计其实非常危险，很多老人家往往习惯将纯数字作为密码来使用，比如生日、过去的座机号码、手机号码的后几位。这种传统密码，有心之人只要配置一些密码字典，就很容暴力破解
  - 甚至一些人会通过做一些软件，利益诱惑你，提供给你传统的注册功能界面，让在这个界面里输入密码进行注册，然后在登陆的时候故意告诉你密码错误，让你反复输入密码，甚至怀疑自己，让自己输入更多的常用密码，从而窃取到更多的密码字典。
因此现有的很多密码管理器给出的方案就是，让用户记不住密码，只使用密码管理器给出的密码来做自动输入。这种方案有一个兜底的方案，那就是依靠云同步来做密码找回。
- 我们固然也可以做类似的事情，特别在我们之后如果打通了个人设备的胡同，那么密码管理器也应该做类似的事情：跨设备同步这些重要信息，这样即便移动设备丢失，只要家没被偷就还好说。
- 但在此之前，我们应该先专注于将“记忆密码”的保护做到极致。
- 未来终极解决方案可能是生物芯片：可以理解成把手机卡嵌入到身体组织里头，并将生命特征与其绑定，只有生命体征正常的情况下才能正常使用芯片进行授权。如果出现异常的生命特征：比如监测到血氧浓度异常、血压异常，那么芯片卡就会被锁定。锁定后需要用户生前自己配置的密钥才能解锁，这个密钥可能在亲人身上，或者在记忆里，或者在某些程序的触发器里。

技术设计

参考资料：

BioforestChain / dweb_browser

【提案】authn.std.dweb #93

提案背景

技术设计