Инциденты и уязвимости
Утечка данных Takufile-bin (2019) — почему хранение паролей в открытом виде фатально и защита через хеширование
В январе 2019 японский сервис передачи файлов Takufile-bin (Ogis-Research Institute) взломали, утекло ~4,8 млн записей. Решающая ошибка: пароли хранились в открытом виде. Защита — односторонний хеш с солью (bcrypt/Argon2id), минимум данных и 2FA.
Реальные публичные инциденты мы читаем не как повтор новостей, а как «как от этого защититься?» Эта статья основана на публичном материале (заявления компании, авторитетные репортажи). Источники перечислены в конце, и никаких инструкций по атаке нет.
- Цель
- Пользователи сервиса передачи файлов «Takufile-bin» (оператор: Ogis-Research Institute)
- Обнаружено
- 22–25 января 2019 (замечен подозрительный файл → сервис остановлен → раскрыто)
- Схема
- Несанкционированный доступ через уязвимость сервера → кража данных клиентов (пароли входа хранились в открытом виде)
- Масштаб
- ~4,8 млн записей (имена, почта, пароли входа, даты рождения, пол; включая ушедших клиентов)
- Первопричина
- Пароли хранились в открытом виде (обратимая форма) + уязвимость сервера + хранение лишних данных, включая ушедших пользователей
- Настоящее исправление
- Односторонний хеш + соль (bcrypt/Argon2id); не держать лишних данных / минимизировать хранение; управление уязвимостями; готовность к повторному использованию (2FA)
Что произошло (простыми словами)
Сервису доверяют пароли пользователей. Вопрос в том, как он их хранит. Храните пароль в открытом виде (читаемым как есть) или только с обратимым шифрованием — и в момент утечки его содержимое сразу пригодно к использованию.
В Takufile-bin через уязвимость сервера получили несанкционированный доступ, и данные клиентов утекли. Затем в дополнительном сообщении раскрыли, что утёкшие пароли входа не были зашифрованы — они были в открытом виде. Поскольку многие повторно используют один и тот же пароль на разных сервисах, утечка в открытом виде позволяет атакующему попробовать его в другом месте ради захвата аккаунта. Больше самого проникновения ущерб расширило именно хранение в открытом виде.
«Шифрование» и «хеширование» — не одно и то же
Частое заблуждение при хранении паролей — что шифрование делает их безопасными. Шифрование обратимо ключом, поэтому если утечёт и ключ, толку не больше, чем от открытого текста. Правильный подход — необратимый односторонний хеш плюс соль на каждого пользователя, с намеренно медленным алгоритмом (bcrypt / Argon2id). При входе вы хешируете введённое тем же способом и сравниваете — так что хранить открытый текст вовсе не нужно.
Цепочка атаки — это ещё и карта защиты
Это была цепочка, где на каждом шаге было место, чтобы её оборвать. Читайте её как где её можно было прервать, а не как инструкцию.
1. Несанкционированный доступ через уязвимость сервера
Оставленная без внимания известная слабость становится входом.
Стоп: управление уязвимостями; дисциплина патчей; минимизация поверхности атаки
2. Забраны данные клиентов и пароли входа
Хранился большой массив данных, включая ушедших клиентов.
Стоп: не держать лишних данных; минимизировать хранение
3. Пароли в открытом виде = сразу пригодны к использованию
Не зашифрованы, поэтому годны в момент утечки.
Стоп: односторонний хеш + соль (bcrypt/Argon2id) = не пригоден сразу при утечке
4. Вторичный ущерб через повторное использование (захват аккаунтов)
Под удар попадают другие сервисы с тем же паролем.
Стоп: перестать использовать пароли повторно; 2FA; быстрый принудительный сброс при утечке
Опубликованная хронология
2019-01-22
На сервере находят файл, который компания не опознаёт (признак несанкционированного доступа).2019-01-23
Сервис останавливают в качестве меры предосторожности.2019-01-25
Раскрывают несанкционированный доступ и утечку данных (~4,8 млн записей, включая ушедших пользователей).2019-01-30
Дополнительное сообщение раскрывает, что утёкшие пароли входа не были зашифрованы (открытый текст).2019-03
Сообщают подробные результаты от внешней фирмы по безопасности; сервис остаётся приостановленным.2020-01-14
Объявляют о прекращении (ввиду стоимости/времени безопасной перестройки); сервис закрывается в том же году.
Первопричина была не только в том, что «их взломали»
Списать это на «их хакнули» — значит упустить суть. Проникновение может случиться; важно, минимизирует ли хранение ущерб при утечке данных.
Конфигурация, которая провалилась
- Пароли входа хранились в открытом виде (пригодны в момент утечки)
- Большой массив данных, включая ушедших пользователей, продолжали держать
- Уязвимость сервера стала входом
- Трудно остановить захват аккаунтов на сайтах с повторным паролем после утечки
Конфигурация, которая держит
- Пароли хранятся как односторонний хеш + соль (bcrypt/Argon2id)
- Не держать лишних данных; минимизировать хранение (удалять после ухода)
- Управление уязвимостями / дисциплина патчей закрывает вход
- 2FA и быстрый принудительный сброс при утечке ограничивают вторичный ущерб
Счёт постфактум затмевает вложение в проектирование заранее
Takufile-bin оставался приостановленным и в итоге был полностью закрыт (ввиду стоимости и времени безопасной перестройки). Правильно захешировать пароли дёшево, тогда как цена утраченного доверия, оттока и вторичного ущерба от хранения в открытом виде куда выше. Проектируйте способ хранения паролей правильно когда строите, а не потом.
Как от этого защититься
Если вам доверен пароль хотя бы одного пользователя — это про вас. В порядке приоритета:
Храните пароли как односторонний хеш с солью
Не храните открытый текст или «обратимое шифрование». Используйте односторонний хеш с солью на каждого пользователя, через намеренно медленный алгоритм вроде bcrypt или Argon2id. Полное руководство — см. как безопасно хранить пароли.
Не держите лишних данных
Собирайте минимум полей и удаляйте данные, как только пользователь ушёл или они больше не нужны. Данные, которых у вас нет, не могут утечь. Не копите записи ушедших пользователей.
Закройте вход — управляйте уязвимостями
Патчите уязвимости сервера и библиотек и минимизируйте открытую поверхность атаки. Исходите из того, что проникновение возможно, и сокращайте число входов.
Ограничьте ущерб даже при утечке (2FA, защита от повтора)
Предлагайте двухфакторную аутентификацию и принуждайте к быстрому сбросу при утечке. Подталкивайте пользователей отказаться от повторного использования. Вместе с хешированием стремитесь к состоянию, где утечка не пригодна к использованию сразу.
Где это пересекается с тем, как устроен этот сайт
По сути этот инцидент хранил самый важный секрет — пароль — в форме, пригодной как есть при утечке (открытый текст). Это зеркальное отражение собственных принципов этого сайта — обращаться с секретами в необратимой форме, не держать лишнего и сжимать радиус поражения. «Мы зашифровали, значит безопасно» — опасное допущение; пароли принадлежат одностороннему хешу + соли. «Не держать открытый текст, не держать лишних данных, сделать утечку непригодной» — это защита, которую может внедрить каждый при любом масштабе.
Источники (публичный материал)
Изложенные здесь факты основаны на следующей публичной информации. Никаких инструкций по атаке нет — только защитные уроки.
- Официальные заявления Ogis-Research Institute («О несанкционированном доступе к сервису Takufile-bin» / извинение и отчёт, 2019–2020) — ogis-ri.co.jp
- Репортажи того времени (приостановка сервиса, подробные результаты и прекращение, 2019–2020), на основе первичных раскрытий
Читать дальше
- Практика: Как безопасно хранить пароли (хеширование и соль)
- Глоссарий: Что такое хеширование паролей / Что такое соль
- Глоссарий: Двухфакторная аутентификация (2FA) (чтобы утечка не годилась сразу) · Практика: Чек-лист базовой безопасности
FAQ
QКакая проблема была самой серьёзной в инциденте Takufile-bin?
То, что утёкшие пароли входа хранились в открытом виде. Спусковым крючком стал несанкционированный доступ через уязвимость сервера, но поскольку пароли были в открытом виде, они годились к использованию в тот же момент, как утекли. Если бы пароли хранились как односторонний хеш (с солью), утечка не раскрыла бы годные пароли, и ущерб был бы куда меньше.
QДостаточно ли «зашифровать» пароли для безопасности?
«Шифрование» и «хеширование» — разные вещи. Шифрование обратимо ключом, поэтому если утечёт и ключ, толку не больше, чем от открытого текста. Правильный подход — необратимый односторонний <strong>хеш</strong> плюс <strong>соль</strong> на каждого пользователя, с намеренно медленным алгоритмом вроде bcrypt или Argon2id. При входе вы хешируете введённое тем же способом и сравниваете — так что хранить открытый текст вовсе не нужно.
QЧто может сделать обычный пользователь?
Да: (1) никогда не используйте один пароль повторно на разных сервисах (тогда даже утечка в открытом виде не приведёт к захвату аккаунта в другом месте); (2) используйте менеджер паролей для длинных случайных значений; (3) включайте двухфакторную аутентификацию или passkey везде, где предлагают. Даже если оператор хранит пароли плохо, отказ от повторного использования разрывает цепочку вторичного ущерба.