Надежное хранение пароля юзера

Тестовая задача одного из нанимателей: создать функционал регистрации/аутентификации юзера. Ну я и создал. При этом пароли храню в БД по схеме md5-хеш + соль. Я уже видел такое решение и посчитал его надежным. Позже, на собеседовании возникли вопросы, почему и зачем. Начали разбирать теоретические ситуации и я оказался в тупике :) Под катом - размышления на тему надежного хранения паролей юзеров.

Здесь я не рассматриваю способы аутентификации типа basic, через ActiveDirectory и т.д. Только тот вариант, что встречается на большинстве сайтов: вход через логин/пароль на html-форме.

В БД в одном поле храним хеш пароля, в другом - соль. Соль - это случайная последовательнось N символов, каждому юзеру - своя. Все проще - php::password_hash(). Там и алгорим хеширования оптимальный и соль из коробки. Только в базе под хеш нужно 255 символов, чтобы не произошло случайного обрезания пароля. На данный момент такой длины поля достаточно для любого алгоритма хеширования.

Возможные векторы атак и защиты

Ситуация 1: атака через HTTP по словарю (разновидность brute-force атаки). Никакие хеши/соли не защитят от такой атаки, если юзер задал пароль "12345". Поэтому вводим минимальные требования к паролю (длина, сложность). Можно добавить ввод капчи при входе (взламывается за 50 центов/час группой безработных индусов), учет частоты обращения на конкретный аккаунт и блокировка на N-цать минут после N-ти ошибок (возможен аналог DоS-атаки на учетки, приведет к массовой блокировке юзеров). Фильтрация по IP - баловство, запрос через список проксей может оказаться де-факто при такой атаке.

Ситуация 2: хакер спер базу. Он может у себя на локалке вести атаку по словарю. У него есть хеши паролей, соли и пример хеша/соли своего пароля. Но он не знает, как именно проводилось хеширование. Поэтому в коде делаем нетривиальный расчет хеша. Пример: 4 прохода хеширования, сначала md5() пароля, на 2-ом шаге md5() полученного хеша и т.д. На каждом шаге добавляем соль, на нечетном - в начало, на четном - в конец, на 3-ем шаге вообще не пишем соль. Без знания алгоритма хеширования подбор пароля будет очень затруднен.

Можно не использовать соль в принципе. Но тогда придется придумать что-то сложнее, чем просто N итераций хеширования, т.к. это легко "расколоть". Например, переворачивать исходный пароль задом наперед, или разбить на части и переставить их местами. Вообщем, соль - не панацея, напрягите фантазию :)

[UPD]: а можно не заморачиваться так и использовать все тот же password_hash().

Ситуация 3: хакер спер только код. Он знает алгоритм хеширования, но базы нет и это равносильно ситуации 1.

Ситуация 4: хакер спер не только базу, но и код. А вот это уже пичалька, джентельмены.. Нормального решения тут нет. Можно перехешировать пароль 100500 раз, чтоб одна процедура расчета конечного хеша занимала много времени (например, 200мс). И единственное, что замедлит при этом хакера, это необходимость так же перехешировать свой словарь для атаки, причем не весь сразу, а в процессе подбора.

В зависимости от технической оснащенности хакера расчетное время может сильно меняться. Учтите, что каждые 4 года производительность железа удваивается. Что будете делать, загонять число итераций хеширования в бесконечность? Да и сама ситуция, когда хакер смог получить копию сайта - это "абзац" защиты, и сокрытие паролей в таком случае - меньшая из ваших проблем.

Наиболее непробиваемой на данный момент защитой юзера мне кажется смс-ка с кодом подтверждения при входе. Т.е. двухшаговая аутентификация: логин/пароль, потом смс-ка. Или использование сертификатов/ЭЦП. Зависит от того, что защищаем.