Хеш или шифрование пароля: почему пароли хранят в виде хешей

Хранение паролей проектируют исходя из худшего случая: база данных сервиса попала к постороннему. Если пароли лежат открытым текстом, злоумышленник сразу получает готовые учётные данные, причём люди часто повторяют пароли на разных сайтах. Если пароли зашифрованы, всё зависит от ключа, а он обычно хранится рядом с приложением и может быть похищен вместе с базой.

Хеш-подход меняет постановку задачи: исходный пароль в системе не хранится вообще, поэтому украсть нечего, остаётся лишь подбирать.

При регистрации сервис вычисляет хеш пароля и сохраняет его. При входе пользователь вводит пароль, сервис снова вычисляет хеш и сравнивает с сохранённым. Если они совпали, пароль верный. Расшифровывать ничего не приходится.

Это объясняет, почему сервис, который умеет присылать вам старый пароль по почте, хранит его небезопасно: значит, пароль доступен ему в исходном виде.

Именно поэтому для проверки пароля достаточно сравнения хешей, и сервису безопасно вообще не знать исходную строку. Он видит её лишь на миг при вводе, вычисляет отпечаток и забывает.

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

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

Хеширование не спасает от слабых паролей: если пользователь выбрал распространённое слово, его подберут по словарю даже при хорошей функции. Не защищает оно и от перехвата пароля при вводе, от фишинга и от вредоносной программы на устройстве.

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

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

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

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

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

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

Если вы разрабатываете сервис, применяйте проверенные библиотеки для хранения паролей, уникальную соль и современные медленные функции, а не собственные схемы.

Заведите привычку проверять важные аккаунты раз в полгода: сменился ли пароль после сообщений об утечках, включена ли вторая проверка входа, нет ли незнакомых устройств в списке сеансов. Эти пять минут заметно снижают риск.

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