Хеширование паролей: почему сайты не должны хранить пароли в открытом виде

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

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

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

Что такое хеширование паролей и как работает хеш

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

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

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

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

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

Как сайты хранят и проверяют пароли пользователей

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

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

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

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

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

Почему хранить пароли в открытом виде опасно

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

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

Подробнее о том, как действовать после подобных инцидентов, можно прочитать в материале Как проверить утечку данных и защитить свои пароли в 2025 году.

Даже обычного хеширования недостаточно, если для хранения паролей используется слишком быстрый алгоритм. Например, SHA-256 хорошо подходит для проверки целостности данных, но изначально не предназначен для безопасного хранения паролей. Современные видеокарты способны вычислять огромное количество таких хешей за короткое время, поэтому простые и популярные пароли можно подобрать перебором.

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

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

Соль для хеширования: зачем она нужна

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

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

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

Соль особенно полезна против заранее подготовленных баз хешей, известных как rainbow tables. Без соли атакующий может заранее вычислить хеши миллионов распространённых паролей и затем быстро искать совпадения в украденной базе. Уникальная соль заставляет выполнять подбор отдельно для каждого пользователя.

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

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

Argon2, bcrypt и другие алгоритмы для хранения паролей

Для паролей недостаточно выбрать любую криптографическую хеш-функцию. Алгоритмы вроде SHA-256 или SHA-512 специально созданы быстрыми, что полезно при проверке файлов и цифровых подписей, но становится недостатком при защите паролей. Чем быстрее считается хеш, тем больше вариантов злоумышленник способен перебрать за секунду.

Поэтому для password hashing используют специализированные алгоритмы, которые намеренно делают вычисление более дорогим. Один из самых известных вариантов - bcrypt. Он позволяет задавать вычислительную сложность: чем выше параметр cost, тем больше времени требуется для расчёта одного хеша. Сервер практически не замечает такую задержку при обычном входе пользователя, а массовый перебор миллионов вариантов существенно замедляется.

Более современный подход предлагает Argon2. Алгоритм позволяет ограничивать атакующего не только временем вычислений, но и объёмом необходимой памяти. Это особенно важно против перебора на GPU и специализированном оборудовании, которое эффективно выполняет огромное количество простых операций параллельно. Для хранения паролей обычно применяется вариант Argon2id, сочетающий защитные свойства разных режимов Argon2.

При сравнении bcrypt vs Argon2 нельзя сказать, что bcrypt внезапно стал бесполезным. Он десятилетиями применяется в реальных системах и при правильных настройках остаётся серьёзной защитой. Однако для новых проектов чаще предпочтителен Argon2id благодаря более гибкой настройке вычислительной сложности и потребления памяти.

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

При этом индустрия постепенно развивает и способы входа, при которых пользователю вообще не требуется передавать серверу привычный пароль. Подробнее об этом можно прочитать в материале Системы безопасности без паролей: что такое passwordless-аутентификация и как работают Passkeys, FIDO2 и WebAuthn.

Заключение

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

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

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