Почему пароль остаётся слабым звеном
Можно закрыть сервер по всем правилам, настроить безопасность сайта и всё равно потерять аккаунт из-за одного слабого пароля. Причина проста: люди повторяют пароли. Один и тот же пароль стоит на почте, в магазине и на форуме — и когда форум сливают, тем же паролем открывают почту, а через почту — всё остальное.
Атака называется credential stuffing: злоумышленник берёт миллионы пар «логин-пароль» из старых утечек и автоматически подставляет их на других сайтах. Ему не нужно вас взламывать — за него это уже сделали. Поэтому надёжность пароля — это не про сложность запоминания, а про два правила: он должен быть длинным и уникальным для каждого сайта.
Как утекают пароли
Пароль редко «угадывают». Гораздо чаще он утекает целыми базами:
- Взлом сервиса — база пользователей с паролями попадает в сеть. Если пароли хранились плохо, их быстро расшифровывают.
- Фишинг — вы сами вводите пароль на поддельной странице, неотличимой от настоящей.
- Вредоносное ПО — стилеры собирают сохранённые в браузере пароли прямо с заражённого устройства.
- Повторное использование — утечка на одном сайте автоматически компрометирует все остальные, где стоит тот же пароль.
Итог всегда один: пароль оказывается в публичных базах, которых уже сотни миллионов записей. Хорошая новость — по этим же базам можно проверить, засветился ли ваш пароль, и сделать это безопасно.
Что делает пароль надёжным
Надёжность измеряется не наличием «спецсимвола», а энтропией — числом вариантов, которые пришлось бы перебрать. Длина влияет на неё сильнее, чем экзотические символы: пароль из четырёх случайных слов надёжнее короткого «P@ss1!».
- Длина — минимум 12–16 символов, для важных аккаунтов больше.
- Случайность — не имя, дата или слово из словаря, а действительно случайный набор.
- Уникальность — свой пароль для каждого сайта, чтобы одна утечка не открывала остальные.
Придумывать такое в голове бессмысленно. Проще сгенерировать: наш генератор паролей создаёт длинный случайный пароль прямо в браузере, криптостойко и не отправляя его никуда.
Как проверить пароль на утечку
Проверить, есть ли пароль в известных утечках, можно, не раскрывая сам пароль. Работает это по модели k-анонимности: пароль хешируется прямо в браузере, на сервер уходят только первые пять символов хеша, в ответ приходит список подходящих под этот префикс — и совпадение ищется уже локально. Сервер никогда не видит ни пароля, ни его полного хеша.
Именно так устроена наша проверка пароля на утечку: она сверяет пароль с базой Have I Been Pwned, ничего не сохраняя. Если пароль нашёлся в утечках — считайте его скомпрометированным и меняйте везде, где использовали. Такую же проверку полезно встраивать в форму регистрации и смены пароля, чтобы предупреждать пользователя о ненадёжном пароле до того, как он его установит.
Менеджеры паролей и двухфакторная аутентификация
Длинные уникальные пароли невозможно держать в голове — и не нужно. Менеджер паролей генерирует, хранит и подставляет их за вас; вы помните только один мастер-пароль. Это единственный практичный способ иметь разный надёжный пароль на каждом сайте.
Второй слой — двухфакторная аутентификация (2FA). Даже если пароль утёк, без второго фактора войти не получится. Порядок надёжности: аппаратный ключ или приложение-аутентификатор надёжнее, чем коды по SMS, которые перехватывают через подмену SIM. Включите 2FA хотя бы на почте и в банке — это те аккаунты, через которые восстанавливают все остальные.
Как хранить пароли на бэкенде (для разработчиков)
Если вы делаете сервис с регистрацией, ответственность за пароли пользователей на вас. Базовые правила не обсуждаются:
- Никогда не храните пароли в открытом виде и не шифруйте их обратимо — только необратимый хеш.
- Используйте медленные адаптивные функции — bcrypt, scrypt или argon2 — с солью для каждого пароля. Обычный SHA-256 для этого не годится: он слишком быстрый и подбирается на GPU.
- Проверяйте новые пароли на утечку при регистрации и смене — по той же k-анонимности, не отправляя пароль наружу.
- Ограничивайте попытки входа и добавляйте 2FA, чтобы утечка базы не означала мгновенный доступ.
Мы закладываем это в архитектуру, когда делаем веб-приложения и SaaS: аутентификация и хранение секретов проектируются с самого начала, а не прикручиваются потом.
Чек-лист безопасности паролей
- Длинный (12+), случайный и уникальный пароль для каждого сайта.
- Менеджер паролей вместо запоминания и повторов.
- Двухфакторная аутентификация везде, где есть, — хотя бы на почте и в банке.
- Проверка важных паролей на утечку; при совпадении — немедленная смена.
- Для разработчиков: argon2/bcrypt с солью, лимит попыток, проверка на утечку при регистрации.
Частые вопросы
Безопасно ли проверять пароль на чужом сайте?
Зависит от того, как устроена проверка. Правильная проверка использует k-анонимность: пароль хешируется в вашем браузере и наружу уходят только первые пять символов хеша, поэтому сам пароль сервер не видит. Никогда не вводите пароль в форму, которая отправляет его целиком.
Какой пароль считается надёжным в 2026 году?
Длинный, случайный и уникальный. Практический минимум — 12–16 символов без словарных слов и личных данных, свой для каждого сайта. Длина важнее «спецсимволов»: фраза из нескольких случайных слов надёжнее короткого набора знаков.
Нужен ли менеджер паролей?
Да, это самый практичный способ иметь разный надёжный пароль везде. Вы запоминаете один мастер-пароль, а менеджер создаёт и подставляет остальные. Риск компрометации самого менеджера гораздо ниже, чем риск повторного использования паролей.
SMS-коды — это надёжная двухфакторная аутентификация?
Лучше, чем ничего, но слабее остальных вариантов: коды по SMS перехватывают через подмену SIM. Приложение-аутентификатор или аппаратный ключ надёжнее. Но любая 2FA сильно лучше её отсутствия.
Как правильно хранить пароли пользователей на сервере?
Только необратимым хешем через argon2, scrypt или bcrypt с уникальной солью для каждого пароля — никогда в открытом виде и не обратимым шифрованием. Обычный SHA слишком быстрый и не подходит. Дополнительно ограничивайте попытки входа и предлагайте 2FA.
