我注意到大多数api教程都说您应该在发送之前加密密码。它还显示了如何解密它们。如果我能做到,他们也不能做到吗?
这是medium
中的示例UserSchema.pre('save', function (next) {
var user = this;
bcrypt.hash(user.password, 10, function (err, hash){
if (err) {
return next(err);
}
user.password = hash;
next();
})
});
他们说要在这里散列
bcrypt.compare(password, user.password, function (err, result)
当用户尝试登录时,他们在此处取消哈希处理。令我困惑的是,如果他们能够轻松地将其哈希化,那么攻击者也无法将其哈希化吗?有人可以向我解释吗?
答案 0 :(得分:1)
需要说明的是,尽管我已经编写了用户帐户系统并使用了安全的哈希函数,但我不是任何一种“专家”,但是对于那些想知道您是否真的需要经历这个问题的人来说,使用安全哈希进行密码存储的麻烦:是的。
此外,如果您仍然不确定,并且对这些哈希方法的工作方式以及它们如何支持安全模型的理解并不十分满意,那么您应该对任何工作的人都诚实之所以这样做,是因为因为很难获得担保权,并且需要经验丰富的同行进行审查和审查。
无论如何,如注释中所述,设计用于密码存储的安全哈希(例如bcrypt
或scrypt
)具有处理所有杂乱工作的API。我对scrypt
较为熟悉,但它们是相似的。哈希密码看起来像一串随机字符,但是在字符串的开头是两个单独的部分,分别包含随机盐和哈希参数。
因为用于密码存储的安全哈希将始终将任何长度的密码和组成的哈希值哈希为某个固定大小的哈希字符串,所以没有充分的理由将用户密码限制为任何长度(除了1000个字符之类的目的只是为了避免DOS攻击)。
答案 1 :(得分:1)
由于攻击者将无法获得纯文本密码,因此它限制了数据库破坏的潜在后果。这非常重要,因为用户经常重复使用密码。
bcrypt
是一种单向密码。一旦对明文进行了编码,您将无法取回它。
当您检查用户密码时,您正在检查对用户输入进行编码的结果是否与存储的密码哈希匹配。
这意味着即使攻击者得到了盐和哈希值,他们仍然必须猜测密码。 Bcrypt具有内置的成本(缓慢性),这使得测试可能的密码的彩虹表非常昂贵。