数据库密码为什么不能直接存

很多人以为把密码放进数据库就安全了，其实大错特错。如果直接把用户设置的“123456”这样的密码原样存进数据库，一旦黑客入侵或者内部人员能接触到数据库，所有人的密码就一览无余了。这不仅意味着用户的这个账户失守，更危险的是，很多人习惯在多个网站用同一个密码，这会引发连锁反应。历史上这样的教训不少，比如2012年领英（LinkedIn）的数据泄露事件，据公开报道，就是因为有大量密码以简单的、可逆的方式存储，导致数百万密码被破解。所以，第一个要牢记的原则就是：绝对、永远不要用明文存储密码。

给密码“上锁”的常见方法

既然不能明文存储，那就要把密码“加工”一下再存。最古老的办法是使用加密算法，比如对称加密。这就像用一把钥匙把密码锁进一个盒子再存起来，需要核对密码时，再用同一把钥匙打开盒子查看。但这个方法有个致命弱点：钥匙（即加密密钥）本身需要被严格保护，一旦钥匙丢了，所有的“盒子”都不安全了。因此，现在普遍认为，存储密码更好的方式是“哈希”。

哈希是一种单向的加工过程。你可以把密码变成一串看似乱码的“哈希值”，但这个过程理论上是不可逆的，无法从这串乱码倒推出原始密码。核对密码时，只需要把用户输入的密码用同样的方法“哈希”一次，比较两次得到的“哈希值”是否一致就行了。这样，数据库里存的永远不是密码本身。为了提高安全性，通常还会在哈希过程中加入“盐”。“盐”是一段随机生成的数据，每个用户都不同。在哈希前，先把密码和用户的“盐”混合，这样即便两个用户密码相同，最终存储的哈希值也完全不同，能有效抵御一种叫“彩虹表”的预计算攻击手段。

现在最推荐的安全“锁”：慢哈希函数

随着计算机算力的飙升，传统的哈希函数（如MD5、SHA-1）已经不够安全了，因为它们计算速度太快，黑客可以用强大的显卡每秒尝试数十亿次猜测。因此，现在安全领域的共识是使用 deliberately slow 的哈希函数，即有意识设计得很慢的哈希函数。这类函数在计算哈希值时，会有意消耗更多的计算资源和时间，对正常登录来说只是一次短暂的延迟，但对需要尝试海量密码的黑客来说，成本就会变得极高。目前被广泛推荐的是 bcrypt、scrypt 和 Argon2 这三种算法。例如，OWASP（开放式Web应用程序安全项目）在其密码存储备忘单中，就明确推荐使用这类适应性哈希函数。

除了加密，还要筑好“围墙”

光是选对加密技术还不够，必须有一系列防护措施来构建多层防线。首先，要实施“最小权限原则”。这意味着数据库和访问它的应用程序账户，只拥有完成其任务所必需的最低限度的权限，避免被攻破后造成更大范围的破坏。其次，所有对数据库的访问，尤其是涉及密码等敏感数据的操作，都必须通过安全的日志记录下来，以便在出现问题时可以追溯和审计。再者，对密码本身要有要求，比如强制用户设置一定长度和复杂度的密码，并定期提示（而非强制）更新，防止因密码过于简单而被猜解。最后，也是最关键的一点，时刻保持软件和系统的更新。许多重大数据泄露事件，最初都是由于没有及时修补已知的安全漏洞导致的。正如安全专家常说的：安全不是一个产品，而是一个持续的过程。