“要来一口盐巴吗”最近这个表情包在聊天群里出镜率很高——一个小人捧着一包盐递过来配上这句没头没尾的话被拿来整活、糊弄提问、或者单纯制造一种无厘头的幽默。我盯着这个表情包看了好几秒脑子里却冒出一个跟搞笑完全无关的词加盐。对就是密码存储里的“盐”Salt。如果你写过登录注册或者负责过用户系统的数据存储那你多半听过“密码不能明文存要加密、要加盐”这句话。但真到了动手写代码的时候很多人会卡在几个问题上盐到底是一串什么数据加盐之后怎么校验密码盐要不要保密为什么我用了 MD5 加盐之后还是被人从库里还原出了密码这篇文章就围绕这些疑问展开。我们会先讲清楚盐的原理再用 Python 和 Java 分别实现完整的加盐哈希流程最后给出常见报错、排查思路和生产环境的最佳实践。文章内容更偏向“安全开发基础 实战操作”适合后端新人、实习开发者以及想系统梳理密码存储方案的初级工程师。1. 为什么“盐”在程序里这么重要1.1 密码存储的第一个教训不要存明文在很多早期的业务系统里用户密码就是直接以明文形式写在数据库里的。开发起来确实简单SELECT * FROM user WHERE username xxx查到密码再和用户输入比对一下“等于”就放行。但这种方式一旦出问题就是灾难级的。数据库被拖库、日志不小心记录了 SQL、备份文件泄露、运维人员误导出数据任何一个环节出漏洞所有用户的密码都会直接暴露在攻击者面前。更要命的是很多人习惯在不同网站复用同一个密码。一个站点的明文密码泄露攻击者就会拿着它去“撞库”尝试登录用户的邮箱、支付平台、其他办公系统。所以业内有一个共识密码根本不应该以可还原的形式存储应用只需要保存一种“能验证密码是否正确”的信息就够了。这个信息就是密码的哈希值。1.2 哈希是什么为什么哈希能代替明文哈希Hash是一种单向散列算法。它的特点是任意长度的输入经过算法处理后都会得到一个固定长度的输出这个输出通常称为摘要Digest或哈希值。同一个输入永远得到同一个输出但通过输出反推输入在计算上极其困难。简单理解就是我能算给你看“它等于什么”但没法从结果“还原它原本是什么”。后面这件事在密码学上叫单向性。正因为单向性系统可以把密码的哈希值存进数据库。用户登录时我们把用户输入的密码重新做一次哈希然后用结果和数据库中存着的哈希值做对比。如果一致就说明输入的密码是正确的但攻击者即使拿到数据库看到的也只是一堆无法直接还原的字符串。示例思路如下注册明文密码 哈希算法 - 哈希值 - 存入数据库 登录用户输入的密码 哈希算法 - 新的哈希值 - 和数据库中的哈希值比对1.3 单纯哈希的致命缺陷按理说存哈希值已经比存明文安全很多了。但如果你直接用 MD5、SHA-1、SHA-256 这类普通哈希函数处理密码依然存在两个很严重的问题。第一个问题是相同的密码一定得到相同的哈希值。假设用户 A 和用户 B 的密码都是123456那么数据库里存储的哈希值也完全一样。攻击者只要看到两个一样的长字符串就基本可以判断这两个账号的密码相同。更严重的是攻击者可以事先把海量常见密码的哈希值计算出来做成一张“密码 - 哈希值”的对照表这就是常说的彩虹表Rainbow Table。拿到数据库后直接反向查询密码很快就会被还原出来。第二个问题是普通哈希函数为了追求速度计算极快。MD5 一秒钟可以算出数亿次。攻击者不需要彩虹表光靠穷举就能在较短时间内把弱密码试出来。也就是说单独使用普通哈希函数密码的安全边界非常脆弱。2. 到底什么是盐Salt2.1 盐的通俗理解盐本质上就是“一小串随机数据”。它的核心思想是在计算哈希时不要把密码单独拿来算而是先把这串随机数据和密码拼在一起再用哈希函数去处理拼接后的内容。举个例子不 加 盐哈希值 MD5(密码) 加 盐 后哈希值 MD5(密码 盐)同样的密码因为每个人的盐不同最终算出来的哈希值也不同。这样一来就算两个用户的密码都是123456只要盐不一样数据库里保存的哈希值就是完全不同的两串字符。两张彩虹表在这里都失去了意义因为彩虹表是针对“密码 - 哈希”预先计算的它不知道你的盐是什么也就无法直接反查。2.2 盐的设计要点盐并不是随便拼几个字符就行它有几个硬性要求。第一盐必须随机生成并且每个用户独立。如果全站所有用户共用同一个盐那攻击者依然可以提前计算“加了这个固定盐之后的彩虹表”。所以正确的做法是一个用户一个盐互不相同。第二盐的长度要足够。太短的盐容易发生碰撞也容易被穷举。通常建议使用 16 字节128 位以上的随机数据。第三盐不需要保密。这不是笔误盐可以和哈希值一起明文存放在数据库里。攻击者拿到盐也没关系因为盐本来就是公开存入的真正的安全核心在于“密码本身没有被泄露”和“哈希算法本身足够慢”。第四盐应该使用安全的随机数生成器生成。不要使用Random()这类普通随机数生成器因为它是伪随机的可预测性比安全随机数强得多。在 Python 中要用secrets模块在 Java 中要用SecureRandom。2.3 加盐哈希的完整流程加盐哈希在注册和登录两个场景下的流程分别如下。注册流程用户输入密码。系统生成一个随机盐。把密码和盐拼接成一个字符串。使用哈希算法处理拼接后的字符串。把盐和哈希值一起存入数据库。登录流程用户输入密码。系统根据用户名从数据库查出盐和哈希值。把输入的密码和数据库中的盐按相同规则拼接。使用相同的哈希算法处理拼接后的字符串。把计算结果和数据库中的哈希值进行比较。这里有一个关键点注册和登录必须使用完全相同的“盐 拼接规则 哈希算法”。很多新人遇到的“注册成功但登录失败”问题根源往往就是注册时用的拼接方式和登录时不一致。2.4 加盐不等于加密这里需要区分一个概念加盐是密码存储的一种辅助机制它本身不是加密。加密是可逆的密钥持有方可以把密文还原成明文。加盐哈希是不可逆的系统本身也只是通过“重算一遍再比较”来验证密码。新手经常把这两个概念搞混导致在代码里使用 AES 之类的对称加密算法来“加密”密码。这种做法其实很危险一旦密钥泄露全部密码都会被还原。所以在密码存储场景中我们的原则是不保存可还原的密码只保存“验证用”的哈希值。3. 环境准备与版本说明3.1 演示环境本文会涉及 Python 和 Java 两种语言。为了保证示例能顺利运行先同步一下环境版本。Python 版本3.10 及以上建议使用 3.11 或 3.12secrets和hashlib都是标准库无需额外安装Java 版本JDK 8 以上本文示例使用 JDK 17Spring Boot示例基于 Spring Security 6.x如果你使用 Spring Boot 2.x需要对应选择 Spring Security 5.x 版本的 API构建工具Maven 3.8 以上IDEIntelliJ IDEA 或 VS Code 均可版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。如果你的版本与本文不一致只要保持核心 API 类似即可。3.2 示例项目结构最终的文章代码会拆成几个文件方便你直接照做。password-salt-demo/ ├── python/ │ ├── simple_salt.py # 标准库实现加盐哈希 │ ├── bcrypt_demo.py # 使用 bcrypt 库 │ └── user_store.py # 模拟注册登录的完整示例 └── java/ └── PasswordDemo.java # Java 实现 PBKDF2 加盐哈希为了演示我们不会连接真实的数据库而是用内存结构模拟一张用户表。这样你可以直接复制代码运行看到加盐哈希的完整链路。4. Python 实现加盐哈希4.1 用标准库手动实现加盐哈希先来看一个最简单的实现。这里使用 Python 标准库中的secrets生成盐使用hashlib计算 SHA-256 哈希值。# 文件路径password-salt-demo/python/simple_salt.py import hashlib import secrets def generate_salt(length16): 生成 16 字节的随机盐返回十六进制字符串 return secrets.token_hex(length) def hash_password(password: str, salt: str) - str: 把密码和盐拼接后计算 SHA-256 哈希值 # 注意这里使用 b| 作为分隔符目的是避免拼接歧义 data salt.encode(utf-8) b| password.encode(utf-8) return hashlib.sha256(data).hexdigest() # 注册场景 salt generate_salt() hashed hash_password(mypassword123, salt) print(盐, salt) print(哈希值, hashed) # 登录场景用户输入密码后重新计算 input_password input(请输入密码) rehashed hash_password(input_password, salt) if rehashed hashed: print(登录成功) else: print(密码错误)运行结果类似下面这样每次运行都会生成不同的盐盐 7d4f3e2a9c06b8d17a5e2f8c3d6b4a10 哈希值 e4d909c290d0fb1ca068ffaddf22cbd0e0e1c3b...此处省略 请输入密码mypassword123 登录成功这个例子已经演示了最核心的加盐思想。但身为开发的同学看到这里要注意SHA-256 加盐并不适合作为生产环境的密码存储方案。因为 SHA-256 很快攻击者可以用 GPU 每秒进行海量尝试。这个例子只用来理解盐的拼接原理。生产环境建议使用 bcrypt、scrypt、PBKDF2 或 Argon2。4.2 使用 bcrypt 库bcrypt 是当前比较推荐的密码哈希算法之一它有几个特点自带盐不需要自己单独管理盐字段。哈希值字符串中同时包含了盐、算法版本和成本因子。算法本身设计得“慢”而且是可调慢的能显著增加暴力破解的成本。先安装依赖pip install bcrypt然后看示例代码# 文件路径password-salt-demo/python/bcrypt_demo.py import bcrypt # 注册生成盐并计算哈希 password bmypassword123 salt bcrypt.gensalt() hashed bcrypt.hashpw(password, salt) print(盐, salt.decode()) print(哈希值, hashed.decode()) # 登录校验密码 input_password bmypassword123 if bcrypt.checkpw(input_password, hashed): print(登录成功) else: print(密码错误)输出内容大致像下面这样盐 $2b$12$abcd1234efgh5678ijklmn 哈希值 $2b$12$abcd1234efgh5678ijklmnABCDEFGHIJKLMNOPQRST 登录成功注意bcrypt.gensalt()可以传入rounds参数控制成本因子默认是 12。成本因子越大哈希计算越慢安全性越高但用户体验也会受影响。建议根据业务并发和硬件性能进行调整。在综合权衡下12 是一个比较常见的默认值。4.3 使用 PBKDF2PBKDF2 是一种基于密码派生的密钥派生函数它通过对哈希算法进行多次迭代来增加破解成本也是 OWASP开放式 Web 应用程序安全项目曾经推荐过的方案。Python 标准库提供了hashlib.pbkdf2_hmac方法# 文件路径password-salt-demo/python/simple_salt.py追加片段 import hashlib import secrets salt secrets.token_urlsafe(16) password bmypassword123 # 迭代 600000 次输出 256 位密钥 derived_key hashlib.pbkdf2_hmac( sha256, password, salt.encode(utf-8), 600_000 ) print(盐, salt) print(派生密钥, derived_key.hex())关于迭代次数OWASP 曾经建议 PBKDF2-HMAC-SHA256 使用 600000 次迭代但这不是一成不变的需要根据 CPU 性能和用户等待时长进行压测调整。迭代次数太低容易暴力破解太高会导致每次登录响应过慢。比较好的判断标准是在你的生产服务器上单次计算耗时控制在 0.5 秒以内同时尽可能大。4.4 完整的模拟注册登录示例为了让你更直观地理解加盐哈希如何落地这里再写一个模拟用户表的例子。它不依赖数据库直接把用户信息保存在字典里。# 文件路径password-salt-demo/python/user_store.py import hashlib import secrets def generate_salt(length16): return secrets.token_hex(length) def hash_password(password: str, salt: str) - str: data salt.encode(utf-8) b| password.encode(utf-8) return hashlib.sha256(data).hexdigest() class UserStore: def __init__(self): # 模拟数据库用户表结构username - {salt, hashed} self.users {} def register(self, username: str, password: str): salt generate_salt() hashed hash_password(password, salt) # 数据库中同时保存盐和哈希值 self.users[username] { salt: salt, hashed: hashed } print(f[注册成功] {username}盐为 {salt}) def login(self, username: str, password: str) - bool: user self.users.get(username) if not user: print(用户不存在) return False # 从数据库取出该用户的盐 salt user[salt] # 按相同规则重新计算哈希 hashed hash_password(password, salt) if hashed user[hashed]: print(登录成功) return True else: print(密码错误) return False if __name__ __main__: store UserStore() store.register(alice, password123) store.register(bob, password123) print(\n--- 注册完成查看用户表 ---) for name, info in store.users.items(): print(f{name}: salt{info[salt]}, hashed{info[hashed]}) print(\n--- 模拟登录 ---) store.login(alice, password123) store.login(alice, wrongpass)运行后你会发现alice 和 bob 的密码完全一样但因为盐不同保存后的哈希值完全不同。这就是加盐要解决的问题之一防止相同密码在库中呈现相同形态。5. Java 实现加盐哈希Java 同样可以很方便地实现加盐哈希。常见的做法有两种一种是引入 Spring Security 的BCryptPasswordEncoder适合 Spring Boot 项目另一种是使用 JDK 自带 API 实现 PBKDF2适合不依赖框架的场景。5.1 使用 Spring Security 的 BCryptPasswordEncoder如果你的项目是 Spring Boot最推荐的方式是直接使用 Spring Security 提供的BCryptPasswordEncoder。它已经被大规模验证过使用简单而且默认支持加盐。先在pom.xml中添加依赖dependency groupIdorg.springframework.security/groupId artifactIdspring-security-crypto/artifactId version6.2.1/version /dependency这里注意版本需要结合你的 Spring Boot 实际版本选择。Spring Boot 2.x 推荐使用 5.7.x、5.8.x 等对应版本Spring Boot 3.x 使用 6.x 版本不要直接复制一个版本号就完事。下面是演示代码// 文件路径password-salt-demo/java/PasswordDemo.java import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder; public class PasswordDemo { public static void main(String[] args) { BCryptPasswordEncoder encoder new BCryptPasswordEncoder(); // 注册编码密码 String rawPassword mypassword123; String encodedPassword encoder.encode(rawPassword); System.out.println(编码后的密码 encodedPassword); // 登录校验密码 boolean matches encoder.matches(mypassword123, encodedPassword); System.out.println(密码校验结果 matches); } }BCryptPasswordEncoder.encode()会随机生成一个盐并把盐和哈希值一起嵌在最终输出的字符串里。所以你在业务表中只需要一个密码字段不需要再额外存盐字段。5.2 Spring Security 的密码前缀在 Spring Security 的现代版本中如果你使用了DelegatingPasswordEncoder存储的密码通常会带有前缀比如{bcrypt}$2a$10$4uX9xU3uJw3J4cN1dZzVcO4x1E3C1...前面的{bcrypt}表示当前哈希值的算法类型。这样做的好处是系统将来升级算法后可以用前缀区分新旧用户密码逐步迁移。如果你手动解密了一个旧密码它是无前缀的Spring Security 需要手动指定编码器。新手容易在这里报There is no PasswordEncoder mapped for the id null的错误解决办法就是在密码前显式加上{bcrypt}前缀或者在配置类中指定DelegatingPasswordEncoder的默认编码器。5.3 使用 JDK 原生 API 实现 PBKDF2不引入 Spring Security 时也可以使用 JDK 自带的SecretKeyFactory和PBEKeySpec实现 PBKDF2 加盐哈希。// 文件路径password-salt-demo/java/PBKDF2Demo.java import javax.crypto.SecretKeyFactory; import javax.crypto.spec.PBEKeySpec; import java.security.SecureRandom; import java.util.Base64; public class PBKDF2Demo { public static void main(String[] args) throws Exception { String password mypassword123; // 1. 生成 16 字节随机盐 byte[] salt new byte[16]; SecureRandom random new SecureRandom(); random.nextBytes(salt); String saltBase64 Base64.getEncoder().encodeToString(salt); // 2. 配置 PBKDF2 参数 int iterations 600_000; int keyLength 256; PBEKeySpec spec new PBEKeySpec(password.toCharArray(), salt, iterations, keyLength); SecretKeyFactory factory SecretKeyFactory.getInstance(PBKDF2WithHmacSHA256); // 3. 生成派生密钥 byte[] derivedKey factory.generateSecret(spec).getEncoded(); String hashBase64 Base64.getEncoder().encodeToString(derivedKey); System.out.println(盐Base64 saltBase64); System.out.println(哈希值Base64 hashBase64); } }这里需要说明几个关键点PBEKeySpec的第一个参数要求是字符数组不要直接传入字符串。SecretKeyFactory.getInstance(PBKDF2WithHmacSHA256)使用的是 HMAC-SHA256 作为 PRF比默认的 HMAC-SHA1 更安全一些。运行时输出的是一个派生密钥实际项目中你需要把saltBase64和hashBase64一起保存到数据库。验证密码时只需要从数据库读盐再用相同参数重新计算哈希值然后和库里的哈希值比对即可。6. 常见问题与排查思路在实际项目中加盐哈希本身不难但很多问题出在“规则不一致”或“选型错误”上。下面整理了几类高频问题。问题现象常见原因解决思路注册成功后登录失败提示密码错误注册和登录使用的拼接规则不一致或盐取错了注册和登录必须使用同一个盐、同一个拼接方式、同一个算法建议把拼接逻辑封装成一个函数数据库中没有单独的盐字段登录时无法校验手动实现时漏掉了盐的存储如果是 bcrypt盐已经内嵌在哈希字符串中不需要单独字段手动实现时必须存盐同一个密码在库中哈希值相同没有加盐或使用了相同盐必须为每个用户生成独立随机盐长度为 16 字节以上使用 MD5 加盐后仍被破解算法太快盐可能被复用升级为 bcrypt、scrypt、PBKDF2 或 Argon2不要继续使用 MD5/SHA-1 作为密码哈希登录接口响应非常慢哈希迭代次数设置过高或登录接口被大量调用压测调整迭代次数增加登录限流必要时做多级缓存Spring Security 报There is no PasswordEncoder mapped for the id null数据库中的密码没有算法前缀默认编码器无法识别在密码前手动添加{bcrypt}前缀或配置DelegatingPasswordEncoder的默认编码器用户密码重置后旧密码仍能登录一小段时间密码哈希没有多设备会话失效机制或缓存了密码校验结果密码重置后主动清除会话不要对密码哈希结果做长期缓存排查时建议按以下步骤来确认数据库中盐和哈希值是否都存在且指向正确的用户。确认注册和登录调用的哈希函数是同一个参数是否一致。在内存中打印注册时的盐、哈希值和登录时计算的哈希值逐字节比较差异。检查代码中是否存在对盐或密码的多余转义、空白字符处理不一致的情况。检查日志中是否打印了完整密码、密码哈希或盐如果有需要立即清理并修复日志逻辑。7. 加盐哈希的最佳实践7.1 不要自己设计密码哈希算法密码学是一个非常容易“自以为是但实际出错”的领域。不要自己去拼接“MD5 盐 固定字符串”的自定义方案也不要设计什么“多层哈希”的奇特算法。标准方案已经足够成熟bcrypt、scrypt、PBKDF2 和 Argon2 都是经过长期验证的选择。Python 有bcrypt库和hashlib.pbkdf2_hmacJava 有 Spring Security 和 JDK 原生 APIGo、Node.js 等语言也都有成熟实现。7.2 盐的生成与存储规范盐的生成必须使用安全随机数生成器。不要在代码中写死盐也不要用用户名、用户 ID、手机号等用户相关数据当盐。这些数据不是随机产生的攻击者一旦掌握了规律就可能构造出专用的预计算表。存储方面bcrypt 和 Argon2 这类算法已经自动把盐嵌入到最终哈希字符串中你不需要单独存储盐字段。但如果你用 PBKDF2 手动实现则必须把盐和哈希值一起保存。推荐格式可以是$pbkdf2-sha256$600000$盐Base64$哈希Base64这个格式的好处是将来换算法时系统可以通过前缀知道旧密码用的是哪种算法从而逐步迁移。7.3 登录限流与防护加盐解决了“库被拖走后密码被还原”的问题但挡不住攻击者直接对登录接口暴力尝试。所以生产环境还需要给登录接口增加限流、验证码、失败次数锁定、IP 黑白名单等防护手段。不要在日志中打印用户密码、密码哈希或盐否则再强的哈希算法也扛不住日志泄露。7.4 算法参数的动态配置很多团队会把哈希算法的迭代次数、成本因子写死在代码里。这在初期没问题但几年后如果硬件性能提升了600000 次迭代可能已经变得过低了。更好的做法是把这些参数配置化方便在不停机的情况下调整。同时当系统升级算法时可以在用户登录成功后判断当前用户的哈希值是否使用了旧参数如果是就用新参数重新计算并更新数据库。这样就能平滑迁移到更强的算法。7.5 密码策略管理加盐哈希负责的是“存储安全”密码本身的强度也需要管理。建议拒绝常见的弱密码比如123456、password、qwerty等。不鼓励强制用户频繁改密因为那样会导致用户把密码改成带尾号的弱密码建议更多关注防撞库和泄露密码库对比。7.6 备份与删除密码哈希值本身不是明文但它们仍然是敏感数据。数据库备份文件、日志平台、对象存储中的历史快照都要按照敏感数据的访问权限进行管理。当用户注销账号或请求删除数据时应同时清除对应的密码哈希记录不能只做软删除留一个残留字段。8. 总结从“要来一口盐巴吗”这个表情包聊到密码加盐听起来像是一个冷笑话但“盐”在安全领域的价值一点也不可笑。它解决的是两个核心问题让相同密码在库中呈现不同形态以及打破彩虹表的直接反查能力。不过也要清醒地认识到加盐只是密码安全的第一步。正确的做法是“随机盐 专用慢哈希算法 合理迭代参数 登录限流 数据备份加密 日志脱敏”这些环节组合在一起才能真正降低密码泄露带来的风险。如果这篇文章对你有帮助可以收藏备用。下一步建议你动手写一个简单的注册登录示例亲手验证“同密码不同盐”的哈希结果再用bcrypt和 PBKDF2 对比普通 SHA-256 的计算耗时。只有亲手跑一遍才能真正理解为什么那些老系统需要做密码哈希迁移。