在一个大企业中换一个工具往往是冗长、痛苦的过程，因此很多公司还在运作着防范旧时代黑客攻击方式的软件。从词组口令角度来看，采用复杂性的要求规范要比采用长度的要求规范要容易实现得多。

NIST在800-63B下新更新了关于口令（password）的指导方针。新文件不再推荐使用大小写、数字和特殊符号的组合。不过，大部分公司和系统依然会将这种组合作为硬性要求。这就引发了对新文件的疑问。

事实上，NIST和一些合规标准之间始终存在一些军备竞赛。SOX、SOC2、PCI等规范都有对口令复杂性的要求。这些规定都一度受NIST的影响，从而相关系统都要求口令有字母、数字和符号的组合。这样一来，企业为了获取相关资质，就不得不要求他们的用户启用这些要求。

口令在法制规范和技术层面的局限

除了标准要求之外，技术系统也对口令有要求。一些对口令有加密要求却没有复杂性要求；一些可以通过调整从而让管理员决定具体可以使用哪些特殊符号、大小写和数字组合是可用的；还有一些系统是在存储能力第一的旧时代建立的，因此他们只会保存输入的前八个字符作为口令。系统的选择，完全由当工具被创建时期的观念潮流，以及相关工具的厂商认为哪些合规要求可能会要，这两个因素决定的。

另一方面，每个公司都会因为自己的实际情况，需要符合不同的规范标准。举例而言，即使两个公司都使用Salesforce这同一个工具，但是根据他们使用的方式以及面向对象的不同，会造成其中一家公司需要满足SOX要求，而另一家不需要。

在过去十年，NIST做了很多改动——加入了数字、一些可接受的符号，还有对口令长度的建议——还在不同工具中以一种不怎么平滑的轨迹被启用。最终，大部分公司都发现了他们的“安乐窝”：把这些要求一锅端地用“我们所有的工具都能做到”就能解决公司需要符合的标准了。

不过，显然这个过程花了一点时间和不少讨价还价的空间。

向词组口令的转变

（词组口令即用多个词组组成的口令，而非单个单词）

在任何公司推动词组口令要求都或多或少受到了一些阻力。原因无他，毕竟尽管安全从来不是建立在一个单独系统、安全厂商、或者合规要求，但在同一个公司始终是由同一拨人在处理的。而在一个大企业中换一个工具往往是冗长、痛苦的过程，因此很多公司还在运作着防范旧时代黑客攻击方式的软件。从词组口令角度来看，采用复杂性的要求规范要比采用长度的要求规范要容易实现得多。

NIST新更新的指导规则建议，如果口令使用频率高、容易被猜到或者泄露，就不应该使用。这个改变是基于黑客往往收集大量的口令字典，而算力已经足够强大到尝试大量组合。任何的“常用词或者常用词组”都可能出现在其中的某一部字典中——这甚至包括了莎士比亚某个独白的第一节，或者某个流行歌曲的歌词。另外，连续或者重复的字符也会在字典攻击中，因此需要被避免使用。

在2000年的时候，脚本很难通过暴力破解去尝试8个字符的所有组合可能——毕竟大概要花三年时间才有机会找到一个正确的。不过随着算力的增长，从2017年开始，同样的工作量可能半天就能完成了。

所以，如果在上世纪90年代，8个随机字符，每个季度更换一次，很大概率能让暴力破解无功而返。而由于加一个字符就能产生的指数级增长，在2000年一个10位字符的口令就需要800年才能破解，15个字符的组合可能就要几十亿年。因此，过去的指导内容都不涉及口令长度，只涉及内容。但是现在黑客使用的机器每秒能尝试十兆的次数，因此8位字符的口令可能数秒就被破解了。不过，15位的字符依然几百万年都猜不到。

从今天的技术角度来看，最好的口令是那些特别长的 ——大于等于15个字符的口令能很大概率躲过字典的暴力破解。由于口令长度增加的复杂性使得黑客很难从海量的组合当中成功破解——至少在更快的计算模型出现之前做不到。今后，不同的合规要求也会紧跟其后，对口令长度提出要求。

口令保密箱

如果说口令有15个字符串或者更长的长度，那是否有大写字母、数字或者一个特殊符合就并不那么重要了——仅仅因为字典本里还没有这样的口令。在安全角度保障以后，使用的便利性就成为另一个考虑因素了。像“Ea429%kkpRT22&!”这样的口令可能成为你下一个建议改变的口令，但对有些人会成为一个麻烦——毕竟他们一天要输入好几次，还得几个月换一次。解决这个问题的方法暂时来看只能通过口令保密箱。不过如果使用同样长度足够的复杂词组口令，就会容易记忆很多——只要你的系统和合规需求接受这样的口令就行。