Я ищу совет о том, как безопасно хранить пароли в MySQL с помощью PHP.
Оглядываясь на ограничения самого PHP, я хочу узнать больше о соле, хэшировании и шифровании этих плохих мальчиков.
Очевидно, что люди будут продолжать использовать слабые пароли, если не будут вынуждены делать иначе, но именно так я храню их, что важно для меня. Пароли моего пользователя гораздо важнее, чем сама база данных, и поэтому я хочу сохранить их таким образом, чтобы они были кропотливыми и однообразными для любого скрипта, который пытался сделать обратный. Очевидно, что с должной осмотрительностью почти все может быть побеждено, но я бы не прочь сделать это особенно назойливым.
Есть два сценария, на которые мы смотрим.
Все советы по этой теме любезно оценены.
Используйте bcrypt . Если у кого-то есть таблица пользователей вашей базы данных, то они могут использовать таблицы грубой силы / радуги / и т. Д. До их содержания. Даже с солью, если вы используете MD5 или какой-то другой алгоритм быстрого хеширования (которые, кстати, не предназначены для решения этой проблемы); это всего лишь вопрос времени, прежде чем он может быть взломан.
Любой известный и широко поддерживаемый алгоритм хэширования будет иметь такой же базовый «недостаток» (если вы можете это назвать, это по определению). Разница заключается в том, что bcrypt работает медленно, как меласса при выполнении операции хэширования, делая атаку грубой силы гораздо менее эффективной.
Для совершенно отличной дискуссии о достоинствах bcrypt , об опасности других подходов и сложности защиты паролем в целом, прочитайте эту тему . В нем много замечаний многих людей, которые гораздо более осведомлены о таких вещах, чем я, и он, надеюсь, поможет вам понять больше вопросов, поставленных на карту.
Предполагая, что вы используете имя пользователя и пароль в качестве токенов аутентификации, вы можете безопасно хранить следующее, чтобы гарантировать, что данные не могут быть скомпрометированы.
Используя схему, злоумышленник не может использовать таблицы радуги против вас, и пароли не могут быть восстановлены никакими (разумными) средствами. (То есть, пока ваш нападающий не является правительством)
Несмотря на то, что у нападающего есть соли и хэш-пары, невозможно использовать таблицы радуги, потому что все возможные хэши нужно будет вычислить в любом случае, используя соль, которую им дали, так что это новая атака грубой силы для каждого пользователя ,
Даже с исходным кодом и злоумышленником не удастся заполучить пароли, потому что сила / безопасность в алгоритме хеширования, а не ваш код.
Объедините это с использованием bcrypt в соответствии с ответом Donut, и вы действительно совершенно безопасны. То есть:
Принимая советы отсюда , для дополнительного удовольствия вы можете динамически изменить свою соль. Например, используйте разные соли для имен пользователей разной длины, используйте дату регистрации пользователя как соль. Это делает так, что даже если кто-то попадает в вашу базу данных, они не могут просто повторно генерировать хеш, они должны вычислить хэш-таблицу для каждой соли, которую вы использовали.
Если ваши пользователи через Интернет, OpenId будет одним из ваших лучших вариантов. http://openid.net/
Если ваши пользователи находятся в вашей сети, можете ли вы интегрировать систему безопасности?
Другими словами, не сохраняйте свои пароли.
Обычно «соленые» пароли (например, с помощью bcrypt) означают, что не сам пароль сохраняется, а только что-то вроде
salt hash(salt with password appended)
Теперь, если у девочки есть ваша база данных (и, конечно, код – нет смысла хранить секретный код), он может только угадывать пароли, вычислять соленый хеш и сравнивать. Если хеш-функция дорогая (например, bcrypt), то и гадание дорого.
Это просто
store(sha256("somesalt" + password));
И никто не сможет его отменить 🙂
См. Также: https://stackoverflow.com/questions/3897434/password-security-sha1-sha256-or-sha512