还以为微软的 BitLocker 有什么特别的防破解之道，去学了一下源代码，原来就是对用户密码 hash 自循环 100 万次。

确实稳妥简单。也够用

涨姿势了 :)

密码学应用基本原则不就是不要自己发明轮子吗

这是防爆破最佳实践吧，挺多软件都是这样做

慢哈希

你这是哪来的 bit locker ，怎么还有 gbk_to_unicode 的

应该是逆向来的代码吧

最简单的方式 也是最有效的

@codehz gbk_to_unicode 是我自己加的，哈哈。

微软的 1 百万次 hash 算法是 github 上找的，一搜一大把。

这点时间就可以防止黑客用字典的方式暴力破解本地密码。

参数里面的 r_salt：请，认真地看着我。
----

哈希类验证防止彩虹表的方法有两布：

1. 加盐。
2. 更多的哈希循环。

缺一不可。

@tool2d 请认真地查找一下有关“加盐”的资料。

哈哈，微软真的是思路清奇

记得以前有个 Password Hashing Competition ，参赛者选择的 hash function 基本上都是 blake2/sha512 ，没有用 sha256 的（大概是因为 sha256 用硬件加速成本太低了），最后胜出的是 argon2 （也是基于 blake2 ）

不知道微软当年有没有考虑参赛（狗头

我记得 keepass 还是 truecrypt 的 hash 迭代次数，就是 （ 1s /你本机算一次 hash 的时间）。这样你每次解开主密码需要 1s ，但是黑客受不了。

@matrix67 #13 是 keepass https://keepass.info/help/base/security.html

By clicking the '1 Second Delay' button in the database settings dialog, KeePass computes the number of iterations that results in a 1 second delay when loading/saving a database.

@ipwx 个人觉得盐其实无所谓，学 RSA 加密标准里，对 padding 取随机数就可以了。

@tool2d 不好意思，搞错了。hash 不是加密，不能通过随机 padding 来还原。保存盐是必须的步骤。

这是 KDF 的标准做法

@majula bitlocker 是跟随 vista 一起推出的功能，那时候 blake 都还没诞生,很多现在使用的密码原语都还没标准化。
Bitlocker 主要优势还是操作系统集成，例如基于 TPM 的自动解锁。想在 linux 用开源组件复刻这套功能还蛮麻烦的。

@ipwx 如果把上一步的 hash 结果用来生成盐会不会有什么用，比如可以减少循环次数但不减弱强度等等呢

@antness 只要没有随机数参与，就一定存在彩虹表。标准的 hash 做法是把盐这个随机数存下来的。

比较通用的实践是 pbkdf2 ，除了不断对自身 hmac 以外，还会和上一轮的结果异或一下

@ipwx 原来如此

这个循环里面 1024 * 1024 可以提出去吧…每次循环都要计算一下，这是微软源码？

@LittleDust 编译器优化里面有一个叫做常量折叠的操作，可以去了解看看。

多次 hash 会导致冲突增加吧