2025 年密码强度要求：NIST 指南与最佳实践

近年来，密码策略经历了根本性的转变。旧规则 — 强制特殊字符、强制 90 天轮换、安全问题 — 已被 NIST（美国国家标准与技术研究院）正式废弃。取而代之的是基于证据的新方法，重点关注长度、泄露列表检查和多因素认证。本综合指南涵盖了 2025 年现代密码要求的所有知识，从最新的 NIST SP 800-63B 指南到实际实施策略。

1. NIST SP 800-63B：发生了什么变化

NIST 特别出版物 800-63B（数字身份指南：认证和生命周期管理）于 2017 年首次修订，并在 2024 年持续更新。它从根本上改变了组织应该如何思考密码安全。关键洞察：大多数传统密码规则使密码对人类更难记忆，但对攻击者来说并没有明显增加破解难度。

# NIST SP 800-63B Summary of Key Changes
┌─────────────────────────────────────────────────────────────────────┐
│  REMOVED (SHALL NOT)              │  ADDED (SHALL / SHOULD)         │
├───────────────────────────────────┼─────────────────────────────────┤
│  Forced periodic rotation         │  Check against breach lists     │
│  Composition rules (upper+lower   │  Minimum 8 chars (12+ better)   │
│    +digit+special)                │  Allow 64+ character passwords  │
│  Password hints                   │  Accept all Unicode + spaces    │
│  Security questions (KBA)         │  Allow paste in password fields │
│  Truncating passwords             │  Offer "show password" option   │
│  SMS as primary 2FA (restricted)  │  Use approved hash algorithms   │
└───────────────────────────────────┴─────────────────────────────────┘

2. 最小长度：8 位已过时，12-16 位是新标准

NIST SP 800-63B 要求用户选择的密码最少 8 个字符，但安全专家和现代框架已经远远超过这个底线。数学现实很简单：每增加一个字符，攻击者必须覆盖的搜索空间就呈指数级增长。

以下是在假设 95 个可打印 ASCII 字符且攻击者以每秒 100 亿次尝试（现代 GPU 集群对快速哈希）进行暴力破解时，密码长度如何影响暴力破解时间：

各组织的现代建议：

• NIST SP 800-63B：最少 8 字符（但建议允许最多 64 字符以上）
• OWASP：最少 8 字符，建议 12 字符以上
• PCI-DSS v4.0：最少 12 字符（从 v3.2 的 7 字符提高）
• Microsoft：Azure AD 最少 12 字符
• Google：最少 8 字符，建议 12 字符以上

3. NIST 推荐什么：允许所有字符、检查泄露列表、无提示

NIST 指南采取了与传统密码策略根本不同的方法。它们不是让密码难以创建，而是专注于让密码难以猜测。

4. NIST 移除了什么：强制特殊字符、定期过期、安全问题

理解被移除的内容与理解被添加的内容同样重要。每个被移除的要求都基于研究证明是错误的假设。

5. 熵计算器：如何以比特为单位估计密码强度

密码熵以比特为单位衡量密码的不可预测性。更高的熵意味着密码更难猜测。熵的计算公式为：H = log2(R^L)，其中 R 是字符池的大小，L 是密码长度。

# Password Entropy Formula
H = log2(R^L) = L * log2(R)

Where:
  H = Entropy in bits
  R = Size of the character pool
  L = Password length

# Example: 12-character password using full ASCII (95 chars)
H = 12 * log2(95) = 12 * 6.57 = 78.8 bits

# Example: 4-word Diceware passphrase (7776-word list)
H = 4 * log2(7776) = 4 * 12.92 = 51.7 bits

字符池大小

常见密码类型的熵计算

2025 年目标熵级别：

• 在线攻击（限速）：有账户锁定的情况下 30+ 比特就足够
• 离线攻击（被盗哈希，快速哈希）：至少 60+ 比特
• 离线攻击（被盗哈希，Argon2id）：40+ 比特可以接受
• 高安全账户：建议 80+ 比特

6. 对比表：NIST vs OWASP vs PCI-DSS vs 旧标准

不同的标准和框架有不同的要求。以下是截至 2025 年的比较：

7. 密码短语 vs 密码：为什么 "correct horse battery staple" 胜出

著名的 XKCD 漫画（#936）有力地支持了密码短语优于传统密码的观点。数学支持这一点：从 7,776 个词的 Diceware 列表中随机选择的 4 个词的密码短语具有 51.7 比特的熵 — 与随机的 8 字符混合大小写字母数字密码相当 — 同时更容易记忆。

密码短语与传统密码比较

密码短语更好的原因：

• 相等或更大的熵：4 个词的密码短语在熵方面与 8 字符的随机密码相当。6 个词的密码短语超过大多数传统密码。
• 更容易记忆：人类更擅长记住词语序列而非随机字符。密码短语创造了心理图像。
• 更容易输入：特别是在移动设备上，输入单词比在字符类型之间切换更快且更不容易出错。
• 抵抗肩窥：一长串单词比短的随机字符串更难从短暂一瞥中记住。
• 自然很长：即使 4 个词的密码短语通常也有 20+ 字符，提供了对暴力破解攻击的出色保护。

