一、问题总结

您需要确保用户的密码足够强，以防止恶意攻击。

二、截图示例

三、参考用法

• 当希望用户为他们的用户帐户选择难以破解，或由人或计算机帮助猜测的密码时使用。
• 当希望增加用户密码的复杂性，并提高攻击者篡改系统的障碍时使用。
• 当希望确保用户知道什么是好的密码，并且他们选择的密码遵循这样的指导原则时，可以使用。

四、解决方案

密码的强度是根据预定义的规则测量的，并且在输入字段旁使用水平缩放显示。 如果密码很弱，则只突出显示水平条的一小部分。 密码的强度越大，水平条就越突出显示。

同时，密码强度也适当地指示，方法是将栏用颜色联想到「好」或「坏」: 绿色表示强密码，红色表示弱密码。

4.1 要多高的密码强度？

强密码的定义可能会引起激烈的争论。一个强制性的复杂密码乍一看只会增加安全性，但若强制性做得过于复杂，那么严格的密码规则可能会产生相反的效果。随着密码被迫变得越来越复杂，用户也越来越难记住它们。这有时会导致增加的安全性的自我毁灭，因为一些用户只是简单地将它写在一个小便签上，然后粘贴到他们的屏幕上，以便记住他们的新复杂密码。这在那些每3个月强制更新密码的地方尤其成问题。

4.2 什么是强密码？

考虑到以上所述，应该强调，一个足够强大的密码不一定需要满足以下所有的规则，只需少数几个做到即可，或只有少数几个可以做到。根据以下几点，可以看作当每个密码遵循的规则数每增加一点，密码强度级别则可增加一级（最弱 0 级，最强 5 级）：

• 超过 8 个字符；
• 包含大、小写字母；
• 至少包含一个数字字符；
• 包含特殊字符；
• 超过 12 个字符。

这也将导致 6 个级别的密码强度，取决于有多少上述标准/规则被满足。

4.3 字典攻击（Dictionary attacks）

尽管只需使用客户端 javascript 便可以轻松完成上述密码检查，但它无法防止字典攻击。为了简化密码的记忆，人们倾向于使用真实的单词作为密码，而且也仅仅是用数字或特殊字符替换字符。此类密码的一个典型例子便是：「p@sw0rd」，它实际上并不是一个强密码。现代密码破解软件相当擅长猜测/破解这种数字、字母的替换。如果要检查这种密码的强度，将需要进行 ajax 的调用，它可以用来检查用户或自己的密码是否为强密码。

4.4 选择适当级别的密码强度

我们可以根据需要保护的内容，来确定密码的强度和复杂性，即对于内容的密级划清界限。对于 99% 的内容，可以相对准确的说，仅仅满足 2~3 条规则就足够了。

4.5 选择密码的一般准则

• 使用看似随机选择的字母、数字组合的密码。
• 使用自己无需看键盘就可以输入的密码（减少别人偷看密码的可能性）。
• 定期更改密码。
• 不要使用网络 ID（大写、反转、翻倍等）。
• 不要使用自己名字、姓氏、中间名、曾用名，或其他人的姓名。
• 不要使用自己姓名的首字母，或其他人可能拥有的昵称。
• 不要使用任何词典（中外文）、拼写表、缩写表等中包含的字词、单词。
• 不要使用他人可以轻易获取的个人信息（车牌、宠物名、出生日期、电话号码等）。
• 不要使用单纯的字母、字符、数字密码，而是将它们混合使用。
• 不要使用键盘序列（例如：qwerty或asdf）。

五、基本原理

通过在密码字段旁显示一个密码强度计，迫使用户考虑使用具有适当强度的密码。而且通过设置一个最低限度级别的密码强度，我们甚至可以使用密码强度计，来增强网站/产品的安全性。

在产品上使用密码强度计，可以使产品具备更高级别的安全性。这不仅可以让当前产品的用户感到更加安全，而且潜在客户在决定与公司进行业务开展和往来时，可能以此作为一个必要前提。

附录

案例

说明

概述：使用户的密码足够强（难于破解），从而使用户获得足够的安全度和安全的心理感受。

何时应用：当用户需要设置密码时，希望用户输入足够复杂的密码，保证账户的安全性和用户的心理安全感。

具体描述：输入密码时，如果用户的密码不符合密码强度要求，则给出错误的原因和正确的例子，并在用户完成设置后提示用户以安全方式保存 。

建议：一般来说，安全的密码需要足够的长度（如8字符长），包含大小写字母和数字，更高的要求是包含下划线、特殊符号（如*、&、$等）。

为何支付宝、微信没有加入密码强度计？

因为支付宝和微信并不需要高强度密码，原因如下：

1. 有法律保护；
2. 有多重技术保障；
3. 有保险公司赔付；

4. 同时普通人对高强度密码认识也非常差。

   
   理论上超过8位的字母、数字、特殊符号密码，AES256位加密，以现在的巨型计算机算力，需要20万年才能破解。
   
   所以实际上，支付宝、微信，包括 TouchID、FaceID 都有接近百分之零点三的失效率。现在流行的方案叫做双密钥加密，公私钥，也就是所谓区块链的基础。

当然，也包括支付宝的支付密码，都没有做强度限制，只有最基本的长度限制。想着是因为根本没考虑被盗的问题，也不需要考虑。

