代码之家  ›  专栏  ›  技术社区  ›  David

基于字符串的协议安全基础

  •  5
  • David  · 技术社区  · 14 年前

    我不知道该如何表达这个问题,所以如果是其他问题的副本,请提前道歉。

    我想检查一下我是如何保护我的基于Twisted的应用程序的,并且认为我在这方面做得很好,但是自从我写了任何使用原始或托管套接字的东西以来已经有十多年了。

    身份验证事务: 客户端连接并立即用16个字符的十六进制字符串发送一个质询响应。 客户端接受用户名和密码,密码转换为sha1(salt+sha1(password)),凭证作为用户名、密码发送回服务器。在服务器端,身份验证执行标准查找模式(如果用户存在并且密码等于输入,则授予)。

    如果用户和客户机之间的连接丢失,协议类会将自己标记为脏的,并将自己与用户对象断开连接。在这之后的任何时候,为了再次访问用户对象,客户机都必须使用新的salt重复身份验证过程。

    我错过什么了吗?对于基于字符流的协议,是否有更好/更安全的方法?

    2 回复  |  直到 14 年前
        1
  •  6
  •   rook    14 年前

    您描述的协议处理一个攻击,即重播攻击。但是,您很容易受到MITM攻击。当攻击者进入协议时,TCP连接不会断开。此外,还可以嗅探通过该系统传输的任何内容。如果你在咖啡馆无线上网,该地区的每个人都能嗅探到传输的所有信息,然后对经过验证的会话进行MITM。另一点是,sha1()被证明是不安全的,您应该将sha256用于任何与安全相关的内容。

    永远不要重新发明轮子,特别是在安全方面。

    使用SSL!每个人都使用SSL,而且它有着久经验证的安全性历史,这是您无法构建的。SSL不仅解决了中间人的攻击,而且您还可以使用证书而不是密码来验证客户端和服务器,这使您不受暴力攻击。在攻击者强行使用2048bit RSA证书之前,太阳将熄灭。神父,你不用担心一个夏娃滴管嗅探传输。

    请记住,openssl是免费的,生成证书是免费的,证书的唱歌是免费的。尽管您想要签署证书的唯一原因是如果您想要实现一个pki,这可能不是必需的。客户端可以硬编码服务器的公钥以验证连接。服务器可以有一个客户端公钥数据库。这个系统是独立的,不需要OCSP、CRL或公钥基础设施的任何其他部分。

        2
  •  1
  •   x4u    14 年前

    您的身份验证似乎可靠,但容易 man in the middle attacks 因为它不能确保到服务器的连接的完整性。

    我建议实施 SRP 6 改为协议。它被证明是安全的,确保了连接的完整性,甚至创建了一个公共秘密,可以用来建立某种形式的对称加密。该协议乍一看有点困难,但实际上很容易实现。还提供了一个javascript演示 project website 并链接到多个不同语言的实现。