随着大语言模型在开发工作流中的渗透率持续攀升，一个被严重低估的安全风险正在浮出水面：开发者与 AI 编码助手越来越频繁地直接采用 LLM 输出的密码作为凭证。安全公司 Irregular 于 2026 年初发布的实证研究揭示了一个令人不安的事实 —— 主流 LLM 生成的「安全」密码在结构上存在系统性脆弱性，其实测熵值较真随机密码低 4 到 6 倍，可在数小时内被暴力破解。这一发现对当前 AI 辅助开发实践构成了直接的安全警示。
实证发现：数字背后的安全真相
Irregular 团队对 Claude、ChatGPT 和 Gemini 三款主流大语言模型进行了系统性密码生成测试。测试方法如下：分别指示每个模型生成包含特殊字符、数字和大小写字母的 16 字符密码，在 50 次独立对话中各生成一次。这一设计旨在检验模型在不同会话上下文下的输出多样性。
测试结果揭示了令人担忧的结构性缺陷。Claude Opus 4.6 在 50 次独立生成中仅返回了 30 个唯一密码，其中 18 个是完全相同的字符串，重复率高达 40%。更值得关注的是，几乎所有生成的密码都呈现出可识别的首尾字符模式 —— 这意味着攻击者即使不知道完整密码，也只需猜测中间部分即可大幅缩小搜索空间。研究人员还发现，所有 50 个密码中不存在任何重复字符，这一特征本应增加随机性，但实际上恰恰暴露了模型对「无重复」规则的过度遵循，反而成为可被利用的识别指纹。
在熵值分析方面，研究团队采用两种独立方法进行估算：基于字符统计的香农熵公式，以及基于模型自身 log probabilities 的条件熵。两类方法得出了一致的结论 ——LLM 生成的 16 字符密码实际熵值仅为 20 到 27 比特。作为对照，真随机生成的同等长度密码使用字符统计方法应达到约 98 比特熵值，而考虑 log probabilities 的理论上限则高达 120 比特。这意味着 LLM 密码的有效随机性仅为理论值的五分之一左右。
脆弱性根源：语言模型的目标函数矛盾
理解 LLM 密码脆弱性的关键在于认识其训练目标与密码安全要求之间的根本性冲突。语言模型的核心优化目标是生成「 plausibility」—— 即在统计意义上看起来像人类会写出的文本。这一目标要求模型学习并复现自然语言中的 token 序列规律，而密码安全的核心要求恰恰相反 —— 消除一切可预测的序列模式，实现真正的均匀分布。
这种目标函数的矛盾无法通过简单的工程技巧加以弥合。研究团队明确指出，无论是调整 prompt 措辞还是修改 temperature 参数，都无法从根本上解决这一问题。因为模型的生成机制决定了它必然倾向于输出高概率的 token 序列，而密码安全要求的是低概率甚至零概率的字符组合。当用户要求生成「随机」密码时，模型并非从真随机源采样，而是从其语言建模的输出分布中抽样 —— 这本质上是一种「看起来随机」而非「真正随机」的序列。
此外，模型训练数据中的模式也会被隐式编码到生成结果中。即使 prompt 中未明确指定格式要求，模型也会倾向于生成符合训练语料中常见模式的字符串。例如，模型可能更频繁地使用某些特定字符组合作为单词边界，或在特定位置放置数字和特殊字符，这些偏好构成了可被攻击者利用的结构性弱点。
工程级影响评估与攻击场景
从工程实践角度评估，LLM 密码脆弱性的影响范围远超个人用户。随着 AI 辅助编程工具的普及，越来越多的开发者开始使用 Cursor、Windsurf 等 AI 编码助手，这些工具在生成代码时可能直接嵌入 LLM 创建的凭证。在 GitHub 公开仓库和开源项目中，研究人员已经能够通过搜索常见的 LLM 密码字符模式识别出大量可疑的硬编码凭证。
具体的攻击场景可以分为两个层面。在离线攻击层面，攻击者可以基于目标 LLM 的输出模式构建定制化的密码字典。与传统的字典攻击不同，这种攻击利用的是模型的结构性偏好。例如，如果攻击者已知目标系统可能使用了 Claude 生成的密码，他们可以构建一个优先考虑特定首尾字符组合的缩小搜索空间，将暴力破解的计算复杂度降低数个数量级。研究团队的实测表明，基于 LLM 模式知识的暴力破解在普通个人计算机上仅需数小时即可完成，而非传统评估所称的「数百年」。
在在线攻击层面，虽然账户锁定策略会限制尝试频率，但攻击者可以使用 LLM 生成的凭证进行凭证填充攻击（credential stuffing）。由于多个用户可能从同一模型获取相同或相似的密码，这种攻击具有较高的成功概率。实际上，研究中发现的 40% 重复率意味着攻击者只需尝试少量「热门」LLM 密码变体即可获得显著的命中机会。
生产环境缓解方案
针对 LLM 密码脆弱性问题，工程团队应采取分层防御策略。首先，也是最根本的，是在开发流程中完全禁止使用 LLM 直接生成生产凭证。所有密码、API 密钥和加密密钥必须通过操作系统级别的加密安全随机数生成器（CSPRNG）产生。在 Python 环境中，应使用标准库 secrets 模块而非 random 模块；在 Node.js 环境中，应使用 crypto.randomBytes 或 crypto.generateKeyPair；在 Java 环境中，应使用 java.security.SecureRandom。
其次，对于必须使用 AI 辅助的场景，建议采用间接调用模式。不应要求 LLM 直接输出密码，而应指示模型生成调用 CSPRNG 的代码片段。例如，可以要求模型「生成一段使用 Python secrets 模块创建 32 字节随机令牌的代码」，然后审查并执行该代码而非直接使用模型输出的字符串。这种模式既利用了 AI 的代码生成能力，又保证了凭证的加密安全。
第三，对于存量凭证的审计与轮换是必要的安全措施。安全团队应检查代码仓库、配置文件和环境变量中是否存在可能由 LLM 生成的凭证。具体的审计指标包括：是否存在大量具有相似首尾字符模式的字符串、是否存在符合特定 LLM 输出风格的字符组合（如特定位置的数字插入模式），以及是否存在在多个地方重复使用的凭证。任何可疑凭证都应立即轮换。
第四，在组织策略层面，应将 LLM 生成的凭证纳入敏感信息管理范围。这包括在 CI/CD 管道中集成凭证检测扫描工具，在代码审查流程中添加凭证模式检查，以及对开发者进行 LLM 安全局限性的培训。Anthropic CEO Dario Amodei 此前曾预测，AI 将在未来编写大部分代码 —— 如果这一趋势成为现实，那么确保 AI 生成的代码不包含弱凭证将成为应用安全的核心挑战。
监控指标与检测阈值
在运营层面，安全团队可以建立以下监控指标以检测可能的 LLM 凭证泄露事件。密码唯一性监控应关注同一时段内新创建凭证的去重率 —— 如果批量生成的凭证存在大量重复，可能表明使用了非 CSPRNG 的生成方式。熵值分布监控应对每个新凭证计算实际熵值，设定低于 60 比特的告警阈值（考虑字符集限制的实际安全阈值）。字符模式监控应检测首尾字符的频率分布异常 —— 如果大量凭证共享相同或相似的首尾字符组合，应触发安全审查流程。
综合来看，LLM 密码脆弱性并非一个可以通过优化 prompt 或调整模型参数来解决的技术问题，而是反映了生成式 AI 与密码安全之间不可调和的目标冲突。在 AI 辅助开发成为常态的时代，工程团队必须对此保持清醒认识，将 CSPRNG 设为唯一的凭证生成来源，并在开发流程的每个环节贯彻这一原则。
资料来源：The Register 2026 年 2 月报道，基于 Irregular 安全公司的实证研究。