羞愧之墙

StatusIM  2018-08-15  SNT/SNT(Status) 栏目  

  这是我们的羞愧之墙。无论我们是因为什么原因,我们知道我们不应该做这样的事情。这份列表来自我们中的一小部分人, 他们在巴塞尔开会, 沉思着 Status 在安全方面应该是什么样的, 以及我们该坚持什么样的原则。

  这是起点, 而不是终点。他们已经在我们的脑海很长一段时间了, 但通常隐含在少部分人的大脑中, 而不是明确的在社区公开表达。这是我们对我们的缺点进行透明的方式, 所以我们可以一起解决这个问题。这甚至是我们核心 OKRs 的一部分, 可以在未来几个月内解决前10的问题。祝我们好运。好消息是, 通过代码, 想法和讨论来帮助解决这些问题。我们支付赏金,请不要客气:)

  列表 (按预估的严重性和风险顺序排列)

  1. 助记词存储在数据库中

  访问我们的数据库和加密密钥的攻击者可以为每个未备份他们的密钥的用户解密所有密码, (在这种情况下, 密码不再存储在我们的数据库中)。数据库本身是加密的, 但理想情况下,密码和助记词是我们永远不能存储在磁盘上的东西。其他敏感数据 (如聊天记录) 应仅通过用户的密码进行加密和访问。

  2. 弱证书检查

  浏览器仅验证 SSL 证书是否有效。仿冒网站可以具有有效的证书。相比之下, 谷歌的安全浏览是对网站上的可疑条款与 google 服务器进行对比检查。

  3. 要求使用 JSON RPC 服务器 (SPOF)

  JSON RPC 是用户使用 Status 连接到以太坊的唯一方法。它是一个受信任的中介, 不是去中心化的。轻型客户/ULC 要求是去中心化的。

  4. 向网络发送垃圾邮件

  我们的集群很容易被打倒, 这也是一个单独的失败点;如果被攻击, 服务就会停止。

  5. 替换 MixPanel

  MixPanel 违反我们的精神, 它保存关于产品使用情况的数据。我们不能保护这些数据。MixPanel 过去泄露过密码。

  在这里被跟踪(https://github.com/status-im/status-react/issues/5169)

  6. 耳语包易于受到 DDos 攻击

  耳语使用 PoW 作为反垃圾邮件的机制, 但在移动设备上我们不得不减少它的使用, 结合 SNT 的监视机制, 我们可以进一步挫败垃圾邮件和补偿节点来坚决处理它。

  7. 完善前向保密

  前向保密 = 更改每条消息密钥。在这种情况下, 即使某个密钥被泄露, 也只能公开少量的用户数据。

  在这里工作(https://discuss.status.im/t/forward-secrecy/150)

  8. 端到端确定性生成

  我们不知道我们的生成和释放管道是否受到破坏, 分发渠道中的二进制是否合法。拥有多个部分, 然后签署减少在软件里遭到黑客或者 bug 的攻击面,至少在版本控制和源代码方面是一个巨大的胜利。

  这意味着我们将有确定性的构建, 这将极大地减少开发人员设置其环境的高门槛。理想情况下, 我们应该达到一键构建。

  9. 群集单点故障

  集群是 "集中化" 的思想, 我们应该设置我们的系统, 使他们去中心化。让我们不要进入一个像 Infura (每个月花费 50万到100万来服务请求) 的角色, 这与我们试图实现的东西是对立的。

  10. 技术缺陷透明

  有时我们会说, 我们的技术比实际更去中心化或更安全。缺乏对通信技术的校对导致了这个问题。(因此才有本文档!)

  11. 日志中泄漏元数据, 有时还有数据

  在日志中公开用户数据等同于对具有一定技术能力的人开放。

  12. 对 HTTP 服务的调用

  HTTPS 对第三方 GET/POST 的方法是不安全的。提交给服务器的数据可以操纵, 它们可以是伪造的, 等等。我们依靠服务提供一些数据 (如 Etherscan), 目前这可能是不可避免。最好使用像 Oraclize.it 这样的。但是, 我们没有给用户一个选项来启用/禁用这些功能。他们应该是可选择的

  13. 聊天中的垃圾信息

  人们在公开聊天中张贴不相关或恶意的信息, 从而降低了体验的质量。

  14. 使用假名

  我可以设置我的显示名称为"朱利安", 并使用他的个人资料照片, 然后假装是他。

  15.-劫持或欺骗 DNS

  我们可以用 DNSCrypt 这样的。诚然, 这实际上只是一个在连接到旧式 Web 2.0 基础结构时的问题。

  这个问题 Web 3.0 和 ENS 通过设计减少了很多。

  16.-注入 web3 请求权限

  为了使 DApps 能够在网络上进行交易, 我们将标准 web3 对象注入到任何站点的 DOM 中。此对象不仅显示用户处于以太坊网络, 而且还可以泄漏与钱包和交易相关的更敏感数据。EIP 1102 提出了一个新的标准来纠正这一点。

  17. 恶意自定义生成

  试图在其计算机上安装 Status 的用户可能会被欺骗, 转而安装恶意程序。二进制哈希和在链上为 Status 版本的签名, 然后使用工具可以进行链上查找我们已经签署的哈希并比较用户拥有的二进制哈希值。

  18. 在所有 DApps 使用相同的密钥

  我们给 DApps 用户的公共地址。我们应该 1) 默认情况下不提供此数据, 并且/或 2) 在用户允许共享其真实数据之前, 现场生成一个全新的帐户。

  19. 依靠 Slack

  Slack 是中心化的。我们把聊天记录都发送给他们了

  20. 在黑暗路由附近没有保证

  需要更多的耳语协议研究/应用研究

  21. 聊天中的节制

  垃圾消息和攻击性内容经常发生, 我们没有措施来保护公众聊天不被完全干扰。

  在这里工作(https://discuss.status.im/t/visibilty-stake-for-public-chat-room-governance/133/12)

  20. Javascript 依赖

  我们有很多 JS 依赖, 而没有操纵保证, 这是一个巨大的攻击面。

  21. 依赖第三方分销渠道

  它们本质上是无权控制一个基本的分发渠道。可如果我们想在 iOS 上分发,我们没有太多的权利, 也许一些第三方可以为 Cydia (但不是我们) 建立渠道。

  对于 Android, 我们可以上架尽可能多的应用程序商店, 包括 Apptoide 和FDroid

  22. 用户泄漏助记词

  错误使用。如果用户备份他们的助记词, 他们将截图, 发电子邮件, 写在纸上, 扔掉等。当前的 UX 允许截屏, 懒惰的用户 (包括我) 将这样做。这个问题应该与时间相结合, 因为用户在开始时并不关心钱包的价值, 但是随着资产的持续使用, 风险会越来越大。

  23. Devp2p 加密损坏

  在未来这将通过移动到 libp2p 上得到修复, 如果我们有 PFS,这立马不是一个问题,。要澄清的是, 这也是 Geth 的一个问题,而 Status 基于 Geth 之上。

  24. 单密码签名和登录

  只用一个密码在用户整个的 Status 帐户中使用。同样, 密码字段不能粘贴, 因此无法使用密码管理器。我们暗地鼓励使用短密码。也许指纹认证更方便和有用。

  25. 使用 github 的代码签名与自托管

  我们依靠 Github 来托管我们的代码库

  26. 交易是公开的

  所有交易记录都在以太坊区块链上可见。虽然匿名, 但它们提供了对来源、目的地和资金数额的探查。

  27. 单一法人实体

  我们依靠政府管辖内的法律实体作为一个组织运作。当我们发展到 DAO 时, 可以减轻这一点。

  28. 清除和导出聊天

  无法清除或导出聊天。这也与销毁消息有关。

  29. 需要互联网运作

  在恶劣的城市环境中, 如互联网关闭, 有了临时 wifi 将允许当地 mesh 网络的出现。

  原文

  Chats are unable to be cleared or exported.

版权信息
作者:status
来源:StatusIM

关于我们

联系我们

作者进驻

手机版

Copyright © 2013 比特巴 www.btb8.com
始建于2013年,提供比特币 区块链及数字货币新闻、技术教程、测评、项目周报、人物等资讯
本页面提供的是SNT教程资讯,Status(SNT)是一个开源的聊天平台以及是一个支持以太坊去中心化应用dApp的移动浏览器。