Подойдёт ли авторизация средствами MySQL?

Question

[Посторонним В.]

При регистрации пользователя его пароль присаливается рандомной строкой, перегоняется через sha1, снова присаливается, снова прогоняется - и так 5 раз. К результату лепится соль и всё это пишется в поле таблицы MySQL.

При попытке логина аналогичные действия выполняются с введённым паролем:
Из БД запрашивается хеш пароля запрошенного юзера, из него берется соль, и с участием введённого пароля и полученной из БД соли выполняется прогонка по вышеописанному алгоритму. Затем результат сравнивается с хешем в БД. Если совпало - юзер авторизован.

Вопрос заключается в том, как это реализовывать - через сервер MySQL, то есть все расчеты sha1 и проч. выполнять на серваке, или просто получать с MySQL строки, а в PHP уже всё считать и сравнивать?
Конечно строка запроса будет приличная, но я часто читаю, что не надо делать на PHP то, что можно сделать на сервере БД.

Comments

[Алексей Уколов]

пароль присаливается рандомной строкой, перегоняется через sha1, снова присаливается, снова прогоняется - и так 5 раз. К результату лепится соль и всё это пишется в поле таблицы MySQL.

Очень зря реверс строки не делаете, это же какая угроза безопасности!

[Посторонним В.]

Алексей Уколов: всё шутите) А если серьезно: предлагаете упростить кодирование и реализовать на MySQL?

[Алексей Уколов]

Посторонним В.: Да, конечно, такая "защита" совершенно излишняя. Но я не думаю, что логика аутентификации должна лежать в БД.

[Посторонним В.]

Алексей Уколов: вообще алгоритм выдумывался давно, но тут идея такова, что если украсть БД юзеров - пароль определить невозможно даже подбором, так как для этого надо знать алгоритм шифрования.

[Алексей Уколов]

Посторонним В.: Для этого соль и нужна

[Посторонним В.]

Алексей Уколов: не скажите. Вот например uCoz соль не спасла: audiophilesoft.ru/blog/ucoz_password_hash/2015-02-02-35

[Алексей Уколов]

Посторонним В.: ага, а еще Битрикс - Как сменить пароль Битрикс через myadmin?

[Алексей Уколов]

Я не думаю, что логика аутентификации должна лежать в БД.
В БД имеет смысл делать все операции, которые связаны с хранением данных и их целостностью - использовать внешние ключи вместо проверок на стороне скрипта, например.

[FanatPHP]

Сергей Сергеев: там не будет ничего интересного

Answer 1

[FanatPHP]

1. К авторизации этот вопрос не имеет отношения.
поскольку буквальный ответ на вопрос из заголовка будет, разумеется - НЕТ. Одними средствами БД авторизовать никого нельзя.

2. Вопрос, на самом деле - где хэшировать пароль. В скрипте или БД.
В итоге вопрос получается дурацкий, поскольку очевидно, что в БД придется городить код из гуана и палок, без малейшей на то причины.

Еще одно соображение - безопасность. Пароль в принципе нежелательно отправлять в БД в открытом виде, чтобы он потом не засветился в каких-либо логах.

3. Весь этот детский лепет с sha1 в цикле заменить на php.net/manual/en/function.password-verify.php