Почему вы предпочитаете хешировать пароли на уровне приложения, а не использовать 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

Независимость от базы данных - это хорошо. Я рассматриваю все системы СУБД как простые движки SQL.

Добавлен

В наши дни классные дети даже не используют SQL. Вместо этого используется промежуточный слой Object-Relational Mapping (ORM). Например, ActiveRecord в Rails или аналог .

PHP ORM

A SO Вопрос о библиотеках ORM для PHP . Нет SQL!

Последняя мысль

Наконец, с точки зрения производительности, часто СУБД является наименее расширяемой. - Уровень приложения может быть клонирован намного быстрее, чем разделение хранилища данных. Таким образом, ваш пробег может отличаться, но я бы осторожно предположил, что переход большей функциональности на уровень СУБД был бы выигрышем для всей системы.

Скорее, часто наоборот - перенос функциональности из СУБД там, где это целесообразно. Например, в наши дни широко используется MemCache, несмотря на системы СУБД, включая их собственные кэши запросов.

Answer 3

Основная проблема в том, что вы не можете выполнить итерацию своей хеш-функции, если вы делаете это в MySQL. Неспособность повторить вашу хэш-функцию делает вас уязвимыми к атакам методом "грубой силы" в автономном режиме, потому что SHA2 очень быстр.

Вы действительно должны использовать хорошо известную функцию хранения паролей, такую ​​как bcrypt или PBKDF2, которая, вероятно, изначально не поддерживается в MySQL.

См. в этой статье для хорошего обсуждения хранения пароля и почему вы должны использовать хорошую, медленную функцию.