Подробнее об уязвимости ниже.
/ фото 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:
- Особенности двухфакторной аутентификации: работает ли это в облаке IaaS
- Тестирование безопасности облачных решений, или Советы по устранению security-проблем
- Построение аттестуемых и защищенных инфраструктур на базе решений VMware
- Защита персональных данных: европейский подход
- VMware NSX: новый подход к обеспечению безопасности в области здравоохранения
- На что обратить внимание при выборе услуги облачного PCI DSS хостинга
Комментарии (29)
php7
30.03.2018 10:10-1Ну а с какой скоростью можно перебирать указанные альтернативы?
Это техническая статья или что?
Или аудитория хавает?
Akon32
30.03.2018 12:01Современные 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 часа, ну или на сотне видеокарт за сутки.
vitaliy2
30.03.2018 14:47Можно запомнить рандомный пароль в ~12 символов и пока спать спокойно.
Вы несёте бред. 12 символьный полностью рандомный пароль по алфавиту из 95 символов (все знаки пунктуации, цифры, заглавные и строчные буквы) переберётся на 1 млрд видеокарт всего лишь за 15 часов.
А если Вы используете алфавит только 62 символа, то хватит 5 минут.
Если алфавит 36 символов (a-z и цифры), то хватит пол секунды.
Надо использовать как минимум 15-символьный полностью рандомный пароль по алфавиту 95 символов — его перебор займёт 1470 лет, т.?е. это пароль низкой сложности — самая минимальная длина, которую можно использовать.
Но если бы Mozilla улучшила менеджер, то эта длина могла бы сократиться на 2.5 символа, что ОЧЕНЬ много.Akon32
30.03.2018 14:54переберётся на 1 млрд видеокарт всего лишь за 15 часов.
Сожрав при этом 3ТВт*ч энергии? Не все пароли настолько ценны, чтобы так платить.
vitaliy2
30.03.2018 15:00Это сегодня 3ТВт*ч. Но теоретически каждые 2 года мощности видеокарт может расти примерно в 2 раза. Получается уже через 10 лет требуемое время и электроэнергия снизятся в 32 раза.
Через 20 лет снизится в 1024 раза — потребовалось бы всего лишь 1 млн видеокарт. 1 млн видеокарт на 15 часов — вполне реально.
Электроэнергия при этом тоже может серьёзно подешеветь. Например, стоимость перебора такого пароля может составить 2 млн рублей.
Далее, если бизнес может предложить видеокарты по какой-то стоимости, нельзя исключать, что на самом деле кто-то располагает более высокими технологиями. Ему конечно было бы выгодно продать их, но всё-равно.
В общем, 1 млрд видеокарт берётся для того, чтобы покрыть всякие такие риски, ведь неизвестно, как будут развиваться технологии в будущем. Даже сейчас в статье написано, что nvidia считает 10 млрд хэшей в секунду. Но где гарантии, что кто-то не считает больше? А может даже существуют специализированные устройства, оптимизированные под подсчёт хэшей.vitaliy2
30.03.2018 15:07Да, забыл ещё упомянуть ботнеты — когда подсчёт ведётся на взломанных устройствах обычных пользователей, тогда электричество бесплатно.
Akon32
30.03.2018 15:12Вы теоретизируете или знаете реальную возможность обеспечить необходимую производительность?
vitaliy2
30.03.2018 15:22При подсчёте безопасности не так сильно нужно знать реальную производительность, теории будут безопаснее. Например, вполне можно представить ботнет из 10 млн видеокарт. Это не значит, что он существует, но ведь такое теоретически возможно? Да. Мы всегда должны рассматривать худший случай.
Конечно это не отменяет того факта, что реальность будет лучше теории. Это хорошо, значит у нас есть какой-то запас. Можно спать спокойно.
Akon32
30.03.2018 15:09Тогда я снова добавлю пару символов в пароль.
Я понимаю, что устаревший sha1 не есть хорошо, и лучше бы его чем-то заменить, но риторика типа "нужно хэшировать 100тыс.раз, как делают нормальные люди" или это ваше "вы несёте бред, миллиарды видеокарт" — сама по себе ересь.
vitaliy2
30.03.2018 15:161 млрд видеокарт, как по мне, стандартная цифра для рассчёта, покрывающая риски. Даже сейчас существования ботнета из 10 млн видеокарт не кажется фантастикой. А что уж говорить про будущее.
Но если Вы так хотите, сократите до 1 млн видеокарт и получится всё-равно 625 дней. Но здесь уже заметно вырастают риски. Видите, удобнее брать 1 млрд — и запас на будущее есть, и запас на то, что кому-то пароль будет сильно нужен. Это не какая-то завышенная цифра.
Тогда я снова добавлю пару символов в пароль.
Но кто получил старые данные, всё-равно сможет их расшифровать. Хотя если брать браузерный менеджер паролей, то здесь можно просто поменять пароли на всех сайтах.Akon32
30.03.2018 15:35Я понимаю, что 12-значные пароли рано или поздно можно будет разгадать, равно как и 16-значные (но чуть позже). В этом свете мне кажется более простым добавить N символов в пароль, чем городить алгоритмы с итерациями.
Добавление символов экспоненциально увеличивает сложность подбора, добавление итераций — линейно.
Ну и, я считаю 2 года вычислений слишком большим сроком, чтобы затратить их на мои пароли. Когда-нибудь это будет уже совсем не 2 года, но я считаю, что это будет достаточно не скоро. И тогда можно будет просто поменять пароль на более длинный.
P.S.: эта логика не относится к хранению паролей
неразумныхпользователей, которым может быть удобно использовать 6 цифр как пароль.vitaliy2
30.03.2018 15:41Я согласен, что в будущем надо подумать заново (когда это возможно), но безопасность ближайшего будущего всё-равно нужно обеспечить.
добавление итераций — линейно
Это невероное утверждение. Сегодня мы сделали 10 итераций, через 4 года 100 итераций, ещё через 4 — 1000 итераций, потом 10 тыс — на лицо экспоненциальная зависимость.
С таким же успехом, как Вы постепенно добавляете 2-3 символа, можно постепенно умножать количество итераций на 10-800 тыс. При этом длину пароля увеличивать уже не придётся.
Ну и само итерирование — это мощная вещь. Сравните: перебрать пароль за 1 час или за 114 лет. Потратить 10 рублей на электричество или 10 млн рублей.Akon32
30.03.2018 16:00> добавление итераций — линейно
Это невероное утверждение. Сегодня мы сделали 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 раз.vitaliy2
30.03.2018 16:03Мы добавляем не K итераций, а, к примеру, 2?, где k изменяется во времени примерно линейно.
Akon32
30.03.2018 16:23Тогда следует сравнивать с добавлением 2^k символов.
Но попробуйте сами рассчитать, как при этом меняется соотношение "наших" затрат и затрат "взломщика". И как меняется при добавлении символов.
vitaliy2
30.03.2018 16:25Но Вы же не станете каждые 3 года добавлять 2? символов? Это получилось бы Вам надо было вначале добавить 2 символа, потом 4 символа, потом 8 символов и т.?д. Боюсь представить длину Вашего пароля через 20 лет.
Akon32
30.03.2018 16:33Нет конечно! Мне достаточно добавить k символов, тогда как вам — 2^k итераций. Это и есть экспоненциальная разница.
Такая же разница будет в соотношении объёмов "моих" расчётов и объёмов "взломщика".vitaliy2
30.03.2018 16:43Добавление символов экспоненциально увеличивает сложность подбора, добавление итераций — линейно.
Ладно, добавление итераций линейно увеличивает сложность, Вы правы. Но я имел ввиду то, что мы можем без проблем добавлять итерации экспоненциально, а вот Вы можете только линейно.
В общем выразился я до этого абсолютно неверно, но сами по себе способы аналогичные. Точнее добавление символов хуже: сложность запоминания и ввода увеличивается, а вот в итерациях физическое время вычисления не меняется.
Но… на самом деле может и меняться, потому что пользователь может со временем тратить меньше денег на видеокарту, а вот злоумышленник тратить меньше не станет. В этом случае придётся комбинировать оба метода.
VolCh
31.03.2018 12:142 года вполне практически допустимый срок атаки даже для условно бытовых целей типа подбора любым сотрудником пароля гендира или админа для своих мелких личных корыстных или даже хулиганских целей. Или школьником пароля от домашней сети и т. п.
dragoangel
30.03.2018 20:38Ваши подсчеты в корне не верны — вы даже в расчет не берете количество символов. Я в паролях где это возможно сейчас даже ASCII символы юзаю.
Плюс вы не учитываете тот факт что в KeePass не один метод шифрования для всех БД. Почитайте про ChaCha20 и Argon и вы поймете что вы не правы. Вы сами хозяин своей БД и сами выбираете насколько много итераций на ней выставить.
sumanai
30.03.2018 22:05Плюс вы не учитываете тот факт что в KeePass
В этой теме речь идёт о Firefox, автор первого сообщения ветки упомянул ещё lastpass. KeePass конечно же надёжнее первых двух, с этим явно никто не будет спорить. У меня вот сейчас чуть больше 10 млн итераций хеширования.
Paranoich
30.03.2018 15:34«Новость» воскресили ещё 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)
dragoangel
30.03.2018 15:34Общеизвестный факт, не вижу чего паниковать, и не знаю ни одного браузера или почтового клиента который надежно хранит пароли от сохраненных в нем учетных записей. Сюда летят и Chrome (и все детища Chromium: Opera и тд) и Firefox и IE и клиенты Outlook, Thunderbird и тд. Банально берем Google и пишем кодовое слово: nirsoft. Запуском 2вух утилит получаем все пароли из вышеперечисленного софта:
WebBrowserPassView
Mail PassView
Ну в этой ситуации мы… просто наше это самое… мы уже… здесь наши полномочия все… окончены. Так что если вы такой же параноик как я: юзайте уникальные пароли на каждый сайт\сервис, используйте двухфакторку где это нужно если это возможно.
P.S. Сам пользуюсь KeePass хоть и знаю что и с него можно своровать пароли но куда сложнее: только если он находится в разблокированном состоянии через инъекцию библиотеки в процесс и вызова функции экспорта паролей в csv например — исходники на github проект KeeFarce. Но так как это инъекция, а не банальное считывание файла с %USERNAME%\AppData (так считываются пароли с бд браузеров) то такое поведение может хотя бы антивирус словить по эвристике и по сигнатурам если он есть.
sumanai
Давно отказался от встроенного менеджера в пользу KeePass и ни разу не пожалел. Оказывается не зря.
Для защиты других данных поставил мастер пароль, который вводит тот же KeePass, только намного более длинный, чем используют обычные люди, думаю, подобрать его будет сложно даже с однопроходным SHA1.
VolCh
Подбор через коллизии может найти и более короткий вариант вашего пароля :)