Comments 32
UFO just landed and posted this here
Какой алгоритм не применяй, а qwerty и перебор по словарю был, есть и будет.
Ну а с какой скоростью можно перебирать указанные альтернативы?
Это техническая статья или что?
Или аудитория хавает?
Это техническая статья или что?
Или аудитория хавает?
Современные 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 часа, ну или на сотне видеокарт за сутки.
Можно запомнить рандомный пароль в ~12 символов и пока спать спокойно.
Вы несёте бред. 12 символьный полностью рандомный пароль по алфавиту из 95 символов (все знаки пунктуации, цифры, заглавные и строчные буквы) переберётся на 1 млрд видеокарт всего лишь за 15 часов.
А если Вы используете алфавит только 62 символа, то хватит 5 минут.
Если алфавит 36 символов (a-z и цифры), то хватит пол секунды.
Надо использовать как минимум 15-символьный полностью рандомный пароль по алфавиту 95 символов — его перебор займёт 1470 лет, т. е. это пароль низкой сложности — самая минимальная длина, которую можно использовать.
Но если бы Mozilla улучшила менеджер, то эта длина могла бы сократиться на 2.5 символа, что ОЧЕНЬ много.
переберётся на 1 млрд видеокарт всего лишь за 15 часов.
Сожрав при этом 3ТВт*ч энергии? Не все пароли настолько ценны, чтобы так платить.
Это сегодня 3ТВт*ч. Но теоретически каждые 2 года мощности видеокарт может расти примерно в 2 раза. Получается уже через 10 лет требуемое время и электроэнергия снизятся в 32 раза.
Через 20 лет снизится в 1024 раза — потребовалось бы всего лишь 1 млн видеокарт. 1 млн видеокарт на 15 часов — вполне реально.
Электроэнергия при этом тоже может серьёзно подешеветь. Например, стоимость перебора такого пароля может составить 2 млн рублей.
Далее, если бизнес может предложить видеокарты по какой-то стоимости, нельзя исключать, что на самом деле кто-то располагает более высокими технологиями. Ему конечно было бы выгодно продать их, но всё-равно.
В общем, 1 млрд видеокарт берётся для того, чтобы покрыть всякие такие риски, ведь неизвестно, как будут развиваться технологии в будущем. Даже сейчас в статье написано, что nvidia считает 10 млрд хэшей в секунду. Но где гарантии, что кто-то не считает больше? А может даже существуют специализированные устройства, оптимизированные под подсчёт хэшей.
Через 20 лет снизится в 1024 раза — потребовалось бы всего лишь 1 млн видеокарт. 1 млн видеокарт на 15 часов — вполне реально.
Электроэнергия при этом тоже может серьёзно подешеветь. Например, стоимость перебора такого пароля может составить 2 млн рублей.
Далее, если бизнес может предложить видеокарты по какой-то стоимости, нельзя исключать, что на самом деле кто-то располагает более высокими технологиями. Ему конечно было бы выгодно продать их, но всё-равно.
В общем, 1 млрд видеокарт берётся для того, чтобы покрыть всякие такие риски, ведь неизвестно, как будут развиваться технологии в будущем. Даже сейчас в статье написано, что nvidia считает 10 млрд хэшей в секунду. Но где гарантии, что кто-то не считает больше? А может даже существуют специализированные устройства, оптимизированные под подсчёт хэшей.
Да, забыл ещё упомянуть ботнеты — когда подсчёт ведётся на взломанных устройствах обычных пользователей, тогда электричество бесплатно.
Вы теоретизируете или знаете реальную возможность обеспечить необходимую производительность?
При подсчёте безопасности не так сильно нужно знать реальную производительность, теории будут безопаснее. Например, вполне можно представить ботнет из 10 млн видеокарт. Это не значит, что он существует, но ведь такое теоретически возможно? Да. Мы всегда должны рассматривать худший случай.
Конечно это не отменяет того факта, что реальность будет лучше теории. Это хорошо, значит у нас есть какой-то запас. Можно спать спокойно.
Конечно это не отменяет того факта, что реальность будет лучше теории. Это хорошо, значит у нас есть какой-то запас. Можно спать спокойно.
Тогда я снова добавлю пару символов в пароль.
Я понимаю, что устаревший sha1 не есть хорошо, и лучше бы его чем-то заменить, но риторика типа "нужно хэшировать 100тыс.раз, как делают нормальные люди" или это ваше "вы несёте бред, миллиарды видеокарт" — сама по себе ересь.
1 млрд видеокарт, как по мне, стандартная цифра для рассчёта, покрывающая риски. Даже сейчас существования ботнета из 10 млн видеокарт не кажется фантастикой. А что уж говорить про будущее.
Но если Вы так хотите, сократите до 1 млн видеокарт и получится всё-равно 625 дней. Но здесь уже заметно вырастают риски. Видите, удобнее брать 1 млрд — и запас на будущее есть, и запас на то, что кому-то пароль будет сильно нужен. Это не какая-то завышенная цифра.
Но если Вы так хотите, сократите до 1 млн видеокарт и получится всё-равно 625 дней. Но здесь уже заметно вырастают риски. Видите, удобнее брать 1 млрд — и запас на будущее есть, и запас на то, что кому-то пароль будет сильно нужен. Это не какая-то завышенная цифра.
Тогда я снова добавлю пару символов в пароль.Но кто получил старые данные, всё-равно сможет их расшифровать. Хотя если брать браузерный менеджер паролей, то здесь можно просто поменять пароли на всех сайтах.
Я понимаю, что 12-значные пароли рано или поздно можно будет разгадать, равно как и 16-значные (но чуть позже). В этом свете мне кажется более простым добавить N символов в пароль, чем городить алгоритмы с итерациями.
Добавление символов экспоненциально увеличивает сложность подбора, добавление итераций — линейно.
Ну и, я считаю 2 года вычислений слишком большим сроком, чтобы затратить их на мои пароли. Когда-нибудь это будет уже совсем не 2 года, но я считаю, что это будет достаточно не скоро. И тогда можно будет просто поменять пароль на более длинный.
P.S.: эта логика не относится к хранению паролей неразумных пользователей, которым может быть удобно использовать 6 цифр как пароль.
Я согласен, что в будущем надо подумать заново (когда это возможно), но безопасность ближайшего будущего всё-равно нужно обеспечить.
С таким же успехом, как Вы постепенно добавляете 2-3 символа, можно постепенно умножать количество итераций на 10-800 тыс. При этом длину пароля увеличивать уже не придётся.
Ну и само итерирование — это мощная вещь. Сравните: перебрать пароль за 1 час или за 114 лет. Потратить 10 рублей на электричество или 10 млн рублей.
добавление итераций — линейноЭто невероное утверждение. Сегодня мы сделали 10 итераций, через 4 года 100 итераций, ещё через 4 — 1000 итераций, потом 10 тыс — на лицо экспоненциальная зависимость.
С таким же успехом, как Вы постепенно добавляете 2-3 символа, можно постепенно умножать количество итераций на 10-800 тыс. При этом длину пароля увеличивать уже не придётся.
Ну и само итерирование — это мощная вещь. Сравните: перебрать пароль за 1 час или за 114 лет. Потратить 10 рублей на электричество или 10 млн рублей.
> добавление итераций — линейно
Это невероное утверждение. Сегодня мы сделали 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 раз.
Мы добавляем не K итераций, а, к примеру, 2ᵏ, где k изменяется во времени примерно линейно.
Тогда следует сравнивать с добавлением 2^k символов.
Но попробуйте сами рассчитать, как при этом меняется соотношение "наших" затрат и затрат "взломщика". И как меняется при добавлении символов.
Но Вы же не станете каждые 3 года добавлять 2ᵏ символов? Это получилось бы Вам надо было вначале добавить 2 символа, потом 4 символа, потом 8 символов и т. д. Боюсь представить длину Вашего пароля через 20 лет.
Нет конечно! Мне достаточно добавить k символов, тогда как вам — 2^k итераций. Это и есть экспоненциальная разница.
Такая же разница будет в соотношении объёмов "моих" расчётов и объёмов "взломщика".
Добавление символов экспоненциально увеличивает сложность подбора, добавление итераций — линейно.Ладно, добавление итераций линейно увеличивает сложность, Вы правы. Но я имел ввиду то, что мы можем без проблем добавлять итерации экспоненциально, а вот Вы можете только линейно.
В общем выразился я до этого абсолютно неверно, но сами по себе способы аналогичные. Точнее добавление символов хуже: сложность запоминания и ввода увеличивается, а вот в итерациях физическое время вычисления не меняется.
Но… на самом деле может и меняться, потому что пользователь может со временем тратить меньше денег на видеокарту, а вот злоумышленник тратить меньше не станет. В этом случае придётся комбинировать оба метода.
2 года вполне практически допустимый срок атаки даже для условно бытовых целей типа подбора любым сотрудником пароля гендира или админа для своих мелких личных корыстных или даже хулиганских целей. Или школьником пароля от домашней сети и т. п.
PS. Длина составила бы 12.5 символов.
Ваши подсчеты в корне не верны — вы даже в расчет не берете количество символов. Я в паролях где это возможно сейчас даже ASCII символы юзаю.
Плюс вы не учитываете тот факт что в KeePass не один метод шифрования для всех БД. Почитайте про ChaCha20 и Argon и вы поймете что вы не правы. Вы сами хозяин своей БД и сами выбираете насколько много итераций на ней выставить.
Плюс вы не учитываете тот факт что в KeePass не один метод шифрования для всех БД. Почитайте про ChaCha20 и Argon и вы поймете что вы не правы. Вы сами хозяин своей БД и сами выбираете насколько много итераций на ней выставить.
«Новость» воскресили ещё 19 марта, что вызвало потоки сообщений по теме «всё пропало».
А Asa Dotzler уже неделю назад внёс корректировку в план развития Firefox на 2018 год.
wiki.mozilla.org/Firefox/Roadmap
А 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)
Общеизвестный факт, не вижу чего паниковать, и не знаю ни одного браузера или почтового клиента который надежно хранит пароли от сохраненных в нем учетных записей. Сюда летят и Chrome (и все детища Chromium: Opera и тд) и Firefox и IE и клиенты Outlook, Thunderbird и тд. Банально берем Google и пишем кодовое слово: nirsoft. Запуском 2вух утилит получаем все пароли из вышеперечисленного софта:
WebBrowserPassView
Mail PassView
Ну в этой ситуации мы… просто наше это самое… мы уже… здесь наши полномочия все… окончены. Так что если вы такой же параноик как я: юзайте уникальные пароли на каждый сайт\сервис, используйте двухфакторку где это нужно если это возможно.
P.S. Сам пользуюсь KeePass хоть и знаю что и с него можно своровать пароли но куда сложнее: только если он находится в разблокированном состоянии через инъекцию библиотеки в процесс и вызова функции экспорта паролей в csv например — исходники на github проект KeeFarce. Но так как это инъекция, а не банальное считывание файла с %USERNAME%\AppData (так считываются пароли с бд браузеров) то такое поведение может хотя бы антивирус словить по эвристике и по сигнатурам если он есть.
WebBrowserPassView
Mail PassView
Ну в этой ситуации мы… просто наше это самое… мы уже… здесь наши полномочия все… окончены. Так что если вы такой же параноик как я: юзайте уникальные пароли на каждый сайт\сервис, используйте двухфакторку где это нужно если это возможно.
P.S. Сам пользуюсь KeePass хоть и знаю что и с него можно своровать пароли но куда сложнее: только если он находится в разблокированном состоянии через инъекцию библиотеки в процесс и вызова функции экспорта паролей в csv например — исходники на github проект KeeFarce. Но так как это инъекция, а не банальное считывание файла с %USERNAME%\AppData (так считываются пароли с бд браузеров) то такое поведение может хотя бы антивирус словить по эвристике и по сигнатурам если он есть.
Не все Хромиумы одинаковы habrahabr.ru/company/yandex/blog/344382
Дня обычных юзеров это возможно это удобное решение, и спорить не буду так как не пользовался. Но лично для меня: у меня глубокое недоверие к продуктам 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 для доступа к каким либо сервисам).
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 для доступа к каким либо сервисам).
Sign up to leave a comment.
Новая старая уязвимость: менеджер паролей Firefox уже 9 лет использует устаревший SHA-1