这是帮助减少数据输入错误的经典实施选择。

计算机科学或信息安全领域的人了解文本字符串和表示值的一系列数字之间的区别。但是在金融、会计和其他领域接受过培训的人在处理数字时被教导要截断前导零。他们更有可能将一行数字视为“有值的数字”。例如，如果他们看到“000001”，他们的大脑会将其解释为值“一”。当需要输入代码时，他们会回忆起值“一”并反射性地输入“1”。从数值上看，它是一个等效值，但作为文本字符串，它不是完全匹配的。

系统设计者有几个选项来处理这个问题。

• 他们可以生成带有前导零的代码，并允许少数用户偶尔犯错误，迫使他们重新输入。这会给应用程序带来难以使用的声誉。

• 他们可以更改输入系统以匹配文本匹配或数值匹配。这增加了代码关键安全区域中用户输入逻辑的复杂性。安全漏洞的历史是一系列证据，表明处理用户输入的复杂性增加会增加导致漏洞的编码错误的风险。

• 他们可以从一组有限的数字中生成代码，这些数字绝不会引起用户混淆。这将可能的有效组合数量减少了大约 10%，系统设计人员在计算暴力破解或随机猜测攻击的可行性时必须考虑到这一点。通过将复杂性转移到代码的生成部分而不是用户输入部分，编程错误可能不太可能造成漏洞。

归根结底，这是一小部分人口的人为因素问题。但是安全系统已经很复杂、耗时且令人沮丧，因此任何会增加用户挫败感的可用性问题对于故意保留在安全系统中（尤其是您试图进行商业营销的系统）来说都是非常糟糕的。

手机短信阅读器倾向于解释文本元素以方便用户导航。这包括用于快速拨号或添加/保存联系人的电话号码。

因此，模式的使用G-[1-9][0-9]{5}很可能是避免这种常见行为的一种方式，这样它就不会阻止复制等其他操作或触发呼叫或保存联系人等不适当的操作。

我怀疑该算法与他们用于 Google Authenticator 的算法密切相关，TOTP（如果考虑到类似的使用上下文，如果不完全相同），并且该算法使用的算法经过定制以确保结果始终为 6 位数，基于几个更大的计算。我对实际的 HMAC 过程知之甚少，无法肯定地说 0 不会出现在输出中，但这显然不太可能。这是一个相当详细的细分：https ://garbagecollected.org/2014/09/14/how-google-authenticator-works/