NIST新密码策略的实际应用

Question

我以前曾询问过NIST特别出版物800-63-3 (密码政策)的应用情况.密码策略

如果没有一种向AD添加密码黑名单的简单方法，那么在现实世界中实现这些建议( https://pages.nist.gov/800-63-3/ )的共同策略是什么？我正在尝试重写内部密码策略，但是如果没有这个策略(什么似乎是一个完整的部分)，我不确定混合策略是否会更好？

Answer 1

其他战略不仅难以实施，而且可能与NIST 800-63b的意图背道而驰。幸运的是，有多种黑名单解决方案，所以您可能不需要(或希望)另一种策略。

这是我的推理。

首先，从800-63b第5.1节对直接适用于检查用户密码质量的验证器(例如密码)进行总结。

要求：

• 验证器(密码)必须是：
  • 最少8个字符

• 验证者还使用“已知常用的、预期的或受损的值”(您的问题的核心)来检查黑名单--至少有一个是：。
  • 从先前入侵身体中获得的密码
  • 字典词
  • 重复或顺序字符(例如‘aaaaaa’，‘1234 e.g.’)
  • 特定于上下文的单词，例如服务的名称、用户名及其派生词。

• 如果在黑名单中找到：
  • 通知订阅者，他们需要选择不同的秘密。
  • 提供拒绝的理由
  • 要求订阅服务器选择不同的值。

根据我的理解，800-63b第5.1条的意图似乎是：

• 首先防止用户使用黑名单上的密码
• 培训用户理解为什么密码选择不佳

如果不能直接通过更改密码的接口实现这一点，其他策略将需要通过人工策略来实现这些目标。这将需要：

• 用户在黑名单中查找密码的另一种方式。由于Windows密码更改界面是由设计专用和隔离的，因此提供一种数字方式来实现这一点将很困难(而打印一本书将是一个可用性和可维护性的噩梦！)
• 一种事后审核遵从性的方法(使用黑名单作为字典破解密码)。无论如何你都应该这么做..。但在这种情况下，我认为它违背了NIST指南的目的(确保黑名单上的密码一开始就不会被使用)

幸运的是，如果只需要执行以下操作，则不需要其他策略：

• 验证最小长度。库存AD复杂性要求已经允许这样做了。
• 实施黑名单。有两个商业(Anixis，等等)和自由和开放源码软件(https://github.com/jephthai/OpenPasswordFilter)解决方案。

换句话说，替代策略不仅是不需要的--它们是不切实际的，提供了困难的用户体验.而且可能实际上并不符合防御标准。