那这里就又涉及到另外一个方面的问题，像是金融公司、银行等等做密码强度限制的，他们是为了给用户一个心理安慰吗？

这里就说到有些公司是必须要做的，比如租赁服务器那种，服务器密码都是20位起步。因为技术领域是高风险，法律不管，保险也不管，所以密码要求都极高。还有一个是国情特色，就是信用卡，只要你设了密码，那么丢了钱，就用户自己负责了，而他们又要求必须设置密码。

PS：换句话说，国内银行的信用卡，你丢钱银行就是不赔的，但是，你不还钱绝对不好使。

同时，极高风险的密码，一般是不太用复杂交互的。就像民航的系统，没有界面，只有命令，操作员必须背下一整本手册，基本没有点错的机会。

通过案例描述它的具体设计方案

对于例子中的事件、动作、状态尝试进行描述，先从状态开始考虑，那么需要几种状态呢？也就是说，这个密码强度计和密码输入框，一共要有几种样子？

首先是默认状态，也就是正常、空、等待输入；然后是正确状态、错误状态，还有异常状态。

在这个例子中，什么是错误？什么是异常？还有，检测应该是在什么时候开始呢？换句话说，什么事件会触发检测？

如果开始输入，就开始检测，那么是不是应该有一个状态，不引起用户的焦虑（不是错误提示）。实际上，密码强度计的事件，包括以下几种：

1. 默认状态，不显示或显示（密码应该复杂）；
2. 输入中，每输入一个数字，检测一次，并给出检测结果和建议；
3. 完成输入，比如密码框失去焦点（点击了其它区域）。

如果不填，就开始填下一个了，那是不是也应该有提示？即现在有用户名、密码、昵称，如果我填完了用户名，直接填昵称，是不是应该有提示？

也就是说，昵称上面应该绑定一个事件：

• 「当昵称框激活时，检测密码框是否为空」。如果为空，则提示「请设置密码」。

所以交互要考虑各种情况，多用的方式，是引入维度，然后考虑极限值、特殊值。比如时间维度，时间特别长、特别短，或者1、2、5分钟，各会怎样？

长时间不填写，一样可以设置一个事件：

• 事件是：「当昵称框激活时」，动作是「弹出请提示密码」。

值维度：缺少、零、极限多等等。 事件：可理解为条件。 动作：是执行的具体内容。

动作肯定不是人的操作，一定是系统发出的。人的操作一般都是事件和交互，不可能叫做动作的。比如说，「输入框」执行了动作「弹出提示」，你不能说「人」执行了动作「弹出提示」。

人只能通过交互「触发事件」。当事件发生时，与其对应的动作就发生。

为什么要把动作和事件分开呢？因为可能存在多个事件，触发一个动作；或者一个事件，同时触发多个动作。举例：事件1被点击，触发动作1变红；事件2鼠标滑过，触发动作1变红。红与不红是两个状态。

同时事件不一定是交互引发的。比如内部计时器，你不管它，它也会触发事件。比如「网页已经打开20秒，用户未下滚」，有些新闻网站，会有这种设计，如果你不滚动，它会给你推更多新闻或广告。

每一种网页前端，会有一种事件触发器，最常见的是JSJavaScript事件触发器，比如「窗口缩小时」，「开始5秒后」。在JS的DOM模型里，包含了所有事件触发器，当然，是网页的。

事件不允许出现「多个事件综合为一个事件」。一个事件可以有多个条件，比如「点击框体的同时按下ALT键」是可以的。但绝对不允许「事件1和事件2」发生出发动作3，因为这会导致代码混乱。

动作是可以发生多个的。

总得来说，理论无所谓，主要是更需要看在实际项目中的实践。我们的交互，必须要在覆盖尽量多的场景有效，且不出现负面作用，或尽量少的负面作用。

其它

现在我们可以把事件和条件，当成一种东西。反馈必须和交互直接联系。

例子：弹出「提示设置密码」是反馈。那么，当点击按钮之后按钮变红，弹出提示「设置密码」，这两个动作，哪个是反馈？这两个动作，分别是针对哪个东西出现的反馈？

点击的反馈是按钮变红，这个相信是都可以理解的，因为变红证明已经点击了。而弹出设置密码，是「输入错误」的反馈。弹出提示也是状态变化，严格来说，动作就是「切换状态」。

现在，我们只要像这样一句一句的写：

1. 点击按钮变红；
2. 点击时如果值错误，则弹框；
3. 点击时如果值正确，则跳转下一页。

因为我们的最终目的，是写明白所有可能会发生的事情，我们用户动作事件系统来写，还是自然语言写，本质上是没有区别的。

「30秒」是条件，「页面打开30秒」是事件，「加载图片」是动作，实际上是个事件分拆的问题。比如说「页面打开30秒」这个事件，是包含了一个主体、一个参数的，主体是「页面」，参数是「30秒」，严格来说，是「页面打开」且「足够30秒」，才执行「动作」。换句话说，双重条件合并的事件。

上述内容看下来，可能会有一种条件、事件、交互、反馈、动作、状态等等都没有特别明确的关系。当然，是的，没有，它们都可以独立发生，除了反馈。

而且在反馈这里，反馈没有必要全部罗列出来，甚至完全可以不写，直接合并到动作里。比如说按钮变红，这本质上就是反馈了，但它同时也是切换状态和动作。

链接

[1] 原文地址