身份认证之前端慢速加盐散列

在《数据安全架构设计与实战》一书中，提倡不传输用户的原始口令，而是在前端执行慢速加盐散列后再传输。

前端慢速加盐散列在对抗暴力破解和撞库方面，具有非常明显的效果。但服务器侧的资源是宝贵的，消耗在这种延时的运算中非常不值得，为了解决这个问题，我们可以将延时运算转移到用户侧去。这种百毫秒级的延时，对用户的影响是几乎可以忽略不计的。

以开源应用安全网关Janusec Application Gateway的后台管理系统的登录模块为例，看看它是如何处理用户口令的。

首先，在用户侧浏览器，通过JavaScript来对口令执行bcrypt慢速加盐散列运算，这里的盐值取用户名、口令和固定字符串拼接而成，延时300~500毫秒，并生成一个比较长的密文字符串，作为替代口令。在实际传输过程中，不再传输原始口令，而是传输这个替代口令。

由于慢速加盐散列的结果通常是比较长的字符串，作为服务器侧的口令输入，符合通常意义上的强口令。

后端再执行一次SHA256加盐散列，后端盐值是在创建时随机生成的，并写入数据库，在修改口令时会重新生成新的盐值。

慢速加盐散列措施是自动化工具绕不过去的一道坎，工具在提交之前，也必须基于密码字典执行同样的慢速加盐散列动作，在拖延时间方面可以起到很好的作用，直至令攻击者耗不起，从而放弃尝试。如果执行百毫秒级（通常可采用300~500毫秒）的慢速加盐散列，则针对不特定用户的自动化工具就失去了意义。

为了方便大家使用，我们已将前端慢速加盐散列的代码开源：https://github.com/Janusec/hashpwd 

这种方式不收集用户原始口令，在用户侧执行前端慢速加盐散列后再传输，好处主要有：

• 可防止用户口令泄露（传输的是单向散列值，不可还原）。
• 可防止撞库（原始口令无效，前端慢速加盐散列极大地提高了撞库门槛）。

本文地址： https://www.janusec.com/articles/data/1580036449.html （转载请注明出处）

评论区(共0条评论)