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

2FA密码应该散列存储吗?

  •  13
  • blackbird  · 技术社区  · 7 年前

    我正在我们的网站上用谷歌认证器实现2FA。如果我理解正确,每个用户都会有自己的密码,我需要在登录时验证他们输入的6位密码。

    将这些密码与用户密码存储在同一个数据库中似乎是一个坏主意(尽管,如果有人掌握了数据库,我们会遇到更大的问题),是否还有其他解决方法?还是应该把它们当作密码来加密?

    2 回复  |  直到 7 年前
        1
  •  13
  •   philnash    7 年前

    您不能散列用于为Google Authenticator生成TOTP代码的密码,因为您需要原始密码才能实际生成代码。

    就像你说的那样,如果有人拥有你的数据库,那么不管怎样,你的麻烦就更大了。然而,这就是双因素身份验证的工作原理。如果密码确实被安全地散列,并且攻击者只有TOTP密码,那么他们所能做的就是在登录所需的2个因素中生成1个,并且他们要做更多的工作来破解或窃取密码。

    Twilio's Two Factor Authentication API . 完全公开,我为Twilio工作,但如果你不想担心照顾那些你不能散列的秘密,也不想利用其他事情,比如 Authy app (包括无二维码的秘密传输)和 extra device data that is now available with authentications

        2
  •  2
  •   ton    5 年前

    你是对的。

    确实,2FA提高了用户安全性,但从定义上讲,在服务器端并不那么强大。如果黑客或具有数据库访问权限的恶意员工转储并发布用户机密,则附加安全性将消失。

    您可以创建一个外部隔离的微服务,接收用户哈希并生成2FA密钥,对其进行加密并存储在密钥值数据库中,如elasticsearch。您可以在服务器启动后动态设置加密密钥,以避免将其硬编码存储。您可以将数据库存储在外部服务器上,员工只能通过API进行访问。

    这样,如果恶意参与者转储elasticsearch数据库,他们就无法知道什么是秘密,即使他获得了对加密密钥的访问权限,他也不知道谁是使用该秘密的用户,因为密钥是用户id哈希(而不是用户id)。