如何生成 Diceware 密码短语：

1. 获取一个 Diceware 词表（7,776 个词，每个对应一个 5 位骰子数）。
2. 为每个需要的词掷 5 个骰子（或 1 个骰子掷 5 次）。
3. 在词表中查找每个 5 位数字。
4. 用空格组合这些词。这就是你的密码短语。
5. 对于大多数用途，5-6 个词提供出色的安全性（64.6 - 77.5 比特）。

# Diceware passphrase generation example
$ dice rolls: 1-6-2-3-4  →  "atlas"
$ dice rolls: 5-4-1-1-6  →  "usable"
$ dice rolls: 2-5-3-1-2  →  "flock"
$ dice rolls: 2-1-4-6-5  →  "dizzy"

Passphrase: "atlas usable flock dizzy"
Entropy: 4 * log2(7776) = 51.7 bits
Length: 24 characters (spaces included)

# Compare to traditional password
"j7#Kp!2x" = 8 chars * log2(95) = 52.6 bits
# Same entropy, but much harder to remember and type!

8. 实施密码策略：Bcrypt 成本、速率限制、MFA

了解指南是一回事；正确实施是另一回事。以下是在 2025 年实施符合 NIST 标准的现代密码策略的实用清单。

密码哈希

选择 Argon2id 作为主要哈希算法。如果 Argon2id 不可用，使用成本因子 12 或更高的 bcrypt。在生产硬件上目标每次哈希 200-500ms。永远不要使用 MD5、SHA-1、SHA-256 或任何快速哈希函数进行密码存储。

// Argon2id configuration (OWASP recommended)
const argon2 = require('argon2');

const hashConfig = {
  type: argon2.argon2id,
  memoryCost: 19456,    // 19 MiB
  timeCost: 2,          // 2 iterations
  parallelism: 1,       // 1 thread
};

// Hash on registration
const hash = await argon2.hash(password, hashConfig);

// Verify on login
const isValid = await argon2.verify(hash, password);

// ── Bcrypt alternative (if Argon2 unavailable) ──
const bcrypt = require('bcrypt');
const COST_FACTOR = 12;  // Target: 200-500ms

const bcryptHash = await bcrypt.hash(password, COST_FACTOR);
const bcryptValid = await bcrypt.compare(password, bcryptHash);

速率限制

在认证端点实施速率限制以防止在线暴力破解攻击。在 5-10 次失败尝试后，引入渐进延迟或临时账户锁定。在 3 次失败尝试后使用 CAPTCHA。实施基于 IP 的速率限制（例如每个 IP 每小时 100 次尝试）和基于账户的速率限制（例如每个账户每 15 分钟 10 次尝试）。

// Rate limiting example (Express.js with express-rate-limit)
const rateLimit = require('express-rate-limit');

// IP-based rate limiting
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,  // 15 minutes
  max: 10,                     // 10 attempts per IP per window
  message: 'Too many login attempts. Please try again later.',
  standardHeaders: true,
  legacyHeaders: false,
});

// Account-based rate limiting (in-memory example)
const accountAttempts = new Map();

async function checkAccountRateLimit(username) {
  const key = username.toLowerCase();
  const attempts = accountAttempts.get(key) || { count: 0, lastAttempt: 0 };

  if (attempts.count >= 5) {
    const cooldown = 15 * 60 * 1000; // 15 minutes
    if (Date.now() - attempts.lastAttempt < cooldown) {
      throw new Error('Account temporarily locked. Try again later.');
    }
    attempts.count = 0; // Reset after cooldown
  }

  return attempts;
}

app.post('/login', loginLimiter, async (req, res) => {
  const { username, password } = req.body;
  const attempts = await checkAccountRateLimit(username);

  const isValid = await verifyPassword(username, password);

  if (!isValid) {
    attempts.count++;
    attempts.lastAttempt = Date.now();
    accountAttempts.set(username.toLowerCase(), attempts);
    return res.status(401).json({ error: 'Invalid credentials' });
  }

  accountAttempts.delete(username.toLowerCase());
  // ... generate session / JWT
});

多因素认证 (MFA)

MFA 是对抗基于凭证攻击最有效的单一防御。即使攻击者获得了密码（通过网络钓鱼、泄露重用或暴力破解），MFA 也能阻止未授权访问。优先选择基于应用的 TOTP（Google Authenticator、Authy）或硬件密钥（YubiKey、Passkeys），而非基于 SMS 的 2FA。

服务端验证清单

Bcrypt / Argon2id 成本调优

成本参数应根据你的特定硬件进行调优。在生产服务器上运行基准测试，选择使每次哈希耗时 200-500ms 的成本。这在用户体验（登录延迟）和攻击者成本之间提供了良好的平衡。

