很简单，令牌不是为记忆而设计的，因此可以随心所欲。密码的长度限制为人们在短时间记忆后实际上可以可靠地回忆起的内容。对于大多数人来说，这将其限制为 7-10 个字符。令牌被设计为可以复制/粘贴一次（因为它是特定于应用程序的），因此绝对不会因为太长而受到惩罚，而且很长的长度使其既安全又独特（即令牌可以有足够的嵌入与特定帐户相关联的信息）。

我想一个更尖锐的问题是，为什么密码不能更长;-)

有几个原因。

原因之一是容易记住的密码对于预期的安全级别来说太短了。有几种方法可以缓解这个问题，但是将它们应用于访问令牌会出现问题：

• 某些服务需要第二个身份验证因素。访问令牌旨在在没有用户干预的情况下使用，因此大多数其他形式的身份验证都已失效（它们要么不适用，例如生物识别，要么只会产生第二个访问令牌）。
• 在线服务通过在身份验证尝试之间施加延迟来防止暴力攻击。这是有问题的，因为它可以锁定合法用户并且因为它是额外的实施负担。
• 密码存储使用慢散列。这会花费大量的 CPU 时间。如果需要对足够长的访问令牌保密并以散列形式存储，则无需特殊预防措施。同样，如果密钥是从访问令牌派生的。

另一个原因是访问令牌的长度通常由协议或库的作者决定，而不是由使用它们的服务的作者决定。使访问令牌更长的成本通常是微不足道的。因此，长度设置为任何人都需要的最高安全级别。您正在将访问令牌长度与最小密码长度进行比较，但更恰当的比较将是最大密码长度。

一些服务使用独立于帐户的访问令牌（即作为 sessio cookie 而不是作为与标识参数组合的身份验证参数）。对于具有不同权限的单个帐户，也可以有许多访问令牌。所以访问令牌需要有更多的熵来保持冲突的概率无穷小。

如果您需要存储相对较短的密码，您必须采取一系列预防措施：

1. 用独特的足够长的盐腌制以防止彩虹表攻击。
2. 密钥拉伸，因此计算需要一些时间，以阻止暴力破解。

另一方面，如果令牌足够长，您可以只存储一个普通的 SHA-256，而不会对安全性造成任何不利影响。这些是优点：

1. 不需要加盐。与加盐密码相比，可以在数据库中搜索令牌哈希。因此，如果您有一个令牌，您可以再次对其进行哈希处理，并使用 SQL 查询检查该令牌是否有效。
2. 计算在服务器 cpu 上快速而轻巧。虽然由于密钥拉伸，我们需要大量的 cpu 能力来散列密码，但令牌的散列速度非常快。

在我最近编写的应用程序中，访问令牌是一个对称加密的字符串，形式为

nonce=123456789;userid=123;username=bob;login_expires=12345679;...

加密的字符串是 cookie，而且很长。解密速度很快，并且假设没有人从服务器窃取密钥，则数据是真实的。