我注意到大多数api教程都说应该在发送密码之前加密密码。它还展示了如何对它们进行去加密。如果我能做到，难道他们也不能做到吗？
这是介质的一个例子
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)
在这里，当用户尝试登录时，他们会取消它的哈希。如果脂肪能这么容易地解开它，攻击者就不能也解开它，我会感到困惑吗？有人能向我解释一下吗？
需要注意的是，尽管我编写了用户帐户系统并使用了安全哈希函数，但我不是任何类型的"专家"，但对于那些想知道你是否真的必须经历使用安全哈希存储密码的麻烦的人来说：是的，你确实需要。
此外，如果你仍然不确定，并且你对这些哈希方法是如何工作的以及它们如何支持安全模型的理解不太满意，那么你应该对你的工作人员坦诚相待，因为做正确的安全工作很难，需要有经验的同行进行审查。
无论如何，正如评论中提到的，为密码存储设计的安全哈希(如bcrypt或scrypt(有一个API来处理所有混乱的工作。我更熟悉scrypt，但它们很相似。散列密码看起来像是一个随机字符的字符串，但在字符串的开头是两个独立的部分，包含随机salt和散列参数。
因为用于密码存储的安全散列总是将任何长度和组成的密码散列为某个固定大小的散列字符串，所以没有充分的理由将用户密码限制为任何长度(除了1000个字符以避免DOS攻击(。
在数据库中散列密码有什么意义
它限制了数据库漏洞的潜在后果，因为攻击者不会获得明文密码。这一点非常重要，因为用户经常重复使用密码。
如果我能做到，难道他们也不能做到吗
bcrypt是一个单向密码。一旦明文被编码，你就无法将其取回。
当您检查用户密码时，您正在检查对用户输入进行编码的结果是否与存储的密码哈希匹配。
这意味着，即使攻击者获得salt和hash，他们仍然必须猜测密码。Bcrypt有一个内置的成本(缓慢(，这使得测试可能的密码彩虹表的成本极高。