# Benchmarking password hashing on your server
# Goal: 200-500ms per hash

# Node.js benchmark script
const argon2 = require('argon2');
const bcrypt = require('bcrypt');

async function benchmark() {
  const password = 'benchmarkPassword123';

  // Argon2id benchmarks
  for (const mem of [19456, 47104, 65536]) {
    const start = Date.now();
    for (let i = 0; i < 10; i++) {
      await argon2.hash(password, {
        type: argon2.argon2id,
        memoryCost: mem,
        timeCost: 2,
        parallelism: 1,
      });
    }
    const avg = (Date.now() - start) / 10;
    console.log(`Argon2id (m=${mem}): ${avg.toFixed(0)}ms`);
  }

  // Bcrypt benchmarks
  for (const cost of [10, 11, 12, 13, 14]) {
    const start = Date.now();
    for (let i = 0; i < 10; i++) {
      await bcrypt.hash(password, cost);
    }
    const avg = (Date.now() - start) / 10;
    console.log(`Bcrypt (cost=${cost}): ${avg.toFixed(0)}ms`);
  }
}

benchmark();

# Expected output (varies by hardware):
# Argon2id (m=19456): ~150ms
# Argon2id (m=47104): ~350ms   ← Good target
# Argon2id (m=65536): ~500ms
# Bcrypt (cost=10):   ~75ms
# Bcrypt (cost=11):   ~150ms
# Bcrypt (cost=12):   ~300ms   ← Good target
# Bcrypt (cost=13):   ~600ms
# Bcrypt (cost=14):   ~1200ms

9. 检查泄露数据库：Have I Been Pwned API、k-匿名性

NIST 最具影响力的要求之一是检查密码是否在已知泄露数据库中。Have I Been Pwned (HIBP) 密码 API 使用一种称为 k-匿名性的技术，使这一过程既实用又保护隐私。

k-匿名性如何工作

HIBP 密码 API 从不查看实际密码甚至完整哈希。相反，它使用基于 SHA-1 哈希前 5 个字符的范围搜索：

1. 用 SHA-1 对密码进行哈希（仅用于查找，不用于存储）。
2. 仅将十六进制编码哈希的前 5 个字符发送到 HIBP API。
3. API 返回所有匹配 5 字符前缀的哈希后缀（通常 500-800 个结果）。
4. 在本地将完整哈希与返回的后缀进行比较。
5. 如果找到匹配，则该密码已在泄露中出现。拒绝它。

// Check password against Have I Been Pwned API (Node.js)
const crypto = require('crypto');

async function isPasswordBreached(password) {
  // Step 1: SHA-1 hash the password
  const sha1 = crypto.createHash('sha1')
    .update(password)
    .digest('hex')
    .toUpperCase();

  // Step 2: Split into prefix (5 chars) and suffix
  const prefix = sha1.substring(0, 5);
  const suffix = sha1.substring(5);

  // Step 3: Query the HIBP API with only the prefix
  const response = await fetch(
    `https://api.pwnedpasswords.com/range/${prefix}`,
    {
      headers: { 'Add-Padding': 'true' }  // Prevents response-length analysis
    }
  );
  const text = await response.text();

  // Step 4: Check if our suffix appears in the results
  const lines = text.split('\n');
  for (const line of lines) {
    const [hashSuffix, count] = line.split(':');
    if (hashSuffix.trim() === suffix) {
      return {
        breached: true,
        count: parseInt(count.trim(), 10),  // How many times seen
      };
    }
  }

  return { breached: false, count: 0 };
}

// Usage in password validation
async function validatePassword(password, username) {
  // Check length
  if (password.length < 12) {
    return { valid: false, reason: 'Password must be at least 12 characters.' };
  }

  // Check against username / email
  if (password.toLowerCase().includes(username.toLowerCase())) {
    return { valid: false, reason: 'Password must not contain your username.' };
  }

  // Check against breach database
  const breach = await isPasswordBreached(password);
  if (breach.breached) {
    return {
      valid: false,
      reason: `This password has appeared in ${breach.count.toLocaleString()} data breaches. Please choose a different password.`,
    };
  }

  return { valid: true };
}

截至 2025 年，HIBP 密码数据库包含超过 9 亿个唯一的已泄露密码。如果用户尝试设置出现在此列表中的密码，应该用清晰的解释拒绝它。

HIBP 的替代方案

10. 密码管理器推荐

随着密码变得更长且更独特（从不在站点间重复使用），密码管理器不再是可选的 — 它们是必需的。密码管理器为每个账户生成、存储和自动填充强大的唯一密码。

为什么密码管理器至关重要：

• 普通人有 100 多个在线账户。没有人能记住 100 个独特的强密码。
• 密码重用是基于凭证泄露的首要原因。密码管理器完全消除了重用。
• 密码管理器生成具有最大熵的真正随机密码，而非人类可预测的模式。
• 自动填充防止网络钓鱼：密码管理器不会在相似的钓鱼域名上填充凭证。

11. 常见问题