密码哈希+盐如何工作
我虽然我理解哈希和腌制密码,但似乎我有一些误解。 我正在为nodejs中的我的网站创build一个用户帐户系统。
我理解的方式是,当用户创build一个密码时,我们生成一个随机salt,将其附加到密码,然后散列该string。 我们还可以添加一个工作因子,使哈希缓慢工作,并防范蛮力攻击。 我们将salt和散列一起存储在我们的数据库中,并validation一个login尝试,我们用储存的salt和密码尝试重复上述过程(在服务器上),并检查哈希是否匹配。
似乎nodejs中的bcrypt
模块与我对散列的解释不一致。 这是来自http://codetheory.in/using-the-node-js-bcrypt-module-to-hash-and-safely-store-passwords/上的一个例子
var salt = bcrypt.genSaltSync(10); var hash = bcrypt.hashSync("my password", salt);
首先,为什么工作因素适用于盐而不是哈希? 如果有人用暴力攻击,他们会运行哈希函数是否正确? 哈希函数是不是我们需要慢一点?
我也对bcryptvalidation感到困惑:
bcrypt.compareSync("my password", hash);
即使两个用户select相同的密码,我们也需要哈希值是独一无二的,这是否是盐点? 那么为什么我们不这样做呢?
bcrypt.compareSync("my password"+salt, hash);
salt
包含循环数,所以bcrypt.hash(Sync)
函数知道它需要做多less轮。 所以hash
不是一个简单的哈希,而是一个embeddedsalt
的容器。
SALT
是2个数(从4到31)的次数 – 函数创build哈希的迭代工作圈。 bcrypt
加盐,乘盐2倍。 并以此值对我们的string执行解码函数的总次数。 这是在bcrypt函数中循环的“圆” 。 每当你做:
bcrypt.hashSync("my password", salt)
bcrypt
创build一个新的“随机”string, 每次使用相同的inputstring,并使用相同的salt
我们采取不同的输出string ,这是工作bcrypt函数的关键思想,这个总结果我们将保存到我们的基地。 然后我们使用:
bcrypt.compareSync("my password", hash);
并且compareSync
计算是否从string“我的密码”创build了散列。 如果我们将函数compareSync
添加到我们的string( “我的密码” ),我们将更改已启动的string,并永远不会以这种方式实现。 因为bcrypt
会比较像这样创build的hash
:
bcrypt.hashSync("my password"+salt, salt);
这就是我们应该使用这种结构:
- 在创build用户数据时创build哈希值:
var salt = bcrypt.genSaltSync(10); var hash = bcrypt.hashSync("my password", salt);
var salt = bcrypt.genSaltSync(10); var hash = bcrypt.hashSync("my password", salt);
- 将
hash
保存到数据库 -
下一步身份validation用户在login期间如:
bcrypt.compareSync("my password", hash);
没有任何salt
或参数。