测试小故事14：密码中可以使用空格吗？

  节前公司发了封关于密码安全的邮件，提到常用的密码中，“123456”仍然是高居榜首的惯用密码，成为了众多人的首选。同时也给出了一条建议性的密码规则，如以“来一瓶82年的皇家礼炮”作为密码，则可以设密码为“lyp82ndhjlp”。

  不知道是否真的有效，但一个足够强大的密码的确可以把被识别的风险降低到足够低，却不能完全避免被攻破的风险。

  同时，有关密码的问题也让我联想起之前有关密码设置的讨论：密码中到底能不能使用空格？

  讨论来自于系统发生的故障：密码设置时全部使用空格，但实际使用时发现按设置的密码无法通过验证，并提示密码不能为空。经过确认发现

  1) 在设置密码进行存储时，将密码中的所有空格校验时作为正确密码校验并成功存储。

  2) 在使用密码时，对于空格输入进行了处理，也就是作为明文trim掉了所有的空格，造成前后策略不一致，无法使用。

 

  一般来讲，好的密码应有足够的强度，应当避免常用的习惯，通常来讲会有这么几项要求（这一点个人比较喜欢linux的密码设置规则，强置+自定义）

  1) 密码长度，通常不应太短，8~10位或是更长。

  2) 密码输入限制，数字、字母、下划线、大小写、特殊字符。

  3) 密码复杂度，必须是几种输入限制的组合。

  4) 密码管理规则，如过期限时间，不允许使用旧密码，不允许使用类似“123456”、生日等。

   

  对于密码是否允许输入空格，并没有完全明确的规范（一般来讲，空格和特殊字符是不允许出现在密码设置中的），从系统设计、实现和测试的角度来讲，却需要进行合理的处理，否则设置与使用就会产生出入，给用户带来不便。

  1) 功能实现，从个人观点来讲，如果没有特别的说明应当允许客户自行设置用户密码。

  2) 易用性/可用性，应在设置密码出给出明确的提示或是说明文字，指导客户按系统规则设置密码。

  应绝对避免输入的密码经过验证通过后，在使用时无法正确输入或是验证的情况出现。（这一般是由于密码的设置与使用规则不一致造成的。）

  3) 安全性，应在第一时间对密码的安全性进行校验，让密码满足一定的复杂度，同时在规定时间内要求对密码进行重置，并提醒使用者注意密码安全问题。（这一点银行系统对于客户密码的管控规则相对全面。）   

-------------------------------------------------------------------------------------------------------------------------------

  无论什么样的密码策略，应当与系统的安全级别要求，用户使用系统的易用性相匹配。

  至于，密码中是否允许使用空格，还是保持系统一致性吧，至少让系统用户不至于迷惑，系统可以正常运行。