密码的级联和TOTP -可能的问题

Question

我遇到了一种使用基于时间的OTP (TOTP)的双因素登录机制。TOTP (6位数字)在应用程序中显示给用户。

有两种登录方式。

方法1:

用户输入用户名和密码。然后批准在TOTP应用程序中收到的登录通知。在这种情况下，不需要输入TOTP。

username = username
password = password

方法2:

用户从应用程序中输入密码和TOTP的连接作为密码。在本例中，应用程序中没有收到任何通知。

username = username
password = password + TOTP (6 digit)

用户名和密码通过TLS发送。

在服务器端，我假设他们将接收到的密码值中的最后6个数字分开，并检查其是否与TOTP匹配(然后将字符串的其余部分与存储的密码匹配)。

否则，它们会散列完整的密码，并将其与存储在数据库中的值匹配(假设密码不以纯文本形式存储)。如果匹配，通知将发送到用户的设备。

在这个系统中有哪些可能的问题或冷冻缺陷？

Answer 1

我假设

当涉及到安全问题时，我的第一条规则，假设最坏的情况，或者什么都不做(尽管我承认我仍然在做假设)

在这个系统中有哪些可能的问题或冷冻缺陷？

密码可以很好地存储在纯文本中，你只是不知道。事实上，他们一开始就在使用TOTP，这是一个好的迹象，但并没有证明他们其余的安全性。

有些公司对自己的安全实现感到自豪，如果你问的话，他们会直接告诉你，他们甚至可能有白皮书详细说明他们的标准。

还有其他的事情告诉公司已经公布他们的服务安全吗？他们是否使用“军事级加密”或“不可打破”之类的蛇皮红旗语？他们关于密码复杂性的政策是什么？他们的网站是否使用TLS 1.3？

我建议问，如果他们是回避或对抗性，这可能是一个不好的迹象。

Answer 2

有很多错误，你可以假设一个黑匣子进程可能会犯。关注支持这两种身份验证方法的挑战，挑战在于用户从未明确指出他们希望使用哪种方法。服务器根据接收到的输入来推断该决定。具体来说，不清楚密码变量的值是用户的密码，还是附加了TOTP的用户密码。

您可以尝试检查该值是否以6位数结尾，如果是这样，请将其拆分到那里。您会发现，密码以6位数结尾的用户无法正常登录。这意味着您可能会得到检查提交的密码和提交的密码减去最后6位数字的代码(如果它与该模式相匹配)。这是服务器必须做的额外工作，特别是如果它使用的是一个缓慢的密码哈希算法(这是最好的做法)--它使得一些登录所需的时间是需要的两倍。但是，一旦服务器完成了这项工作，它将确定密码的任何一个版本是否有效，然后从那里开始。因此，攻击者可以以1的代价获得2个密码猜测，但这并不是什么优势。