为什么选择在应用层对密码进行散列，而不是使用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专家)

Answer 1

这不是散列密码;但是如果它是(如果你在那里传递一个明文密码)…

数据库连接协议一般不加密。不使用此功能的一个原因是您正在通过网络以明文形式发送密码。如果有人控制了你的网络服务器和数据库之间的路由器，他们就可以拦截这些数据。

Answer 2

数据库独立是一件好事。我把所有的DBMS系统看作是简单的SQL引擎。

添加

这些天，酷孩子甚至不使用SQL。相反，使用中间的对象关系映射(Object-Relational Mapping, ORM)层。例如Rails中的ActiveRecord或类似的

PHP ORM

一个关于PHP ORM库的问题。没有SQL !

最后的想法

最后，从性能的角度来看，DBMS通常是最不容易扩展的。——应用程序层的克隆速度比数据存储分片要快得多。因此，您的情况可能会有所不同，但我要谨慎地假设将更多的功能转移到DBMS层将是整个系统的胜利。

更确切地说，通常是相反的——在合理的情况下将功能移出DBMS。例如，尽管DBMS系统包括自己的查询缓存，但现在广泛使用MemCache。

Answer 3

主要问题是，如果你在MySQL中做的话，你不能迭代你的哈希函数。没有迭代你的哈希函数会让你容易受到离线暴力攻击，因为SHA2非常快。

您应该真正使用一个众所周知的密码存储功能，如bcrypt或PBKDF2，这可能不是MySQL本地支持的。

请参阅本文，详细讨论密码存储以及为什么需要使用一个好的、慢的函数。