Хранение Паролей в Базе Данных

Привет, хабр! Сегодня, в процессе разработки системы аутентификации для своего проекта передо мной встал выбор — в каком виде хранить пароли пользователей в базе данных? В голову приходит множество вариантов. Самые очевидные:
- Хранить пароли в БД в открытом виде.
- Использовать обычные хэши crc32, md5, sha1
- Использовать функцию crypt
- Использовать статическую «соль», конструкции вида md5(md5($pass))
- Использовать уникальную «соль» для каждого пользователя.
Первый вариант отпал конечно сразу же. Использование обычных хэшей после недолгого обдумывания тоже пришлось отбросить по ряду причин.
Коллизия хеш-функций
Коллизия хеш-функции возникает, когда она выдает одинаковый результат на разные входные данные. Конечно же, вероятность этого достаточно мала, и зависит от длины хэша. Однако устаревшая (но до сих пор иногда используемая) функция crc32 возвращает в качестве хэша 32-битное целое число. Т.е., чтобы подобрать пароль к такому хэшу, по теории вероятности нужно получить 2^32 = 4 294 967 296 различных хэшей. Даже на моем бесплатном хостинге crc32 работает со скоростью порядка 350 000 раз в секунду — посчитайте сами сколько нужно секунд, чтобы взломать такой хэш ;)Радужные таблицы
Радужные таблицы состоят из хэшей наиболее часто употребляемых паролей — имен, дат рождения, названий животных и т.п. Эти таблицы могут включать миллионы, миллиарды значений, но работа с ними относительно быстра, и проверить хэш на соответствие одному из значений не составляет никакого труда. Частично, от них можно защититься с помощью «соли» или конструкций типа md5(sha1(md5($pass))).$password = "easypassword"; // простейший пароль, вводимый пользователем и, вероятно, имеющийся в радужной таблице echo sha1($password); // Хеш такого пароля при обработке функцией sha1 будет следующим: 6c94d3b42518febd4ad7478022f956 $salt = "f#@V)Hu^%Hgfds"; // используя случайный набор символов, мы можем изменить значение хеша echo sha1($salt . $password); // а вот хеш для пароля, сдобренного солью: cd3378628c0d9336af69b74d9d71a5 // такая комбинация пароля и его хэша не найдётся ни в одной радужной таблице
Радужные таблицы. Часть 2
Статическая соль и тому подобные конструкции могут служить достаточно хорошо… пока структура этих конструкций и соль хранятся в тайне. Если же злоумышленник вызнает секрет хэширования — он с легкостью сможет модифицировать под него свою «радужную таблицу». А т.к. мы не можем абсолютно полагаться на систему защиты своего сервера, нужно искать другой вариант. Одним из решений может быть генерация уникальной соли для каждого юзера, что-то вроде:$hash = sha1($user_id . $password);
Еще лучше генерировать совсем случайную соль, например так:
// генерируем случайную строку длиной в 22 символа function unique_salt { return substr(sha1(mt_rand), 0, 22); } $unique_salt = unique_salt; $hash = sha1($unique_salt . $password); // формируем хеш пароля
Конечно, уникальную соль придется вносить в базу данных, но даже получив доступ к ней, злоумышленник вряд ли сможет сгенерировать несколько миллионов радужных таблиц.
Скорость хэширования
Казалось бы — чем быстрее, тем лучше. Чем быстрее сгенерируется хэш, тем быстрее наш юзер сможет зарегистрироваться и начать уже приносить профит. Однако чем больше скорость хэширования, тем быстрее его сможет подобрать и хакер.Современные ПК с мощными GPU, могут рассчитывать миллионы хэшей в секунду и больше. А это позволяет ломать пароли простым подбором, с помощью брутфорса-атак. Считаете что пароль в 8 символов достаточно безопасен? Если в пароле используются символы в нижнем и верхнем регистрах и цифры, то общее количество возможных символов составит 62 (26+26+10). Для пароля длиной в 8 символов, существует 62^8 различных комбинаций (порядка 218 триллионов). Со скоростью в 1 миллиард хэшей в секунду (достаточно маленькая для брутфорс-атаки), пароль будет сломан примерно за 60 часов. А для наиболее распространенной длины пароля в 6 символов, длительность расшифровки составит меньше двух минут.
Source: habrahabr.ru
kubernetes приложения на java статьи, примеры