Как сайты хранят пароли: почему plaintext опасен и что делать

Что такое plaintext и почему это опасно

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

Представьте, что ваш пароль — Pa$$w0rd. Если сайт хранит его в открытом виде и базу взломают, киберпреступник просто пролистывает список аккаунтов, находит ваш адрес электронной почты и видит Pa$$w0rd. Неважно, насколько сложен ваш пароль — если он сохранён в plaintext, он полностью уязвим.

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

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

Как пароли должны храниться: простая модель

Коротко о терминах:

• Хеш — одностороннее преобразование данных в набор символов. Невозможно получить исходный пароль из хеша обычными средствами.
• Соль (salt) — случайные данные, добавляемые к паролю перед хешированием, чтобы один и тот же пароль давал разные хеши.
• Медленный хеш — алгоритм, специально рассчитанный на замедление вычислений (например, bcrypt, scrypt, Argon2). Это делает перебор парольного словаря значительно медленнее.

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

Дальше — меры усиления:

• Соль для каждого пароля индивидуальна.
• Используют «медленные» хеши (bcrypt, scrypt, Argon2) с параметрами, которые можно регулировать по мощности оборудования.
• Иногда добавляют «pepper» — секретную глобальную строку, хранящуюся отдельно и недоступную в базе.
• Ограничивают скорость попыток входа (rate-limiting), используют логирование и мониторинг подозрительных входов.

Эти меры делают массовый взлом и перебор паролей намного сложнее.

Как понять, хранит ли сайт пароли в открытом виде

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

• Если при регистрации или в приветственном письме вам прислали ваш пароль в явном виде — это почти верный признак plaintext.
• Если при нажатии “Забыли пароль” сайт отправляет вам текущий пароль, а не ссылку для сброса — это дефинитивный признак: пароль хранится в читаемом виде.
• Поддержка или техподдержка, присылающая ваш пароль по запросу, скорее всего, имеет доступ к паролю в базе.
• Сайты, включённые в списки, посвящённые нарушителям (например, специализированные ресурсы по plaintext offenders), тоже дают повод беспокоиться.

Проверка на практике: зарегистрируйтесь с уникальным, легко узнаваемым «заглушечным» паролем (например, MyTestPlainText123!) и нажмите «Забыли пароль». Если в письме вы видите именно этот пароль — сайт хранит его в открытом виде.

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

Быстрая проверка — блок-схема

flowchart TD
  A[Начало: есть аккаунт на сайте?] --> B{При регистрации получили письмо
с вашим паролем?}
  B -- Да --> C[Скорее всего plaintext]
  B -- Нет --> D{При восстановлении пароля
сообщают старый пароль?}
  D -- Да --> C
  D -- Нет --> E[Скорее всего хранят правильно 'хеш/соль']
  E --> F{Вы хотите удостовериться?}
  F -- Да --> G[Зарегистрируйтесь с заглушечным паролем
и попробуйте восстановление]
  F -- Нет --> H[Следите за безопасностью: уникальные пароли
и 2FA]

Что делать, если вы обнаружили или подозреваете plaintext

Для пользователя:

1. Немедленно смените пароль на защищённый и уникальный для этого сайта.
2. Если вы повторно использовали этот пароль на других сайтах — смените и там.
3. Включите двухфакторную аутентификацию (2FA), если сайт предлагает такую возможность.
4. Если были финансовые риски (банкинг, платежи) — оповестите банк и следите за выписками.
5. Свяжитесь с поддержкой сайта письменно, попросите разъяснений и указать сроки исправления.
6. Проверьте свой адрес на утёчки через сервисы вроде Have I Been Pwned.

Для владельцев сайта / разработчиков:

1. Перестаньте хранить пароли в открытом виде немедленно.
2. Реализуйте хранение паролей через соль + медленные хеши (рекомендуется Argon2, bcrypt или scrypt).
3. Для миграции: при первом входе пользователя сохраняйте новый хеш и соль; затем удаляйте старые записи plaintext.
4. Разработайте план миграции и отката на случай ошибок. Тестируйте на стенде, прежде чем менять продуктивную базу.
5. Внедрите мониторинг, логирование и rate-limiting для защиты от перебора.
6. Уведомьте пользователей и регуляторов, если произошла утечка.

