为什么选择在应用层哈希密码而不是使用MySQL的SHA2()函数？

Question

我之前一直在将密码通过php（或其他方式）哈希后再插入数据库。今天我发现mysql 5.5内置了哈希功能，因此我可以像这样做：

+-----------------+--------------+------+-----+---------+----------------+
| Field           | Type         | Null | Key | Default | Extra          |
+-----------------+--------------+------+-----+---------+----------------+
| user_id         | int(11)      | NO   | PRI | NULL    | auto_increment |
| user_uname      | varchar(63)  | YES  | UNI | NULL    |                |
| user_password   | binary(32)   | YES  |     | NULL    |                |
+-----------------+--------------+------+-----+---------+----------------+

--set password
UPDATE users SET user_password=UNHEX(SHA2(CONCAT('username','salt'), 256))\
WHERE user_id = 1;

-- validate password 
SELECT (SELECT user_password FROM users WHERE user_id=1) = \
SHA2(CONCAT('username','salt'), 256);

这样做有什么不好的原因吗？（我并不是mysql专家）

- ysaw

Answer 1

数据库独立性是一件好事。我将所有DBMS系统视为简单的SQL引擎。

添加

现在，时髦的孩子们甚至不使用SQL。而是使用中间Object-Relational Mapping（ORM）层。例如Rails中的ActiveRecord或similar。

PHP ORM

一个有关PHP ORM libraries的SO问题。没有SQL！

最后的想法

最后，从性能的角度来看，通常是DBMS最不可扩展的。应用程序层可以比分片数据存储更快地克隆。因此，你的里程可能会有所不同，但是我会谨慎地假设将更多的功能移动到DBMS层将成为整个系统的胜利。

相反，通常是将功能合理地移出DBMS。例如，尽管DBMS系统包括自己的查询缓存，但这些天广泛使用MemCache。

- Larry K

---

不是所有受欢迎的孩子都认为ORM是一个好主意。 - ysaw

Answer 2

这不是对密码进行哈希处理；但如果你在此处传递的是明文密码...

数据库连接协议通常不加密。不使用此功能的原因之一是在传输过程中以明文形式发送密码。如果有人控制了您的web服务器和数据库之间路径上的路由器，他们可以拦截这些数据。

因此，您会为系统的安全引入弱点。

- Bill Barry

---

这是一个非常好的观点，我认为这可能会敲定交易。 - ysaw

Answer 3

主要问题是如果在MySQL中进行哈希函数迭代是不可能的。未能迭代哈希函数会使您容易受到离线暴力攻击的威胁，因为SHA2非常快。

您应该真正使用一个众所周知的密码存储函数，如bcrypt或PBKDF2，这在MySQL中可能没有本地支持。

请参阅this article以获取有关密码存储的良好讨论以及为什么需要使用良好、缓慢的函数。

- Cameron Skinner