Хабрахабр

[Перевод] Можно ли доверять свои пароли синхронизации Chrome и Firefox?

Недавно я писал о недостаточной защите локально сохранённых паролей в Firefox. Как правильно отметили некоторые читатели, злоумышленник с физическим доступом к вашему устройству — не главная угроза. Поэтому взглянем, как разработчики браузеров защищают ваши пароли при их передаче в облако. И Chrome, и Firefox предоставляют сервис синхронизации, который может загружать не только сохранённые пароли, но и куки, и историю просмотров страниц. Насколько безопасен этот сервис?

У обеих служб есть слабые места в защите. TL;DR: в настоящее время ответ «нет». Впрочем, некоторые из этих недостатков хуже других.

Начну с синхронизации Chrome, где ответ более предсказуем. В конце концов, несколько вещей указывают на то, что данная услуга создана скорее для удобства, чем для приватности. Например, пароль для защиты ваших данных от Google необязателен. В настройках нет предупреждения типа «Эй, вас не волнует, что мы можем заглянуть в ваши данные? Лучше установите пароль». Вместо этого пользователь должен сам проявить инициативу. Другой признак — то, что Google открывает доступ к паролям через веб-страницу. Вероятно, идея в том, чтобы вы могли открыть эту веб-страницу с чужого компьютера, например, из интернет-кафе. Хорошая идея? Вряд ли.

Он будет использоваться для получения (среди прочего) ключа шифрования — и ваши данные зашифруются этим ключом. В любом случае, что произойдет после установки пароля? Оказывается, Chrome использует PBKDF2-HMAC-SHA1 с 1003 итерациями. Конечно, здесь возникает большой вопрос: если кто-то получит ваши зашифрованные данные с сервера, насколько пароль защищён от брутфорса?

Тут я опять для справки приведу цифры из этой статьи: с учётом этих итераций одна графическая карта Nvidia GTX 1080 может обсчитать 3,2 миллиона хэшей PBKDF2-HMAC-SHA1 в секунду. Чтобы это значит? То есть 1,5 миллиарда паролей, известных из различных утечек веб-сайтов, обсчитываются менее чем за 8 минут. Это 3,2 миллиона угаданных паролей в секунду. Вероятно, специалисты переоценивает возможности людей по выбору хороших паролей, но примерно за два дня этот пароль будет подобран. Что насчёт надёжного пароля с энтропией 40 бит, который эти специалисты считают средним паролем у людей?

Соль, которую Chrome использует для получения ключа, представляет собой константу. На самом деле ситуация ещё хуже. В свою очередь, это значит, что при наличии большого объёма данных от разных пользователей можно проводить атаку сразу на всех. Это означает, что один и тот же пароль у разных пользователей Chrome соответствует одинаковым ключам шифрования. Имейте в виду, что у самой Google достаточно оборудования, чтобы проделать эту работу за несколько минут, если не секунд. Таким образом, за четыре дня будет подобран пароль к любой учётной записи, где используется пароль с энтропией до 40 бит. Я говорю о тех злоумышленниках, кто не хочет тратить на оборудование более 1000 долларов.

Я зарегистрировал этот баг в трекере с номером 820976, следите за обновлениями.

Эта функция прогоняет PBKDF2 четыре раза, хотя одного прохода достаточно. Примечание. Особая благодарность Chrome за креативность в бесполезной трате ресурсов CPU. Это довольно бессмысленно: соль не должна быть секретом, она просто должна быть уникальной. Первый запуск получает соль от имени хоста и имени пользователя (в случае синхронизации Chrome это константы). Следующие три запуска генерируют три разных ключа из идентичных входных данных, используя разное число итераций. Так что объединение значений или прогон на них SHA-256 дают тот же эффект. Один вызов PBKDF2 с генерацией данных для всех трёх ключей явно был бы эффективнее.

Синхронизация Firefox использует хорошо документированный протокол Firefox Accounts для установки ключей шифрования. Хотя различные параметры и выполняемые там операции могут запутать, но похоже, что это хорошо продуманный подход. Если кто-то получит доступ к данным, хранящимся на сервере, то им придётся иметь дело с ключами на основе scrypt. Перебор scrypt на специализированном оборудовании гораздо сложнее, чем PBKDF2 хотя бы потому, что каждый вызов scrypt требует 64 МБ памяти — если учитывать параметры, которые использует Mozilla.

На стороне клиента этот протокол использует PBKDF2-HMAC-SHA256 только с 1000 итерациями. Тем не менее, есть существенный недостаток: scrypt работает на сервере Firefox Accounts, а не на стороне клиента. В данном случае одна видеокарта Nvidia GTX 1080 будет проверять 1,2 миллиона хэшей в секунду. И хотя полученный парольный хэш не хранится на сервере, но если кто-то перехватит его во время передачи на сервер, то сможет относительно легко подобрать пароль. И пароль с 40-битной энтропией угадают в среднем за пять дней. Хотя для каждого аккаунта придётся начинать операцию заново, но проверка 1,5 миллиарда известных паролей займёт 20 минут. В зависимости от содержимого учётной записи такая трата ресурсов может окупиться.

Таким образом, Mozilla знает о проблеме, как минимум, 18 месяцев, а 8 месяцев назад даже опубликовала эту информацию. Самое интересное: Mozilla оплатила аудит безопасности Firefox Accounts, и этот аудит указал генерацию ключа на стороне клиента как ключевой недостаток. Судя по всему, проблему не посчитали слишком важной. В чём же дело? Возможно, это отчасти связано с тем, что аудитор неправильно оценил риск:

Атака предполагает очень сильного злоумышленника, который способен обойти TLS.

Конечно, одним из возможных способов проведения атаки стало бы получение валидного сертификата для api.accounts.firefox.com и перенаправление трафика на собственный сервер. Но более вероятно, что будет скомпрометирована безопасность самого сервера api.accounts.firefox.com. Даже если сервер не взломан, всегда есть шанс, что сотрудник Mozilla или Amazon (сервер размещается на AWS) решит взглянуть на чьи-то данные. А что если американские власти постучатся к Mozilla?

Сейчас он помечен как дубликат бага 1320222 — я не смог его найти, потому что он был помечен как «важный в отношении безопасности» (security sensitive), хотя не содержит никакой новой информации. Я изначально зарепортил этот баг как 1444866.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть