我为什么要使用弱口令？兼谈对用户口令的保护措施

笔者是网络安全从业人员，深知弱口令在安全认证环节的脆弱性，但我仍在很多地方使用弱口令（除了一些跟资金相关的比较重要的应用），不光是我，相信很多安全从业人员也或多或少的在使用弱口令，普通用户就更别提了。当然，特别重要的应用，如支付宝，就算官方各种诱导（希望大家改为6位数字口令），笔者也坚持不为所动，始终使用的是超长的复杂口令。

用户使用弱口令是出于什么考虑呢？

对于大部分普通用户而言，弱口令好记，而复杂口令很容易遗忘；

但对很多安全从业者而言，在某个网站上使用弱口令，不是不注重安全，而是我不信任你！有的时候，真不能怪用户的安全意识不足。

我不信任你

是的，我不信任你!

我不知道你是如何处置我的口令的。

之前曾经收到过一些注册确认邮件，结果邮件中竟然包含我的明文口令，自此，凡是注册都得小心翼翼，能用弱口令的就先用弱口令。

我的口令是我的隐私，这个数据，它是我的！ It is mine!

它不属于服务提供方。

在我有理由怀疑服务提供方的安全管理做得可能并不怎么样的时候，我首先的考虑就是尽量不注册，如果需要注册，则先用弱口令。

当我觉得服务方可以信任的时候，再改为强度高的口令。

这是笔者作为网络安全从业人员的职业敏感性决定的。

我们不止一次的从各种安全新闻或资讯中看到，弱口令排行榜、用户的安全意识远远不足之类的文章。但试想，作为服务提供方，我们对用户口令的保护真的到位了吗？

明文存储显然与网络安全法（草案）相冲突，存储MD5或SHA-1散列值同样也属于较高的风险，这个也基本被安全圈所普遍接受了（一旦被拖库，那些使用弱口令或之前已泄密的口令的用户，基于在线彩虹表直接秒杀） 。

那么如下场景呢？

（1）存储的不是MD5或SHA-1，而是SHA-256或SHA-512之类的散列值，就算今天还没有现成的彩虹表可供查询，但谁又能知道几个月后会不会有这样的在线服务提供？或者基于已泄露的密码字典进行破解，运行一遍也是分分钟就出来了；

（2）还有，有的应用是在客户端先加密，但是服务器侧竟然就不再加密了，不再加密了有木有？这其实跟明文有什么区别呢！

（3）很典型的一个场景，拿已泄漏的口令逐个去猜。你的应用能够防住吗？也许防住了批量的(用户:密码)对的不断尝试，但你见过还有人拿固定的弱口令去撞用户名的场景吗？我就亲自见证了一个复杂的防撞库规则被人用这样的方式给绕过了！也许还有更多的撞库场景没有被发现。

改进建议

那么，我们的产品怎样才能让用户放心去用，放心的使用强密码？

我从用户和安全人员两个角度，给产品或服务提供方提供几个建议供参考：

1一个公司的全部互联网业务都使用统一的认证接口（即SSO），让用户少记口令；实际上是不是总有那么几个应用，使用的是自带的用户管理模块？这就要求负责SSO认证的团队多加宣传、多提供便利（让SSO集成手册或指导可轻易获取，以方便SSO的推行）；

2.对口令的主保护措施采取加盐HASH，HASH算法采用SHA-2（首选其中的SHA-256或SHA-512）或SHA-3，一定要加盐，并且在任何时候都不要尝试收集或保存用户提交过来的口令（这绝对是给自己找麻烦），以防止信息泄漏之后被轻易破解；

3.防止撞库措施一定要有，很多知名公司都或多或少的存在撞库的问题；包括限制同一台机器的登录频次（如采取 IP + User-Agent 或其它具有唯一属性的头部对客户端计算机进行标识）、启用 CSRF-Token，也要考虑使用固定弱密码来撞用户名的场景；

4.在注册及修改密码界面，告诉用户你是如何保存和使用用户的口令的，让用户放心的使用高强度的口令，至少，如果你的这个应用不是Gmail、支付宝或者微信的话，我是不会放心的把自己常用的复杂口令交给你来保管的。

5.如果已经采取了足够的保护措施，在注册和修改密码界面中的密码字段旁，动态展示用户输入的密码强度，以提醒用户；

6.至少为认证过程相关的页面启用https加密传输通道，或者对口令数据在客户端先加密然后再传输的方式；

7.扫码登录（比如微信的扫码登录，或第三方的扫描登录应用）在改善用户体验和安全性方面有所创新，有条件的话也可以尝试。

当然，也有一些先在客户端作一些预处理以改善安全性的做法，但无论客户端是如何处理的，口令字段在服务器侧写入数据库之前都需要至少有一次HASH动作。

关于“密码将要消失”的相关文章和论点，笔者持有不同意见，拟单独写篇文章，敬请关注。

---

长按并在弹出菜单中选择"识别图中二维码"关注微信公众号: Security_SDL ，共同探讨网络安全体系建设~

原文始发于微信公众号（数据安全架构与治理）：我为什么要使用弱口令？兼谈对用户口令的保护措施