Secret背后的技术架构与安全实践

Secret作为一个创业项目虽然失败了，但这一过程却留下了不少值得汲取的经验和教训。2014年2月发布4天后，创始人David Byttow曾经在Medium上介绍了Secret的技术架构和安全实践，打消用户对隐私暴露的担心。下面是一些要点。

• Secret本身寄存在GAE上，主要用Go语言开发，部分组件用的是Java和Python。这些都很自然，因为Byttow是Google出来的。
• 数据放在Google数据中心的服务器中，这个数据中心还有一个大应用，就是Gmail，因此物理安全是令人放心的。
• 所有线上的通信都用TLS加密。
• 存储层用的是基于BigTable的高可用、非关系型数据存储，没有关系性数据库。
• 所有消息数据在写入数据库之前都已加密，密钥保存在独立的密钥存储服务中。
• 图片存储在Google的Cloud Storage里，通过Google的图片前端经TLS提供。
• 对于从手机上获取的通讯录数据，会在本地散列化（这一转换是单向的），然后将散列值存到服务器中，服务器端只用散列值进行其他处理。所以Secret本身不知道用户的电话号码和其他数据。当然，如果攻击者获取了散列所用的salt值（这是全局共享的），仍然可能反推出来。Secret还在研究更安全的办法，比如加入客户端特定的数据预散列，或者Diffie-Hellman密钥交换。
• 用户发送的秘密元数据保存时不会引用用户信息。秘密发给一个用户时，会为用户生成唯一的令牌，将其授权给秘密信息，是多对一的关系。令牌资源放在秘密而非用户拥有的一个ACL中。秘密极其评论的数据都在服务器端加密，当有令牌时解密。所以，显示秘密信息时，不需要个人身份数据。
• 用户、秘密消息和ACL等数据结构的存储都是逻辑隔离的。
• 身份方面，管理者不能查看或者修改特定用户的发送的秘密。如果为管理、调试或者其他目的，需要访问和修改这些信息的话，遵守两人规则，即必须两人同时进行、互相监督，一般情况下是两位创始人同时用自己的Google账号登录（并受双因鉴别保护），在同一时间请求同一资源。这种实践被Cloudflare称为红十月。
• 信息推送方面，设计目标是安全、快速、基于学习算法。秘密消息首先保存并发送给作者，然后运行一个异步作业，依据算法来决定还会推送给谁（可能是与作者有关系或者系统认为有关联的人）。通讯录是算法中的强信号，但不会推送给通讯录上的所有人。每个推送对于每个用户都是不同的，可以撤销，有助于识别和减少垃圾信息和其他无益的行为。
• 推送时机方面，虽然推送管道的吞吐量很大，但并不是总是立即推送。系统中用户的朋友越少，推送的信息也越少。有助于避免用一些简单的办法隔离一些用户及其秘密消息。（？）用户在系统中朋友足够多了之后，看到的信息也越多，比如秘密来自朋友圈（朋友和朋友的朋友）。朋友再多一些，会看到来自朋友或者非朋友。这对于匿名环境中建立联系是至关重要的。