加盐Hash与密码扩展

前言

保护一个网站的安全，是多方面的努力，如何保障数据不被拖库，这里就不讲了。
首先来说说密码加密，现在很少有系统会直接保存用户的密码了。至少也应该是计算密码的MD5/SHA哈希后保存。这种不可逆的加密方法理论上已经很安全了，但是随着彩虹的出现，GPU并行计算能力的不断提升，使得大量长度不够的密码可以直接从彩虹表反推出来。

安全的终极目的：

即使在数据被拖库，代码被泄露，请求被劫持的情况下，也能保证用户的密码不被泄露。
具体来说，我们的心中的安全系统大概是这样的：
1. 首先保障数据很难被拖库。
2. 即使数据被拖库，攻击者也无法从中破解出用户的密码。
3. 即使数据被拖库，攻击者也无法伪造登录请求通过验证。
4. 即使数据被拖库，攻击者劫持了用户的请求数据，也无法破解出用户的密码。

加盐Hash的应用

只对密码进行哈希运算时肯定的不够，这样程序员想出了一个办法，即使用户的密码很短，只要我在他的短密码后面加上一段很长的字符，在进行HASH运算，那么反推出原始密码就非常困难了。加上的这段长字符，我们称为盐（Salt），通过这种方式加密后，我们称为加盐Hash，例如：

SHA512（SHA512（Password）+ Salt）

通过以上加盐运算，即使攻击者拿到最终结果，也很难反推出原始的密码。不能反推，但是可以正推，假设攻击者将Salt值也拿到了，那么他可以枚举密码，加盐Salt哈希，计算出一个结果对照表，从而破解出简单密码，为了增加攻击者的成本，我们可以采用密码扩展。

密码扩展

为了增加攻击者的成本，我们采用密码扩展，使用加盐的慢Hash。慢Hash是指执行这个Hash函数非常慢，这样暴力破解就需要花上非常非常长的时间。
比如：bcrypt就是这样一个慢哈希函数：

bcrypt（SHA512（password），salt，cost）

通过调整cost参数，可以调整该函数慢到什么程度。假设让bcrypt计算一次需要0.5秒，遍历6位简单密码，需要的时间为：((26*2 + 10)^6)/2，约900年。

加盐Hash与密码扩展

Salt的初始化与更新

1. 用户注册，修改密码
2. Server使用安全随机数，为每个用户单独生成Salt（不要太短）
3. Salt建议独立存储

认证过程

1. 协商密钥，建立HTTPS
2. 验证密码
客户端通过HTTPS加密通道，提交Password Hash与UserID：

Hash=SHA512(password)

通过HTTS加密链接，将Hash提交到服务器端。
服务器端找到该UserID对应的Salt，验证SaltHash值。

SaltHash = bcrypt(SaltHash, Salt, cost)

验证计算出的SaltHash与数据存储的原有值是否相同。

假设攻击场景

以上就是加密传输、验证的全过程，我们来假设几种攻击场景：

1. 假设数据被拖库，密码会泄露吗？

   假设数据库存储的Salt, SaltHash 暴露了，想从SaltHash 直接反解原始密码几乎不可能。

2. 假设数据被拖库，攻击者能不能伪造登录请求通过验证？

   用户在伪造登录信息Password Hash 的时候，由于不知道原始密码，所以无法计算出Hash， 又无法从SaltHash 反推出 Password，所以无法伪造登录请求通过验证。

3. 为什么每个用户单独生成Salt？

   如果整个系统使用同一个Salt，攻击者只需要对所有SaltHash进行一轮暴力破解就可以，Salt只是增加了单次运算的复杂度。如果为每个用户生成独立Salt，意味着攻击者需要为每个用户单独进行一轮暴力破解，攻击成本极高。

如何快速检测到拖库攻击

如果我们已经做了充足的安全准备，仍然不幸被攻击者拖库，如何能够快速发现哪？如果我们能够及时发现攻击行为，就可以快速做出反应，防止进一步的信息泄露。

在部署必要的安全设备后，我们可以再进一步做如下部署，增强安全性：

场景一：账号数据表陷阱

在同一数据库中建立至少两套与认证相关的账号数据表，一真一假，二者实时更新、同步数据，对假账号表进行读取控制的监控和告警。因为攻击者无法区分哪一个表是真正的账号表，所以多数情况下会一并拖走，这样监控就可以及时发现非法行为。

场景二：账号数据值的陷阱

在同一账号数据库中，可以随着系统用户的注册增加，按照一定策略”内建”一些”假” （假，是与网民注册的真实用户对应）的数据账号。同场景一一样，多数攻击者会将所有用户信息拖走，这样监控就能及时发现非法行为。

Q&A

1. 使用bcypt慢Hash，在服务器应对大量用户登录访问是否有性能问题？

   我们可以对于服务器来说，这个性能是可控的。并且可以使用独立服务器单独运算。

2. 如何预防撞库？

   撞库的前提是攻击者已经获得了一批账号，密码（买来的，或者从其他网站拖库出的数据），由于大多数人都会使用同样的账号，密码。所以并不能从根本上防住撞库行为，我们可以认证过程中添加用户行为提高撞库的难度。