后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载密码是大多数系统认证体系的基石但把密码存进数据库这件事本身藏着大量安全陷阱。本文以 如何安全存储密码指南 为核心骨架系统讲解为什么不能明文存储、为什么单纯哈希也不够、加盐Salt的原理与存储格式以及完整的密码校验流程并结合仓库中 敏感数据管理、编码/加密/令牌化对比、密码管理器原理 等相关文档把密码存储这件事从会做提升到知其所以然。读完你将能设计出一套可防御彩虹表、字典攻击和拖库泄露的密码存储与校验方案。一、绝对不能做的事明文存储与裸哈希原指南开篇就用Things NOT to do的方式点出了两种必须规避的做法这也是设计密码存储时最先要建立的底线思维。1. 明文存储Plain Text明文存储意味着任何能访问数据库的人——无论是 DBA、运维、被拖库后的攻击者还是拿到数据库备份的第三方——都能直接看到所有用户的密码原文。Storing passwords in plain text is not a good idea because anyone with internal access can see them.这里的关键词是internal access。数据库的安全边界远不止防火墙内部人员的越权访问、备份文件泄露、日志误打印都可能导致明文密码成批量外泄。一旦密码原文泄露攻击者还会将其用于撞库——因为大量用户在不同平台复用同一密码单个站点的明文泄露往往引发连锁安全事件。2. 直接哈希存储Bare Hashing把密码经过哈希函数处理后存储看起来比明文进步了但原指南明确指出它仍然不够Storing password hashes directly is not sufficient because it is prone to precomputation attacks, such as rainbow tables.原因是哈希函数是确定性的同一个输入永远得到同一个输出。攻击者可以预先离线计算海量常见密码的哈希值构建成查找表一旦拿到数据库中的哈希值反查即可还原出原文。这类攻击统称为预计算攻击Precomputation Attack其中最典型的形态就是彩虹表Rainbow Table——它用时间-空间权衡技术用远小于完整字典的存储量覆盖大量密码空间。更进一步的担忧还在于如果两个用户设置了相同的密码在没有加盐的情况下它们的哈希值完全相同。攻击者仅凭哈希值是否相等就能推断出这两个账号使用了同一密码这种模式本身也是可被利用的信号。二、破解预计算攻击的关键加盐Salt针对上述缺陷原指南给出的解决方案是加盐To mitigate precomputation attacks, we salt the passwords.盐的权威定义引自 OWASP开放式 Web 应用程序安全项目指南a salt is a unique, randomly generated string that is added to each password as part of the hashing process 盐是一串唯一的、随机生成的字符串在哈希过程中被添加到每个密码上。盐需要满足的核心特性要真正达到缓解预计算攻击的目的盐必须满足唯一性Unique每个用户、每次密码设置都应使用不同的盐。全局共用一个盐值会退化为裸哈希固定前缀彩虹表依然可以针对该盐值重新预计算。随机性Randomly Generated盐必须由密码学安全的随机数生成器产生不能是用户 ID、时间戳、用户名等可预测值——可预测的盐会被攻击者提前纳入预计算范围。足够长度实践中通常建议至少 16 字节128 位以上以保证碰撞概率可忽略。三、如何存储密码与盐格式与数据库设计原指南给出了两条关键规则明确了盐与哈希值的存放方式。规则一盐不需要保密A salt is not meant to be secret and it can be stored in plain text in the database. It is used to ensure the hash result is unique to each password.这一点常被误解盐不是密钥它不需要保密可以直接以明文形式与哈希值一同存储。盐的安全价值在于让每个密码的哈希计算路径各不相同从而破坏预计算攻击的复用性而不是依赖自身的机密性。这与仓库中 编码/加密/令牌化对比 强调的原则一致——加密依赖密钥保密、编码无需任何密钥而盐介于两者之间它是公开参数却改变了每个哈希的结果分布。规则二存储格式为 hash(password salt)The password can be stored in the database using the following format: hash(password salt).数据库中的密码字段存储的是hash(password salt)的组合结果而不是密码本身。一个典型的用户表结构如下字段说明示例user_id用户唯一标识u_1001salt该用户的随机盐明文存储f8a2c9...随机字符串password_hashhash(密码 盐) 的结果$2b$12$...哈希值为了让校验流程可执行salt必须和password_hash一起持久化——因为校验时需要拿到同一个盐重新计算哈希再比对。如下是符合该格式的示意图示例值非真实数据┌─────────────────────────────────────────────┐ │ users 表 │ ├──────────┬──────────────────┬────────────────┤ │ user_id │ salt │ password_hash │ ├──────────┼──────────────────┼────────────────┤ │ u_1001 │ k8Rf3xQp... │ a9c2e7d1... │ │ u_1002 │ 7dXw2nLm... │ 5b8f1a3c... │ └──────────┴──────────────────┴────────────────┘ ▲ ▲ │ 明文存储无需保密 │ hash(password salt)需要注意的是hash(password salt) 中的哈希函数在实战中不应是普通的快速摘要算法如裸 SHA-256而应是专为密码设计的慢速密码哈希算法这一点下文会展开。原指南以hash(password salt)的简洁形式表达的是核心思想盐参与哈希计算、结果入库、盐一并保存。为什么这里要区分哈希而非加密仓库文档 编码/加密/令牌化对比 明确指出三者的本质区别编码Encoding可逆且无需密钥如 Base64仅用于数据传输格式转换不提供任何安全性加密Encryption依赖密钥可逆用于保证机密性持有密钥者可还原原文哈希Hashing不可逆的单向变换用于校验完整性——这正是密码存储选择哈希而非加密的原因系统自身也不应该有能力还原用户密码原文。如果密码用可逆的加密存储一旦密钥泄露所有密码原文都会被还原而哈希是单向的即使数据库完全泄露攻击者拿到的也只是不可逆的哈希值。这一设计哲学与仓库中 密码管理器原理 的核心理念一脉相承——即使是服务提供方也无法获知用户的明文密码。四、如何校验密码四步验证流程原指南给出了完整的密码校验流程这是登录场景中每个后端必须实现的核心逻辑A client enters the password.The system fetches the corresponding salt from the database.The system appends the salt to the password and hashes it. Lets call the hashed value H1.The system compares H1 and H2, where H2 is the hash stored in the database. If they are the same, the password is valid.拆解如下第 1 步客户端输入密码——用户在前端输入密码密码通过 HTTPSSSL/TLS传输到服务端。仓库文档 敏感数据管理 强调数据在传输过程中需要使用 SSL 加密这一步是密码安全传输的前提防止密码在网络上被窃听。第 2 步取出对应盐——系统根据用户名/用户 ID 从数据库取出该用户行中的salt字段。第 3 步拼接并哈希得到 H1——系统将盐拼接到密码上执行哈希计算得到临时值 H1H1 hash(用户输入的密码 从数据库取出的 salt)第 4 步比对 H1 与 H2——H2 是数据库里存储的password_hash。若 H1 与 H2 相同说明用户输入的密码正确认证通过否则认证失败。用伪代码表示这一流程示意非仓库源码def verify_password(user_input, stored_salt, stored_hash): h1 password_hash(user_input stored_salt) return constant_time_compare(h1, stored_hash)校验环节的进阶要点时序安全比较原指南只要求相同即有效但在实战中H1与H2的比较应使用恒定时间比较Constant-Time Comparison。普通字符串比较如在发现第一个不匹配字符时就会提前返回攻击者可以通过测量响应时间差异逐字符猜测哈希值时序侧信道攻击。恒定时间比较则无论匹配到哪一位耗时始终一致。多数语言的标准库都提供此类 API如 Go 的crypto/subtle、Python 的hmac.compare_digest。五、从会存到存得对密码哈希算法的正确选型原指南以通用的hash(...)表达哈希过程但用什么函数做哈希直接决定方案的安全等级。这里给出行业通行实践作为背景补充不涉及本仓库实现密码哈希不应使用 SHA-256、MD5 这类面向速度设计的通用摘要算法而应使用专门为密码设计的、内置加盐与工作因子的慢速算法典型代表有bcrypt内置随机盐与成本因子cost factor输出自带算法标识、成本与盐如$2b$12$...是目前应用最广的密码哈希方案之一Argon22015 年密码哈希竞赛的获胜算法可分别调节内存、迭代次数与并行度是当前推荐级别最高的选择PBKDF2基于 HMAC 的密钥派生函数通过迭代次数控制计算成本历史兼容性好scrypt通过内存占用提高攻击者的并行攻击成本。这些算法之所以优于通用摘要核心在于**慢**合法用户每次登录只需等待毫秒级时间但攻击者离线爆破每个候选密码的成本同样被放大几个数量级。bcrypt 的输出格式本身同时携带算法标识、成本因子、盐和哈希值四部分信息可以看作对原指南hash(password salt)格式的工业级实现。值得一提的还有Pepper胡椒这一可选增强与盐不同胡椒是保密的、全局共享的固定密钥在哈希前附加到密码中。即使数据库连同盐一起泄露没有胡椒的攻击者依然无法进行离线爆破。不过它引入了密钥管理问题属于进阶选项原指南并未涉及此处仅作知识延伸。六、把密码存储放进更大的安全图景密码存储不是孤立的技术点它处于整个认证与数据安全体系的关键位置。本仓库的多篇指南共同勾勒出了这幅完整图景1. 密码验证是认证流程的起点在 如何设计安全的 Web API 访问 中密码校验之后紧接着的是令牌Token或 HMAC 签名的签发——用户输入密码 → 认证服务器验证凭据 → 生成带过期时间的令牌。也就是说本文的校验流程是第一步后续的会话管理、令牌签发都建立在其正确性之上。2. 凭据只是四种认证机制之一仓库文档 Top 4 认证机制 将 SSH 密钥、OAuth 令牌、SSL 证书与用户凭据Credentials并列为四种主流认证方式。密码属于其中的凭据类别也是最普遍但最需要小心处理的一种——因为它是可被人类记忆、也因此可被人类猜测和复用的秘密。3. 密码只是敏感数据的冰山一角敏感数据管理指南 指出PII个人身份信息、健康信息、知识产权、财务信息等都属于敏感数据密码只是其中一类。围绕敏感数据该指南还给出了多层防护建议加密与密钥管理传输层用 SSL 加密密码不在数据库明文存储对于密钥可设计申请人、管理员、审计员多方分权持钥机制数据脱敏对外共享数据时进行匿名化处理避免敏感信息连带泄露最小权限通过 RBAC基于角色的访问控制让用户只拥有职责所需的访问权限数据生命周期管理数据开发完成后及时回收开发阶段的访问权限。这些策略共同说明密码哈希加盐是存储层的防线而完整的系统还需要传输加密、密钥管理、权限控制与生命周期治理等多层防线协同这正是 如何设计安全系统 中所列认证、授权、加密、审计与合规等设计要点的落地方式。4. 极端场景密码管理器如何走得更远仓库中的 密码管理器原理 展示了比哈希加盐更进一步的方案密码管理器对保险库内容采用加密而非哈希存储主密码通过 2SKD 等算法派生主解锁密钥MUK服务端甚至无法获知用户密码原文。对比可见普通网站对密码的诉求是不可逆校验密码管理器对密码的诉求是可恢复使用两种场景因此选择了哈希与加密两种截然不同的技术路线——理解这一差异是正确选型的根本。七、实战清单与常见误区可落地的最小方案清单绝不存储明文密码也禁止在日志、错误信息中打印密码绝不裸哈希必须为每个用户生成独立的随机盐并存储hash(password salt)盐要真随机使用密码学安全的随机数生成器长度至少 16 字节选对算法优先 Argon2其次 bcrypt / scrypt / PBKDF2并设置合理的工作因子恒定时间比对校验哈希时使用constant_time_compare类 API传输全程加密密码只在 HTTPSSSL/TLS通道中传输参见 敏感数据管理指南配合整体安全设计密码校验成功后接令牌/会话体系参见 安全 Web API 访问设计。常见误区速查误区正确理解盐是秘密不能入库盐不需要保密可明文存储在数据库它的价值是破坏预计算攻击的复用性两个用户密码相同哈希就应相同加了盐之后相同密码因盐不同会产生不同的哈希值用 SHA-256 哈希密码就够了通用摘要算法速度太快无法抵御离线爆破应使用慢速密码哈希算法哈希和加密是一回事哈希不可逆用于校验密码存储加密可逆用于机密性如密码管理器保险库总结从原指南的核心脉络出发密码的安全存储可以凝练为一条主线明文存储不可取 → 裸哈希挡不住彩虹表等预计算攻击 → 加盐让每个密码的哈希路径独一无二 → 按hash(password salt)格式入库盐明文存储→ 校验时重新计算 H1 并与库中 H2 恒定时间比对。在这个主线上再叠加慢速密码哈希算法选型、传输加密、最小权限与数据生命周期治理就构成了一个完整、可防御常见攻击的密码安全方案。希望本文能帮你把密码存储从能跑提升到扛打也欢迎结合仓库中的 security 分类 继续学习认证、加密与整体安全设计的其余篇章。赞分享后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载相关推荐Yii 2 密码安全哈希实战使用 bcrypt 安全存储与校验用户密码Yii 2 密码安全哈希实战使用 bcrypt 安全存储与校验用户密码 在 Web 应用中密码绝不能以明文形式入库这是所有开发者都认同的基础安全常识。本文后端Web框架Wasp密码安全哈希、加盐与密码策略Wasp密码安全哈希、加盐与密码策略 密码安全的重要性 在现代Web应用中密码安全是保护用户数据的第一道防线。Wasp作为一个全栈开发框架内置了强大的密码Web框架后端前端CLI开发工具gqlgen密码安全哈希与加盐最佳实践指南gqlgen密码安全哈希与加盐最佳实践指南 在构建现代GraphQL API时密码安全是开发者必须重视的核心问题。gqlgen作为Go语言中强大的Graph后端GraphQL代码生成上一篇Redwood 应用部署到 AWS 的完整指南使用 Flightcontrol 托管 API、Web 与数据库下一篇XUnity自动翻译器终极指南3步实现Unity游戏无障碍中文体验创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考