这听起来很像 Fencepost Security。想象一下，您正在运营一个设施，其周围有 500 英尺高的链节围栏。将栅栏提高到 3,000 英尺高，安全性会提高多少？没有——因为任何试图进入的人都不会爬上 500 英尺；他们会在下面挖，挖一个洞，等等。

同样，您的密码是 20 个随机字母数字字符。那是 62^20 种可能性。您正在考虑将其更改为 20 个随机 unicode 字符。这将可能性空间提高了很多，除了强制使用 20 个字符的随机密码不会受到损害。

从安全角度来看，这是一个好主意。包含 unicode 字符的密码比包含相同长度的 ASCII 字符的密码更难暴力破解。即使您比较字节长度而不是字符长度，这仍然成立，因为 Unicode 使用最高有效位，而 ASCII 不使用。

但是，我认为这不切实际，因为 Unicode 错误如此普遍。我认为，如果您在任何地方都使用 Unicode 密码，您会遇到不止几个登录时遇到问题的网站，因为开发人员没有正确实现对密码的 Unicode 支持。

忽略通过默默无闻论点的安全性，这是熵的基本问题。8 个字符的 unicode 密码比 8 个字符的 ASCII 密码更安全，但不如 64 个字符的 ASCII 密码安全。

总的来说，我同意 Sjoerd 的观点——这些可能带来的不便多于好处。最重要的是，如果您需要手动输入密码，随机 Unicode 可能会让您的生活变得痛苦。

但是，对于需要使用主动支持 unicode 的服务同时强制执行最大密码长度限制（再次忽略这通常表明其他安全故障）的边缘情况，有一个论据。

我能想到的在密码中使用 Unicode 字符的唯一有效原因是，特定站点的密码中的字符数（不是字节数）是否有限（比如这个以前最多 10 个字符的哑银行），所以一两天之内就很容易猜到了。在这种情况下，您可以使用 Unicode（如果网站所有者允许）在您要求网站所有者遵守NIST 800-63-3并删除长度限制（并正确散列）的同时，在密码中获取更多熵所以密码存储不是问题）。

我还想在这里纠正一个误解：

Unicode 使用最高有效位，而 ASCII 不使用。

虽然对于普通 ASCII 是正确的，但某些密码管理器（例如 KeePass）可以在密码生成中使用的扩展 ASCII 使用每个字节的每一位，因此具有比 Unicode 更高的熵密度，Unicode 仍然具有一些结构来指示有多少以下字节的一部分是同一字符的一部分（请注意，在 Unicode 中存在无效字节序列之类的东西）。

由于限制您使用短密码的网站可能甚至无法正确散列其密码（导致 Unicode 密码失败或以错误的编码存储），因此您几乎不应该浪费时间来处理 Unicode 密码，因为当您如此被你有趣的角色分心（以及你必须重置密码，因为它被奇怪地存储的事实），攻击者可能会猜测你的（in）安全问题或使用巧克力密码术来访问你的帐户。