Новая старая уязвимость: менеджер паролей Firefox уже 9 лет использует устаревший SHA-1

    Создатель AdBlock Plus Владимир Палант (Wladimir Palant) обнаружил уязвимость в браузере Firefox и почтовом клиенте Thunderbird, позволяющую подобрать их мастер-пароль путем перебора. Источник проблемы — используемый механизм хеширования SHA-1.

    Подробнее об уязвимости ниже.


    / фото Z Jason CC

    Суть проблемы


    В своем блоге Палант описывает работу функции sftkdb_passwordToKey() function, которая преобразует пароль пользователя в ключ шифрования с помощью хеширования строки, содержащей соль и сам мастер-пароль. В качестве алгоритма хеширования используется SHA-1.

    Проблема заключается в том, что в Firefox и Thunderbird функция применяется лишь один раз, хотя общепринятая практика в индустрии предполагает минимум 10 тыс. итераций. В LastPass, например, используется 100 тыс.

    Современные GPU чрезвычайно хорошо вычисляют хеши SHA-1. Например, одна видеокарта Nvidia GTX 1080 вычисляет 8,5 млрд SHA-1 хешей в секунду. По данным исследования Microsoft, сложность пароля рядового пользователя составляет порядка 40 бит. Получается, что для его подбора нужно около 239 попыток — это означает, что подбор пароля средней сложности займет около минуты.

    Не первый баг-репорт


    Об этой уязвимости Mozilla сообщил Джастин Дольске (Justin Dolske) еще девять лет назад, оформив соответствующий баг-репорт. Джастин обратил внимание разработчиков, что столь малое число итераций хеш-функции создает угрозу безопасности пользователей браузера. Однако по какой-то причине проблема так и осталась не решенной.

    Ирония в том, что SHA-1 по-прежнему был частью браузера даже после того, как в октябре 2016 года Mozilla прекратила поддержку сайтов с сертификатами, использующими этот алгоритм хеширования.

    Основной причиной являлась возможность коллизии — явления, при котором два различных блока информации после хеширования имеют идентичный вид. Это позволяло подменять настоящие сертификаты сфабрикованными. О возможности «коллизионной атаки» эксперты заявляли еще в 2012 году, предсказывая, что уже к 2021 году ресурсов на ее осуществление хватит рядовым вычислительным системам, используемым в исследовательских институтах.

    А в начале 2017 года Google анонсировали первую успешную коллизионную атаку. В результате эксперимента, команда Google смогла получить два одинаковых хеша для двух разных PDF-документов. Для осуществления атаки инженеры сперва создали PDF-префикс, а затем задействовали масштабные технические ресурсы Google для вычисления коллизии. Всего компания произвела 9 квинтильонов вычислений SHA-1.

    В связи с успешным воспроизведением коллизионной атаки в Google рекомендовали специалистам по информационной безопасности как можно скорее начать использовать более защищенные алгоритмы хеширования SHA-256 и SHA-3.


    / фото Z Jason CC

    Потенциальное решение проблемы


    Ответ на форуме Mozilla поступил только после того, как Владимир Палант «воскресил» баг-репорт Джастина Дольске 9-летней давности. В ответе разработчики отметили, что уязвимость будет исправлена с выходом Lockbox — нового компонента для менеджера паролей. Пока утилита доступна как отдельное расширение, зависящее от менеджера паролей Firefox Accounts.

    Однако сам Палант для решения проблемы предложил разработчикам начать использовать алгоритм хеширования Argon2, который использует многократный проход по памяти. Argon2 был объявлен победителем конкурса Password Hashing Competition в 2015 году, участники которого разрабатывали новую функцию хеширования паролей.

    Сперва Argon2 хеширует пароль с использованием хеш-функции Blake2b. Результат хеширования записывается в блоки памяти, которые преобразуются с использованием функции сжатия G (она принимает на вход два 8192-битных блока, а выдает 1024-битный блок), и в результате генерируется ключ.

    Функция оптимизирована под архитектуру x86 и утилизирует особенности организации кэша и памяти в процессорах Intel и AMD. При этом Argon2 позволяет настраивать количество итераций, размер результата, секретный ключ и др.



    P.S. Материалы по теме ИБ из Первого блога о корпоративном IaaS:

    ИТ-ГРАД

    409,65

    vmware iaas provider

    Поделиться публикацией
    Комментарии 32
      +3
      Давно отказался от встроенного менеджера в пользу KeePass и ни разу не пожалел. Оказывается не зря.
      Для защиты других данных поставил мастер пароль, который вводит тот же KeePass, только намного более длинный, чем используют обычные люди, думаю, подобрать его будет сложно даже с однопроходным SHA1.
        0
        Подбор через коллизии может найти и более короткий вариант вашего пароля :)
          0
          Вот часто упоминают про коллизии, но найти примеров для коротких паролей (длиной не более 32 символов) я так и не смог. Был бы рад увидеть примеры.
        0
        Какой алгоритм не применяй, а qwerty и перебор по словарю был, есть и будет.
          –1
          Ну а с какой скоростью можно перебирать указанные альтернативы?
          Это техническая статья или что?
          Или аудитория хавает?
            0
            Современные GPU чрезвычайно хорошо вычисляют хеши SHA-1. Например, одна видеокарта Nvidia GTX 1080 вычисляет 8,5 млрд SHA-1 хешей в секунду. По данным исследования Microsoft, сложность пароля рядового пользователя составляет порядка 40 бит. Получается, что для его подбора нужно около 2^39 попыток — это означает, что подбор пароля средней сложности займет около минуты.

            Значит, 10-значный пароль (60бит) на одной видеокарте нужно перебирать в среднем 2 года, а в худшем случае 4 года?
            2^59 / 2^33 ≈ 67млн. с ≈ 770 дней.
            Можно запомнить рандомный пароль в ~12 символов и пока спать спокойно.


            Самое забавное, что те 100тыс. итераций в lastpass перебираются на условных 1000 видеокартах за 2 часа, ну или на сотне видеокарт за сутки.

              0
              Можно запомнить рандомный пароль в ~12 символов и пока спать спокойно.

              Вы несёте бред. 12 символьный полностью рандомный пароль по алфавиту из 95 символов (все знаки пунктуации, цифры, заглавные и строчные буквы) переберётся на 1 млрд видеокарт всего лишь за 15 часов.

              А если Вы используете алфавит только 62 символа, то хватит 5 минут.
              Если алфавит 36 символов (a-z и цифры), то хватит пол секунды.

              Надо использовать как минимум 15-символьный полностью рандомный пароль по алфавиту 95 символов — его перебор займёт 1470 лет, т. е. это пароль низкой сложности — самая минимальная длина, которую можно использовать.

              Но если бы Mozilla улучшила менеджер, то эта длина могла бы сократиться на 2.5 символа, что ОЧЕНЬ много.
                +2
                переберётся на 1 млрд видеокарт всего лишь за 15 часов.

                Сожрав при этом 3ТВт*ч энергии? Не все пароли настолько ценны, чтобы так платить.

                  0
                  Это сегодня 3ТВт*ч. Но теоретически каждые 2 года мощности видеокарт может расти примерно в 2 раза. Получается уже через 10 лет требуемое время и электроэнергия снизятся в 32 раза.

                  Через 20 лет снизится в 1024 раза — потребовалось бы всего лишь 1 млн видеокарт. 1 млн видеокарт на 15 часов — вполне реально.

                  Электроэнергия при этом тоже может серьёзно подешеветь. Например, стоимость перебора такого пароля может составить 2 млн рублей.

                  Далее, если бизнес может предложить видеокарты по какой-то стоимости, нельзя исключать, что на самом деле кто-то располагает более высокими технологиями. Ему конечно было бы выгодно продать их, но всё-равно.

                  В общем, 1 млрд видеокарт берётся для того, чтобы покрыть всякие такие риски, ведь неизвестно, как будут развиваться технологии в будущем. Даже сейчас в статье написано, что nvidia считает 10 млрд хэшей в секунду. Но где гарантии, что кто-то не считает больше? А может даже существуют специализированные устройства, оптимизированные под подсчёт хэшей.
                    +1
                    Да, забыл ещё упомянуть ботнеты — когда подсчёт ведётся на взломанных устройствах обычных пользователей, тогда электричество бесплатно.
                      0

                      Вы теоретизируете или знаете реальную возможность обеспечить необходимую производительность?

                        0
                        При подсчёте безопасности не так сильно нужно знать реальную производительность, теории будут безопаснее. Например, вполне можно представить ботнет из 10 млн видеокарт. Это не значит, что он существует, но ведь такое теоретически возможно? Да. Мы всегда должны рассматривать худший случай.

                        Конечно это не отменяет того факта, что реальность будет лучше теории. Это хорошо, значит у нас есть какой-то запас. Можно спать спокойно.
                      0

                      Тогда я снова добавлю пару символов в пароль.


                      Я понимаю, что устаревший sha1 не есть хорошо, и лучше бы его чем-то заменить, но риторика типа "нужно хэшировать 100тыс.раз, как делают нормальные люди" или это ваше "вы несёте бред, миллиарды видеокарт" — сама по себе ересь.

                        0
                        1 млрд видеокарт, как по мне, стандартная цифра для рассчёта, покрывающая риски. Даже сейчас существования ботнета из 10 млн видеокарт не кажется фантастикой. А что уж говорить про будущее.

                        Но если Вы так хотите, сократите до 1 млн видеокарт и получится всё-равно 625 дней. Но здесь уже заметно вырастают риски. Видите, удобнее брать 1 млрд — и запас на будущее есть, и запас на то, что кому-то пароль будет сильно нужен. Это не какая-то завышенная цифра.

                        Тогда я снова добавлю пару символов в пароль.
                        Но кто получил старые данные, всё-равно сможет их расшифровать. Хотя если брать браузерный менеджер паролей, то здесь можно просто поменять пароли на всех сайтах.
                          0

                          Я понимаю, что 12-значные пароли рано или поздно можно будет разгадать, равно как и 16-значные (но чуть позже). В этом свете мне кажется более простым добавить N символов в пароль, чем городить алгоритмы с итерациями.
                          Добавление символов экспоненциально увеличивает сложность подбора, добавление итераций — линейно.
                          Ну и, я считаю 2 года вычислений слишком большим сроком, чтобы затратить их на мои пароли. Когда-нибудь это будет уже совсем не 2 года, но я считаю, что это будет достаточно не скоро. И тогда можно будет просто поменять пароль на более длинный.


                          P.S.: эта логика не относится к хранению паролей неразумных пользователей, которым может быть удобно использовать 6 цифр как пароль.

                            0
                            Я согласен, что в будущем надо подумать заново (когда это возможно), но безопасность ближайшего будущего всё-равно нужно обеспечить.

                            добавление итераций — линейно
                            Это невероное утверждение. Сегодня мы сделали 10 итераций, через 4 года 100 итераций, ещё через 4 — 1000 итераций, потом 10 тыс — на лицо экспоненциальная зависимость.

                            С таким же успехом, как Вы постепенно добавляете 2-3 символа, можно постепенно умножать количество итераций на 10-800 тыс. При этом длину пароля увеличивать уже не придётся.

                            Ну и само итерирование — это мощная вещь. Сравните: перебрать пароль за 1 час или за 114 лет. Потратить 10 рублей на электричество или 10 млн рублей.
                              0
                              > добавление итераций — линейно
                              Это невероное утверждение. Сегодня мы сделали 10 итераций, через 4 года 100 итераций, ещё через 4 — 1000 итераций, потом 10 тыс — на лицо экспоненциальная зависимость.

                              Верное.
                              Пароль длиной N символов по 6 бит — 64^N проверок для полного перебора. Добавляем P символов: 64^(N+P) — получаем увеличение сложности в 64^P раз.
                              K итераций для М символов — увеличивают сложность в K раз: K(64^М). Добавляем P итераций: (K+P)(64^М) — получаем увеличение сложности в (K+P)/K раз.

                                0
                                Мы добавляем не K итераций, а, к примеру, 2ᵏ, где k изменяется во времени примерно линейно.
                                  0

                                  Тогда следует сравнивать с добавлением 2^k символов.


                                  Но попробуйте сами рассчитать, как при этом меняется соотношение "наших" затрат и затрат "взломщика". И как меняется при добавлении символов.

                                    0
                                    Но Вы же не станете каждые 3 года добавлять 2ᵏ символов? Это получилось бы Вам надо было вначале добавить 2 символа, потом 4 символа, потом 8 символов и т. д. Боюсь представить длину Вашего пароля через 20 лет.
                                      0

                                      Нет конечно! Мне достаточно добавить k символов, тогда как вам — 2^k итераций. Это и есть экспоненциальная разница.
                                      Такая же разница будет в соотношении объёмов "моих" расчётов и объёмов "взломщика".

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

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

                                        Но… на самом деле может и меняться, потому что пользователь может со временем тратить меньше денег на видеокарту, а вот злоумышленник тратить меньше не станет. В этом случае придётся комбинировать оба метода.
                              0
                              2 года вполне практически допустимый срок атаки даже для условно бытовых целей типа подбора любым сотрудником пароля гендира или админа для своих мелких личных корыстных или даже хулиганских целей. Или школьником пароля от домашней сети и т. п.
                      0
                      PS. Длина составила бы 12.5 символов.
                      0
                      Ваши подсчеты в корне не верны — вы даже в расчет не берете количество символов. Я в паролях где это возможно сейчас даже ASCII символы юзаю.
                      Плюс вы не учитываете тот факт что в KeePass не один метод шифрования для всех БД. Почитайте про ChaCha20 и Argon и вы поймете что вы не правы. Вы сами хозяин своей БД и сами выбираете насколько много итераций на ней выставить.
                        0
                        Плюс вы не учитываете тот факт что в KeePass

                        В этой теме речь идёт о Firefox, автор первого сообщения ветки упомянул ещё lastpass. KeePass конечно же надёжнее первых двух, с этим явно никто не будет спорить. У меня вот сейчас чуть больше 10 млн итераций хеширования.
                          0

                          Извиняюсь, прочитал LastPass, а подумал о KeePass.

                      0
                      «Новость» воскресили ещё 19 марта, что вызвало потоки сообщений по теме «всё пропало».
                      А Asa Dotzler уже неделю назад внёс корректировку в план развития Firefox на 2018 год.
                      wiki.mozilla.org/Firefox/Roadmap
                      Lockbox integration with Firefox: Mozilla's new password manager will integrate with Firefox and Firefox accounts allowing users to take their passwords beyond the browser. (2018)
                        0
                        Общеизвестный факт, не вижу чего паниковать, и не знаю ни одного браузера или почтового клиента который надежно хранит пароли от сохраненных в нем учетных записей. Сюда летят и Chrome (и все детища Chromium: Opera и тд) и Firefox и IE и клиенты Outlook, Thunderbird и тд. Банально берем Google и пишем кодовое слово: nirsoft. Запуском 2вух утилит получаем все пароли из вышеперечисленного софта:
                        WebBrowserPassView
                        Mail PassView

                        Ну в этой ситуации мы… просто наше это самое… мы уже… здесь наши полномочия все… окончены. Так что если вы такой же параноик как я: юзайте уникальные пароли на каждый сайт\сервис, используйте двухфакторку где это нужно если это возможно.
                        P.S. Сам пользуюсь KeePass хоть и знаю что и с него можно своровать пароли но куда сложнее: только если он находится в разблокированном состоянии через инъекцию библиотеки в процесс и вызова функции экспорта паролей в csv например — исходники на github проект KeeFarce. Но так как это инъекция, а не банальное считывание файла с %USERNAME%\AppData (так считываются пароли с бд браузеров) то такое поведение может хотя бы антивирус словить по эвристике и по сигнатурам если он есть.
                          0
                          Не все Хромиумы одинаковы habrahabr.ru/company/yandex/blog/344382
                            0
                            Дня обычных юзеров это возможно это удобное решение, и спорить не буду так как не пользовался. Но лично для меня: у меня глубокое недоверие к продуктам Yandex и Mail.ru. Раньше они себя очень плохо зарекомендовали, вот пример: ссылка. В changelog WebBrowserPassView:
                            Version 1.70: WebBrowserPassView now automatically detect the passwords of Yandex Web browser. Скорее всего это относится к той версии что еще с менеджером паролей от Chromium. А тестировать я не буду потому как все равно менеджер паролей в браузере мне не подходит по ряду причин:
                            1. он менее надежный: KeePass имеет историю паролей, и если что я могу вернуть случайно измененный пароль назад за два клика мышки. Так же KeePass хранится в Dropbox в котором есть версионирование, а плагин KeeAnywhere для работы с Dropbox сохраняет базу в Dropbox и еще хранит настраиваемое количество копий локально в нужном мне месте — а это дает мне гарантию того что если я потеряю доступ к Dropbox я не потеряю саму базу — ее 10 копий у меня на ПК, и если я забуду новый мастер пароль через даже десять дней или месяц, но буду помнить предыдущий я могу востановить более старую версию базы с резервной копии на ПК или Dropbox;
                            2. менее безопасный: я прочитал статью от Yandex и все равно AES-256-GSM это вам не ChaCha20. Да и если как то взломают учетку Yandex ваши пароли от туда могут просто удалить из-за злости того что не смогли с ними ничего сделать, хотя 2FA может тут спасти. С Dropbox есть 2FA да и если случится чудо и кто то как то его уведет будет еще локальная версия. Плюс с KeePass я уверен в том что пока база открыта пароли не могут быть прочитаны кем попало с оперативной памяти даже программой с правами администратора — украсть их можно только через DLL инъекцию и нативную функцию экспорта паролей, если база захлопнута с ней вообще ничего не сделать, и эти настройки я делаю сам. А как работает браузер Yandex не понятно, как долго он хранит базу паролей открытой и как работает защита от перехвата в оперативной памяти и тд.
                            3. и что самое главное он не универсальный: в отличии от менеджера паролей в браузере KeePass может хранить любые пароли: в поле URL может быть совсем пусто и это будет пароль не от веб-приложения, или быть указана ссылка на rdp:// или ssh:// etc.., а в настройках ассоциации указана программа для запуска с параметрами передачи логина\пароля и других кастомных полей, плюс можно хранить дополнительные атрибуты в паролях: файлы (например приватные сертификаты PGP\ OpenSSH ключи и тд, или конфигурации для тех же OpeVPN), или другие кастомные поля защищенные в памяти (для одноразовых паролей 2FA или для ключи API для доступа к каким либо сервисам).
                              0
                              Это про старую, конечно же. С тех пор у нас и платный BugBounty заработал, и участие в CVE, и свой менеджер паролей.

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

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