够安全，但需显式指定method='pbkdf2:sha256'和salt_length=32，并始终配对使用check_password_hash验证；旧密码可平滑升级，存储字段须足够长（如VARCHAR(255)）。
Flask里直接用generate_password_hash够不够安全
够，但得用对方式。Werkzeug的generate_password_hash默认用的是pbkdf2:sha256，迭代150000次（Flask 2.3+），符合OWASP当前推荐强度，不是简单哈希，也不是MD5/SHA1那种能被彩虹表秒杀的货。
常见错误是只写generate_password_hash(password)，没传method和salt_length——旧版本默认pbkdf2:sha256但迭代次数低（260000次其实是Flask 2.2之前的老默认值，新版本已上调），而且盐长度固定为16字节，够用但不显式声明容易让人误以为可省略。
- 必须显式指定
method='pbkdf2:sha256'，避免未来Werkzeug升级后默认方法变更（比如加了scrypt但你不兼容） - 建议显式设
salt_length=32，比默认16更抗碰撞，且不影响兼容性 - 别自己拼接盐或用
hashlib手撸——generate_password_hash生成的字符串自带盐、算法、迭代数，格式如pbkdf2:sha256:150000$abc123...$xyz789...，check_password_hash才能正确解析
为什么check_password_hash比自己写验证逻辑更可靠
因为验证时它会自动提取哈希串里的盐、迭代次数、算法，并用完全相同的参数重算一次——你手动实现很容易漏掉其中一环，比如硬编码了150000次但数据库里存的是旧用户（260000次），或者忘了用相同盐值，结果就是“所有老密码都登不上”。
典型翻车场景：用户注册时用新参数加密，登录时却用hashlib.pbkdf2_hmac('sha256', pwd.encode(), salt, 150000)硬算，但盐从哪来？从哈希串里解析？那等于重复造轮子，还容易出错。
立即学习“Python免费学习笔记（深入）”；
-
check_password_hash是唯一推荐的验证方式，它和generate_password_hash配对设计，内部逻辑严格一致 - 传入的哈希字符串必须是
generate_password_hash原生输出，不能截断、base64再解、或去掉前缀——哪怕多一个空格，check_password_hash都会静默返回False - 它不抛异常，只返回布尔值，所以别写
if check_password_hash(...) == True:，直接if check_password_hash(...):
升级旧密码哈希时怎么平滑过渡
老系统可能存着sha1或md5明文盐哈希，不能强制所有人改密码。得在登录成功后悄悄升级：验证旧方式通过了，就用新方式重哈希并更新数据库。
关键点不是“怎么判断旧哈希”，而是“怎么避免重复升级”。Werkzeug生成的哈希字符串开头带标识，比如pbkdf2:sha256:，而sha1$或纯hex串（40位）大概率是旧的。
- 检查数据库里存的哈希是否以
pbkdf2:开头，不是就走旧逻辑；是的话直接用check_password_hash - 旧验证通过后，立刻调用
generate_password_hash(new_password, method='pbkdf2:sha256', salt_length=32)生成新哈希，更新到DB - 别在每次登录都无条件重哈希——如果用户用的是新哈希，再跑一遍
generate_password_hash会产生新盐，导致下次登录失败
和bcrypt、argon2比，pbkdf2有什么实际差异
不是“谁更好”，是“谁更适合你现在这个Flask小项目”。pbkdf2:sha256是纯Python实现，零依赖，Werkzeug自带，部署简单；bcrypt要装bcrypt包，argon2要装argon2-cffi，多一个C扩展依赖，CI/容器环境容易卡在编译上。
性能上，pbkdf2比bcrypt稍快（但都在百毫秒级），比argon2明显快——但对登录这种低频操作，快10ms还是20ms用户根本感觉不到。真正要注意的是内存占用：argon2可调内存参数防ASIC攻击，pbkdf2纯CPU绑定，适合资源受限的小服务器。
- 如果你的Flask应用没额外装
bcrypt或argon2-cffi，别为了“更先进”强行切——pbkdf2:sha256足够应付绝大多数场景 - 真要用
argon2，别用Werkzeug接口，改用argon2-cffi原生API，因为Werkzeug目前不内置argon2支持 - 所有方案都依赖“密码本身够强”，哈希再慢也挡不住
123456——该前端校验长度/复杂度，还得做
最易忽略的一点：哈希结果要存足够长的字段。pbkdf2:sha256:150000$...$...完整字符串通常超120字符，MySQL用VARCHAR(255)，SQLite用TEXT，别图省事建个VARCHAR(64)——截断后哈希失效，且毫无提示。
