STRCMP不能用于密码比较，因其为可变时间函数易受时序攻击；正确做法是应用层用bcrypt等带盐哈希并恒定时间比对。
STRCMP不是密码比较的正确工具
直接用 STRCMP() 比较明文密码或未加盐哈希值，是典型的安全误用。它本身不解决时序攻击、不防爆破、也不替代哈希流程——它只是个二进制安全的字符串比较函数，和 = 在功能上接近，但多了对 NULL 和字节序的严谨处理。真正在生产环境做密码验证，核心动作永远是：先哈希用户输入，再恒定时间比对哈希值。
为什么不能用 STRCMP 直接比密码哈希
MySQL 的 STRCMP() 是可变时间比较：字符串在第几个字节不同时就提前返回，攻击者可通过响应延迟反推哈希前缀，实施时序攻击。而密码验证必须使用恒定时间比较逻辑，哪怕数据库层不原生支持，也该由应用层兜底。
- MySQL 无内置恒定时间比较函数；
STRCMP()和=都不满足该要求 -
PASSWORD()已废弃多年，MD5()、SHA1()均不可用于密码存储（碰撞易、算力廉价） - 即使你用
SHA2(password, 256)存了哈希，用STRCMP()查库匹配，仍是“哈希后比字符串”，没解决根本风险 - 真正安全的做法是：应用层用
bcrypt、scrypt或Argon2生成带盐哈希，并用语言原生恒定时间函数（如 Python 的secrets.compare_digest()、Go 的bytes.Equal()）比对
如果非要在 SQL 层做比对，该怎么做
仅限极简场景（如内部工具、原型验证），且前提是哈希已由应用层生成并传入。此时可借助 MySQL 的哈希函数 + 等值判断，但必须规避 STRCMP() 的时序特性。
- 用
=替代STRCMP()—— 二者在语义和性能上无实质差异，且都存在时序缺陷，但=更直白，不易误导人以为“更安全” - 示例：
SELECT id FROM users WHERE email = 'u@example.com' AND password_hash = SHA2('input_pass', 256); - 严禁把原始密码传进 SQL；必须由应用层完成哈希计算，SQL 只负责等值查找
- 若需支持多算法迁移（如从 SHA2 升级到 bcrypt），必须在应用层统一抽象，数据库只存哈希字符串，不参与计算逻辑
真正该关注的两个落地点
别卡在“SQL 里怎么比”，要往前一步看“哈希怎么生成”和往后一步看“比对在哪发生”。MySQL 只适合存哈希结果，不适合生成或验证密码。
- 哈希必须带盐，且盐不可复用；
bcrypt()自动处理盐，SHA2()+RAND()手动拼接盐极易出错 - 验证必须恒定时间；PHP 用
hash_equals()，Python 用secrets.compare_digest()，Node.js 用crypto.timingSafeEqual() - 数据库字段类型建议用
CHAR(64)存 SHA2-256，或TEXT存 bcrypt（因长度可变），避免VARCHAR引发隐式截断风险
最常被跳过的环节，是忘记校验哈希生成是否成功（比如空输入、超长密码导致截断）、以及忽略数据库连接字符集对二进制哈希存储的影响。这两处一出问题，连“比对”这个动作都失去了意义。