Мини‑методология аудита хранения паролей (короткое руководство для команд)

1. Проанализируйте текущую БД: есть ли столбцы с явными паролями? Найдите поля с форматом ASCII, не напоминающим хеш.
2. Проверьте логику восстановления пароля: отправляет ли система ссылку или сам пароль?
3. Проверьте используемые алгоритмы: если хеши — какие параметры стоят у bcrypt/Argon2? Подходят ли они под современный уровень угроз?
4. Оцените хранение секретов: где лежит pepper? Есть ли отдельный HSM или KMS?
5. Спроектируйте план миграции: тесты, бэкапы, откат, уведомление пользователей.
6. Проведите внешнее тестирование безопасности и аудит третьей стороной.

Роль‑ориентированные чек‑листы

Чек‑лист для пользователя:

• Использовать уникальные пароли для каждого сайта.
• Включить 2FA где возможно.
• Хранить пароли в менеджере паролей.
• При подозрении сменить пароль и уведомить сайт.

Чек‑лист для разработчика:

• Хранить соль отдельно для каждого пароля.
• Использовать bcrypt/Argon2 с адекватными параметрами.
• Не отправлять пароли по электронной почте.
• Логировать и ограничивать попытки входа.

Чек‑лист для администратора:

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

Ограничения и случаи, когда методы не сработают

• Даже сильные хеши не помогут, если секреты и ключи управления находятся в той же среде, что и база данных (например, в том же бэкап‑хранилище) и доступны злоумышленнику.
• Если злоумышленник захватил доступ к системе аутентификации на уровне сервера (рекеконфигурировал логику входа), хеши не спасут.
• Социальная инженерия и фишинг обходят любые технические меры — техническая защита должна дополняться обучением пользователей.

О менеджерах паролей и plaintext

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

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

Короткая «план‑действий», если вы обнаружили, что сайт хранит пароли в открытом виде

1. Сменить пароль на сайте и на всех сервисах, где он повторялся.
2. Включить 2FA.
3. Связаться с поддержкой и потребовать действий и сроков исправления.
4. Поменять пароли в менеджере паролей и проверить, не скомпрометированы ли другие аккаунты.
5. При серьёзных рисках — уведомить банк или поставщиков платежей.

Краткая глоссарий терминов

• Хеш: одностороннее преобразование строки в набор символов.
• Соль (salt): уникальные случайные данные, добавляемые к паролю перед хешированием.
• Медленный хеш: алгоритм, затрудняющий массовый перебор (bcrypt, scrypt, Argon2).
• Pepper: глобальный секрет, хранящийся отдельно от базы данных.

Часто задаваемые вопросы

Что делать, если поддержка сайта ответила, что «мы используем шифрование»?

Попросите уточнить: шифруются ли сами пароли (и где хранятся ключи), или используется хеширование с солью и медленным алгоритмом. Термин “шифрование” сам по себе не гарантирует правильную архитектуру: симметричное шифрование, где ключ хранится рядом с данными, уязвимо.

Могу ли я заставить сайт удалить мои данные?

В разных юрисдикциях действуют разные правила. В ЕС и странах с подобными законами вы можете запросить удаление данных в рамках GDPR-права на удаление; в других странах стоит уточнять местные правила и политику сервиса.

Как быстро менять пароли после утечки?

Сначала смените пароли на критичных сервисах: банковских, почтовых, соцсетях. Затем меняйте на остальных. Менеджер паролей поможет автоматизировать процесс.

Итог и ключевые выводы

• Если сайт присылает ваш пароль по email или возвращает назначенный ранее пароль при восстановлении — это очевидный и серьёзный дефект безопасности.
• Надёжное хранение паролей — соль + медленные хеш‑функции (Argon2, bcrypt, scrypt), плюс дополнительные меры: pepper, rate‑limiting, 2FA.
• Как пользователь, используйте уникальные пароли, менеджер паролей и двухфакторную аутентификацию. Сообщайте владельцам сайтов о проблемах безопасности.

Ключевые действия: смените пароли, отключите повторное использование, включите 2FA и требуйте от сервисов современных стандартов хранения паролей.