Взлом Adobe как урок по хранению паролей и цене старых схем
Что крупный взлом 2013 года говорит о цене устаревших схем хранения секретов и о том, как компании реагируют на инциденты.
В октябре 2013 года стало известно, что Adobe подверглась взлому, затронувшему несколько десятков миллионов аккаунтов. Утекли зашифрованные пароли, подсказки к паролям, данные платёжных карт и исходный код продуктов.
Для пресс-релиза это "инцидент безопасности". Для людей, которые строят системы с хранением пользовательских данных, это учебник с конкретными ошибками и конкретными последствиями.
Что именно было сделано неправильно
Пароли хранились в зашифрованном, а не в хешированном виде. Разница принципиальная.
Хеш - это одностороннее преобразование. Из хеша нельзя получить исходный пароль напрямую. Если злоумышленник получает базу хешей, ему нужно перебирать варианты - а при правильном использовании соли и современного алгоритма это дорого по времени и ресурсам.
Шифрование - двустороннее. Если ключ известен или может быть восстановлен, все пароли расшифровываются. В случае с Adobe ключ шифрования в конечном счёте оказался доступен вместе с данными - иначе масштаб ущерба был бы иным.
Вдобавок подсказки к паролям хранились рядом с зашифрованными значениями. Это дало атакующим семантические подсказки, которые значительно упростили задачу восстановления.
Что говорит масштаб об организационном долге
Тридцать с лишним миллионов аккаунтов - это не маленький сервис. Это означает, что схема хранения паролей была заложена давно и с тех пор не менялась, несмотря на то что стандарты сдвинулись.
Именно так работает технический долг в безопасности. Схема работала, инцидентов не было видно, приоритетов для переработки не возникало. Стоимость долга была скрытой - до момента, когда она материализовалась сразу и полностью.
Это не специфика Adobe. Это паттерн, который я встречаю в компаниях разного масштаба. Системы хранения пользовательских данных закладываются на старте, когда думают о функциональности, а не о безопасности. Дальше они живут годами без ревизии.
Как реакция на инцидент усиливает или смягчает ущерб
Публичная реакция Adobe была запоздалой и неточной. Первоначально объявленные цифры оказались занижены в несколько раз. Это типичная ошибка - сообщить раньше, чем понят реальный масштаб, а потом уточнять в сторону увеличения.
Для пострадавших пользователей это означало неопределённость: нужно ли менять пароль, какими данными рискуешь, что делать с картой. Неопределённость хуже плохой новости - она не даёт принять конкретное решение.
Хорошая реакция на инцидент начинается с внутреннего понимания масштаба до любых публичных заявлений. Это требует заранее выстроенных процессов логирования и мониторинга - которые либо есть, либо их нет в момент, когда они нужны. Вопрос о том, кто принимает решение в первые 30 минут, стоит решить задолго до инцидента.
Что это означает для компании с пользовательскими данными
Этот взлом не требует быть крупной компанией, чтобы сделать выводы. Если в вашей системе хранятся пароли или другие секреты пользователей, несколько вопросов стоит задать прямо сейчас:
- Как хранятся пароли - хеш с солью или что-то другое? Какой алгоритм и когда он выбирался?
- Если пароли написаны давно - пересматривалась ли схема в последние два-три года?
- Где хранятся ключи шифрования и кто имеет к ним доступ?
- Есть ли план реагирования на инцидент - не как документ, а как понятный процесс с ответственными?
- Как быстро можно понять реальный масштаб компрометации, если она произошла?
Вопросы не технические - они организационные. Ответы на них не требуют быть экспертом по безопасности. Они требуют задать их команде и получить честный ответ.
Взломы такого масштаба - редкость. Но схемы хранения, которые делают их последствия катастрофическими, встречаются повсеместно.