讨论/投票：是否以向后兼容性为代价换取正确的密码哈希实现

[winderica]

以前的实现：

• 哈希：

const salt = crypto.randomBytes(16).toString('base64');
const hash = crypto.scryptSync(password, salt, 64).toString()

• 验证：

hash !== crypto.scryptSync(password, salt, 64).toString()

其中存在两个问题：

1. scrypt的第二个参数类型为string | Buffer。当其为string时，node会把它理解为UTF8编码的字符串，也就是说base64编码的salt会被以UTF8解码，导致实际上salt的长度大于16。这是错误（至少是非意料）的实现，但是因为哈希与验证时都是将错就错，所以它工作。例子：

> const a = crypto.randomBytes(16)
undefined
> a
<Buffer 93 d6 ad 26 c5 12 bb f5 62 0f 25 db 1e ad b7 6b>
> Buffer.from(a.toString('base64'), 'utf8')
<Buffer 6b 39 61 74 4a 73 55 53 75 2f 56 69 44 79 58 62 48 71 32 33 61 77 3d 3d>

2. scrypt以Buffer格式返回哈希，Buffer.toString有一个可选参数，即编码，默认是UTF8。这就带来了另一个问题：unicode在编码无效字符时，会将其替换为U+FFFD，而scrypt的结果可能（极大概率）会包含无效的unicode字符，导致它们全部被替换为了U+FFFD。这是大错特错的实现，而且正好也是因为哈希与验证时都是将错就错，所以它工作。例子（以我自己的密码为例）：

> require('./users.json')[0].password.hash.length
62
> [...require('./users.json')[0].password.hash].filter(i => i.charCodeAt(0) === 0xFFFD).length
33

长度为62（尽管不是真正的长度）的哈希里，有33个都是0xFFFD，极大增加了碰撞的可能性（尽管我们的体量太小，没人会对我们做这种事）。

附上正确的实现：

// hash
const salt = randomBytes(16);
scrypt(password, salt, 64, (error, derivedKey) => {
    // ...handle error
    return resolve({
        salt: salt.toString('base64');
        hash: derivedKey.toString('base64'),
    });
}
// verify
scrypt(password, Buffer.from(salt, 'base64'), 64, (error, derivedKey) => {
    // ...handle error
    return resolve(derivedKey.toString('base64') === hash);
}

采取正确的实现后，所有用户都需要重新设置密码，但是它毕竟是正确的。

所以投票，滋磁采取正确的实现按👍，反对按👎。

[winderica]

我想出了一种向后兼容的解决方案（大概），现在初次登录的时候用的是以前的算法，验证成功后会把用户密码迁移到新的算法，之后都是用新的算法验证了。参见06ec536。