以下银行交易认证方案的缺点是什么？

Question

在德国，网上银行交易的认证(除了基本的登录密码是而且一直需要的密码之外)已经从预先在纸上分发的一次性密码列表(所谓的"TAN“代码，或交易认证号)发展到使用一次性密码按要求发送到移动电话或类似设备的信息中，其中还包含用于验证消息的传输细节。我一直在想，在采用较旧的预先分发纸张清单的方法的同时，是否有可能达到类似的安全水平，而事实上，我想出了一个对我来说可行的方案。由于我知道业余者(我也是业余者)设计的安全方案的一般质量，我想从这个网站的读者那里听到关于我的计划的缺点的评论。

该方案的基本思想是，银行将事先向客户分发编号条目的书面清单。但是，列表将包含简单的数字任务，而不是包含简单的密码，例如：

1. 输入图1和图4的帐户号之和，然后是数字8，然后是60减去银行分类代码的图3。
2. 输入帐户号的图3，然后是图2和图7的银行分类代码，然后是图2和图1所要转移的金额(忽略美分)。
3. ..。

当客户必须对事务进行身份验证时，将给出其中一个任务的编号，并要求他们使用事务详细信息输入解决方案。在我看来，这个方案满足了这样的要求:一次密码生成应该由银行在交易时发起，它与交易相关联，从密码返回到生成的方法是不容易的，而且它涉及第二个分离的通信通道。此外，我希望它对客户来说是可管理的(除了它可能需要一张很大的纸来保存任务！)，并鼓励他们检查交易的细节。

我意识到，需要对这些任务提出要求，才能保证它们的可用性，但仍然是安全的，而且它们必须以银行计算机能够处理的方式表达，而且参数化(尽管在任何时候都可以引入新的类型)。除此之外，我还想知道这个计划中有哪些重大漏洞是我错过的。

Answer 1

有些想法没有什么特别的顺序。

1. 它需要良好的数学、阅读和推理能力；尽管如果每个人都能完成这些任务，那将是很棒的，但我们也不能(也不应该)期望每个拥有银行账户的人都能做到这一点。这将导致错误的登录失败，减少使用，并增加支持调用。
2. 关于如何写问题，它需要标准化。理想情况下，这些问题应该能够通过算法生成，而不是由人类编写，并且可以验证是正确的，并且没有歧义。
3. 该方案要求能够阅读所用的问题所用的语言。只有令牌卡或密码列表的方案没有此限制。银行账户大多是跨语言的数字.
4. 考虑到上面所要求的标准化，现在我们必须能够验证从密码向生成算法反向工作确实不是件容易的事。从你的描述中还不清楚这是真的。
5. 得到的数字必须足够长，以提供足够的熵，并且足够短，以使计算步骤可行。例如，一个10位数字可能有足够的熵，这取决于计算方案和其余的安全性；但是10位数可能太长，不能指望有人跟随您的所有步骤。
6. 你想要解决的问题是什么，而你觉得目前的计划还不够呢？

Answer 2

这有两个缺点，其中一个可能是毁灭性的(在我看来)。

1. 可用性糟透了。很大一部分客户将很难使用它。错误率会大大提高。有些客户只会对银行不满，这对生意不好。其他人将打电话求助热线，这对商业来说很糟糕:我听说有人估计每打电话到服务台要花20到40美元。因此，如果你的建议增加了10%的求助电话，这对你的计划来说是一个巨大的成本，这会让它死在水里。我觉得这是个表演障碍。
2. 它没有任何明显的安全利益的替代方案，如发送交易的细节和确认代码给客户的手机。