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

https://palant.de/2018/03/13/can-chrome-sync-or-firefox-sync-be-trusted-with-sensitive-data
  • Перевод
Недавно я писал о недостаточной защите локально сохранённых паролей в Firefox. Как правильно отметили некоторые читатели, злоумышленник с физическим доступом к вашему устройству — не главная угроза. Поэтому взглянем, как разработчики браузеров защищают ваши пароли при их передаче в облако. И Chrome, и Firefox предоставляют сервис синхронизации, который может загружать не только сохранённые пароли, но и куки, и историю просмотров страниц. Насколько безопасен этот сервис?

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

Синхронизация Chrome


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

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

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

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

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

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

Синхронизация Firefox


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

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

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

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

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

Ну. И что?
Реклама
Комментарии 32
    0
    У LastPass по-умолчанию 5000 (хоть и pbkdf2 с sha2).
      +9

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

        0
        Да без разницы — как вообще можно доверять свои пароли стороннему сервису?

        Поэтому в FF есть возможность использования своего сервера. Хотя пароли всё равно лучше хранить в KeePass, но для кук и истории вполне подходит встроенная синхронизация.
          +1

          Сервер для хранения — не самый критичный момент, особенно если то, что на нём хранится, было зашифровано на клиенте ключом, известным только самому клиенту. Как в случае с хранением базы KeePass в Dropbox или зашифрованных бэкапов в любом публичном облаке.


          Совсем другое дело, когда клиентом является, по сути, сторонний веб-сервис вроде LastPass. Сегодня он присылает в браузер надёжный код, который всё шифрует в браузере и передаёт на сервера LastPass только зашифрованные данные без ключа дешифрования… а что он пришлёт завтра?


          И никакой опенсорс здесь уже не спасёт, потому что никто не знает, что на самом деле запущено на серверах LastPass. Чтобы такой сервис стал безопасен необходимо скачивать его в исходниках и запускать на своём сервере — а это гораздо больше мороки, чем использовать локальное приложение вроде KeePass.

          0
          bitwarden. Тот же lastpass, но opensource и еще с возможностью развернуть у себя на сервере
            +1
            полностью работающее на вашем компе

            Полностью работающее не на вашем компе, а на отдельной железке без зондов, Management Engine, проприетарных операционных систем и возможности динамической загрузки/исполнения кода.

              0

              Да! А такая есть? :)

                0

                Сделайте :)
                STM32F103 имеет и USB (для эмуляции клавиатуры), и набортную флеш, и пока вы сами не сделаете — не сможете динамически загружать софт в железку.


                Да, для действительно секурного хранения данных используется отдельный класс микроконтроллеров (с элементом безопасности на кристалле), но


                1. Их простым смертным особо не продают (гуглить NXP Secure MCU)
                2. Ваш логин от вконтактика/хабры столько не стоит
                  +1

                  USB-девайсы для паролей не новость, хоть самодельные, хоть покупные. Но пока этот девайс подключен к компу с той самой OS (и даже не обязательно проприетарной) общего назначения с тьмой софта, работающей на железе с ME — отличия от KeePass совершенно непринципиальные. Чтобы пароль ввести в формочке в браузере его надо как-то в этот браузер передать, и если OS скомпрометирована или ME любопытствует — они что из KeePass что из USB его получат в момент передачи.


                  Вариант когда USB девайс пароли не передаёт вообще, а работает по схеме уникальный запрос/ответ будет понадёжнее, но на 99.999% сайтов/сервисов такой способ логиниться всё-равно не поддерживается, так что смысла на это заморачиваться пока что нет.


                  На данный момент комбинация KeePass на компе плюс 2FA через OTP приложение на телефоне — самый надёжный, и даже поддерживается многими сайтами.

                    0

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


                    А про ОСь и ME все правильно сказано, да.


                    работает по схеме уникальный запрос/ответ будет понадёжнее

                    кажется скоро его время может и прийти

                      0

                      А в чём проблема допустить атаку по времени? Необходимости держать в секрете файл с базой KeePass нет. При использовании надёжного мастер-пароля этот файл можно взламывать до конца жизни.

                      0
                      Вариант когда USB девайс пароли не передаёт вообще, а работает по схеме уникальный запрос/ответ

                      Возрадуйтесь, стандарт наконец принят: "Web Authentication"
                      https://www.w3.org/TR/2018/CR-webauthn-20180320/

                      0
                      Напоминаю, что BootROM ARM'ов закрыт и не может быть отключён. Кто вам сказал, что там нет супервизора?
                        0

                        Супервизора в Cortex M3 (в отличие от А15 и круче, как и М23/М33, которые еще не вышли) не предусмотрено архитектурой (да там даже Memory Protection Unit нет), но фактически гарантий никаких.


                        Проблема в том, что при наличии физического доступа — можно запустить bootloader, закинуть сверхмаленькую прошивку, которая сольет все содержимое по открытому каналу.

                  0
                    0

                    Спасибо, читал ещё когда она вышла. Как по мне — не очень актуально, если система скомпрометирована и там работает кейлоггер, то оппаньки. Пытаться защищаться можно, но по факту проще предотвратить изначальный взлом системы, чем бороться с последствиями. У меня KeePassXC и линух. Он использует вроде какие-то доп.меры предосторожности вроде защиты секретных значений в памяти, etc. Но я больше полагаюсь на hardened ядро ОС, регулярные обновления, файрвол и тщательный выбор всех сервисов/приложений, которые доступны по сети (браузер прикрывает, в основном, uMatrix).

                +6
                Имхо, предложение, одновременно содержащее слова «доверять» и «Chrome» не требует вопросительного знака в конце.
                  +1
                  Таким образом, Mozilla знает о проблеме, как минимум, 18 месяцев, а 8 месяцев назад даже опубликовала эту информацию. В чём же дело? Судя по всему, проблему не посчитали слишком важной.

                  Дело в том, что и синхронизация, и менеджер паролей (об уязвимости которого недавно писали многие) давно уже числятся в Roadmap на текущий, 2018 год. И наверное всё это будет реализовано. У разработчиков и без этого дел по горло, видимо поэтому и затянули решение проблемы. Хотя как качественно всё это будет реализовано — пока не известно, может статься что проблема останется или мутирует.
                    0
                    Лучшее средство хранения паролей — своя голова.
                      +5
                      Худшее. Вы много запомните паролей вида?
                      K!Ad73DhvIMfKKCRlzDu
                      VaPUCukAlaFseH7g002P
                      C2Rr7fvIvpw«Etil88kK
                      2Nn7tUNvRnA№PxFVYDMx
                        0
                        А где вы применяете такой пароль? (в большинстве случаев обынчо стоят простые пароли, если мы говорим о синхронизации браузеров то это соц сети, почта, доступ в личные кабинеты и пр).
                        Я храню в голове свои 8+ значные пароли и рабочие 15+ знаков.
                        Запоминаются сами, путем ввода каждый день либо раз в неделю.
                        IP адреса в голове держаться тоже… не знаю что со мной не так.
                        Прошлый админ на работе хранил пароли на бумажном блокнотике, в целом очень таки удобно. Но потом я блокнот выкинул.
                          +5
                          А где вы применяете такой пароль?

                          Да везде, это KeePass генерирует, я даже не задумываюсь и не знаю эти пароли.
                            0
                            А завтра вы окажетесь на необитаемом острове и где брать пароли новому админу?
                            0
                            В июне 2017 года была закончена двухлетняя работа по переработке стандарта NIST Special Publication 800-63B.
                            обновлённый стандарт рекомендует использовать длинные парольные фразы, лёгкие для запоминания, но трудные для брутфорса.
                            миллионы пользователей, которые тупо меняли пароли каждые три месяца, выбирая строчные и прописные буквы, цифры и специальные символы, интуитивно чувствовали абсурдность этого процесса — и теперь они тоже могут вздохнуть с облегчением. Новые правила предполагают использование парольных фраз, которые гораздо легче запомнить. Это могут быть строчки из стихотворения или произвольные предложения. Чтобы брутфорсить 40-символьные фразы, хакерам придётся применять новые словари с графами сочетаемости слов. Это более сложно, чем сбрутить восьмисимвольный пароль с произвольными символами.

                            geektimes.com/post/291907
                              +1
                              Я читал статью. Она не рассматривает парольные менеджеры. Брутфорсить 20 случайных знаков сложнее, чем парольные фразы. И ничто не мешает мне сделать пароль хоть в 40, хоть в 100 знаков, главное — надёжный мастер пароль. А вот там уже можно использовать парольную фразу.
                              0
                              На самом деле у вашего пароля энтропии не больше, чем у например МышК0л0лН0Пр0д0лжалК@ктусить (в англ раскладке)
                            +1
                            Интересно, как обстоят дела у Safari и синхронизации iCloud Keychain?
                              0
                              > Чтобы это значит? Тут я опять для справки приведу цифры из этой статьи: с учётом этих итераций одна графическая карта Nvidia GTX 1080 может обсчитать 3,2 миллиона хэшей PBKDF2-HMAC-SHA1 в секунду. Это 3,2 миллиона угаданных паролей в секунду.

                              Вот тут чушь какая-то написана.
                              «может обсчитать 3,2 миллиона хэшей PBKDF2-HMAC-SHA1 в секунду» означает скорость перебора, но никак не 3,2 миллиона совпавших хэшей. За эту секунду работы полного перебора ни один из этих 3.2млн хешей может не совпасть. Т.е. это никак не «3,2 миллиона угаданных паролей в секунду.», а «3,2 миллиона потенциальных вариантов паролей в секунду.». В реальности она может 3 дня или 3 месяца перебирать по 3,2 миллиона хэшей в секунду и не найти совпадения.
                                –1
                                Мой подход — двухфакторная авторизация на важные сервисы (почта, банк, гитхаб, соцсети)

                                На остальные, которые не жалко, можно и простые пароли ставить.
                                Пароли при этом можно хранить хоть где, в том числе в браузерах. Злоумышленник всё равно не получит доступ, т.к. будет заходить с необычным IP и без куков.
                                  0
                                  Таким образом, Mozilla знает о проблеме, как минимум, 18 месяцев, а 8 месяцев назад даже опубликовала эту информацию. В чём же дело?

                                  В том, что готовят новый менеджер паролей.
                                    0
                                    Перешел на LastPass

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

                                  Самое читаемое