谈谈系统密码存储策略

最近IT界很火的一则新闻是华住的数据库泄露问题，身边很多人在讨论数据库安全的问题，大家经常说提升密码复杂度、加密等，但是很多人并不知道在开发的时候，用户的密码怎么处理，或者说，处理的并不恰当，这篇文章主要介绍在系统设计的过程中，我们的密码究竟应该怎么处理才最大限度的保证安全。

密码加密的重要性？

还是从脱库说起，数据库被人拉走了，最可怕的是什么？个人手机、身份证、地址？？这些是很重要，但是，其实个人隐私数据，获取的难度不是很大，而且不容易直接对一个人造成巨大的伤害，但是，密码被人知道了，就是很可怕的事情。因为，大部分人不同的系统都是共用密码。这个错误比较低级，但是很常见，所以，密码，是被脱库后最容易被人利用。所以，密码是必须加密的，不把用户密码加密的系统和公司，都该判刑。

密码管理的入门要求

密码管理产品级别的需求，大家都能看到的是，提升密码的复杂度和管理策略，一般包括：

• 密码加密保存，并且是不可逆的。
• 密码更长更复杂。如：密码长度大于8位，必须是大小写字母和数字的组合。
• 定期修改密码策略。
• 登录输入密码错误多次，需要输入验证码，甚至是锁定账户。
  以上都是一些基础，但是非常有效的方案，这些产品设计不是我们讨论的重点，我们重点说说具体的实现。
  在技术上，实际密码我们是怎么存储的呢？

String password=MD5("明文")

对用户的输入进行MD5加密后，就直接保存在数据库，可能15年前这还是比较安全的存储方式，但是现在，MD5已经不再安全，越是简单的密码，被撞库获取到原文的可能性非常的高，所以直接使用MD5加密后保存密码，显然已经是非常不安全的方式了。

密码+salt

前文说道，密码太短，显然已经不安全了，那么为了提升负责度，就会强制把用户的密码变得更加复杂，于是，就产生了密码加salt的方案。salt肯定是需要一个比较的复杂的字符串，长度可以长一点。而且最好是，每个用户的salt是不一样的。以前的数据库结构是：

ID	用户名	密码
1	user1	34234sdfse2342dggs234s
2	user2	d34desf3432sdf23423sdf

那么比较安全的方式应该是：

ID	用户名	密码	salt
1	user1	sdf452342sdfsd23234sdf	982934&7934708hHG12&%&()()()IUHUHGggifiknsdf
2	user2	234df3234sdf234asfddsd	&&8uhhhkKHKl9(7KBKH&……)adksjknklasdlfkjkkkkk

String password=SHA1("明文"+salt);

这里，我们用了相对而言撞库难度比较大的SHA1的加密方式来取代MD5加密，这样基本就是一个比较安全的密码了，即使数据被脱库了，撞库也很基本不可能破解出明文。

但是，这样就真的安全了吗？不一定，我们还少了传输加密以及客户端加密。

客户端和传输加密

首先我们说说传输加密，其实，这个现在已经有很标准的解决方案——https，这里我们就不多说了。
我们主要所属说说客户端加密：
可能大家觉得有了传输加密了，实际客户端加密也不太重要，显然不是，这里有个很重要的场景就容易出现风险：

• 日志。大家的系统都会统一记录日志，针对密码这类敏感的信息，如果记录了日志，而且大家记录的都是用户输入的明文，这样非常危险。
• 内网劫持。如果数据还没有到公网，在内网就被劫持了，有可能暴露明文的密码。

所以，客户端加密也是很有必要的。现在的前端技术都是支持MD5加密，所以我们就在前端对用户的数据进行了MD5加密。
客户端代码：

var password=md5("明文");

String password=SHA1("客户端MD5加密后的支付"+salt);

实际，这样最终存在数据库的，就是一个做了双重加密的支付。网络传输和日志记录的就是单次加密的字符，整体的安全度就非常高了。

总结

这样，一个好的密码体系应该就是这样了：

• 客户端MD5针对用户输入的明文加密后提交到服务端。
• 服务端根据用户生成一个复杂的随机salt。
• 根据随机salt和接收到的密码，sha1加密，生成密码保存到数据库。

这是一篇非常基础的文章，但是却被很多的开发和产品忽略，风险总在一念之间。安全永远是一个相对的概念，我们只能提升破解安全的成本，无法做到绝对的安全。

---

欢迎大家关注我的公众号交流、学习、第一时间获取最新的文章。
微信号：itmifen