假设拖库很难避免,但加密就安全么?

　　在标准HASH安全破灭后，又看到有人呼吁用AES，其实这不是一个好建议。AES这些对称算法，都不具备单向性。网站被攻击的情况是复杂的，有的是只有数据库被拖，有的则整个环境沦陷。而后者AES密钥一旦被拿到，密码就会被还原出来，这比被查表还要坏。

　　当然我们还看到一种把AES当HASH用的思想，就是只保留一部分的AES加密结果，只验证不还原。但其实这样的AES并不见得比HASH有优势。比如即使攻击者没有拿到密钥，也只拖了库，但攻击者自己在拖库之前注册了足够多的帐号，并使用大量不同的短口令。那么就拿到了一组短明文和对应密文。而此时密钥是完全有可能被分析出来的。

　　而使用DES、AES一类的算法，还是使用标注HASH，还是自己设计算法，如果不解决不同用户相同口令密文相同的统计性缺陷，那么攻击者即使拿不到密钥，也都可以先把一些高频口令用于帐号注册，拖库后进行密文比对。就可以锁定大量的采用常见口令的用户。

　　加“一粒盐”

　　其实很多同仁都指出了哈希加盐法（HASH+SALT），是问题的解决之道，所谓加盐（SALT）其实很简单，就是在生成HASH时给予一个扰动，使HASH值与标准的HASH结果不同，这样就可以抗彩虹查表了。

　　比如说，用户的密码是123456，加一个盐，也就是随机字符串“1cd73466fdc24040b5”，两者合到一起，计算MD5，得到的结果是6c9055e7cc9b1bd9b48475aaab59358e。通过这种操作，即便用户用的弱密码，也通过加盐，使实际计算哈希值的是一个长字符串，一定程度上防御了穷举攻击和彩虹表攻击。

　　但从我们审计过的实现来看，很多人只加了“一粒盐”。也就是说，对同一个站点，不同用户使用同一个密码，其密文还是相同的。这就又回到了会遭遇高频统计攻击，预先注册攻击等问题。

　　口令的安全策略

　　在传统密码学家眼中只有一种加密是理想的，那就是“一次一密”，当然事实上这是不可能的。但如果我们套用这种词法，我们也可以说，口令安全策略的理想境界，我们可以称为单向、一人一密、一站一密。

　　单向：标准HASH算法的价值尽管在这个场景下，已经被推倒，但其单向性的思想依然是正确的，口令只要是能还原的，就意味着攻击者也能做到这一点，从而失去了意义，因此使用单向算法是必须的。

　　一人一密：同一个站点设置同样口令的不同用户，加密生成的密文内容并不相同。这样就能有效的应对结果碰撞和统计攻击。采用字典的攻击的方法基本是不收敛的。

　　一站一密：仅仅保证一人一密是不够的，还要保证使用同样信息、同样口令去注册不同网站的用户，在不同站点的口令加密结果是不同的。鉴于有大量用户用同样的信息、同样的口令去注册不同网站，如果能做到这一点，流失出的库信息会进一步打折扣。而攻击者基本会放弃生成密文字典的尝试。

　　实现这些说起来很简单，依然是HASH+SALT，关键在于每个站点要有不同的SALT，每个用户要有不同的盐。

（编辑：网站开发网_盐城站长网 ）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!