В этой статье рассказывается об очень серьёзной и распространённой угрозе бизнес-данным, так что давайте сразу же перейдём к ней:
Стандартные функции управления паролями браузеров Chrome, Firefox и Edge обеспечивают лишь видимость защищённого хранения паролей. На самом деле, они не дают абсолютно никакой защиты сохраняемых пользовательских паролей.
Если ваши сотрудники используют эти браузеры для хранения своих рабочих паролей, то, скорее всего, возникает серьёзный риск, который легко подвергнуть эксплойтам, он требует вашего немедленного внимания. Вероятно, ваши критически важные внутренние системы бизнес-данных, поставщики и клиенты в гораздо большей опасности, чем вы можете себе позволить.
Есть ли угроза для вас?
Предположим, что ваши сотрудники поступают правильно, создавая сложные, случайные и уникальные пароли для всех аккаунтов, связанных с работой. Но их много: один для корпоративной почты, другой для Dropbox, третий для заказов на платформе поставщика, четвёртый для HR-портала, пятый для AWS, и ещё множество других для всех бизнес-сервисов, которые они используют в работе.
Вам нужно задаться простым вопросом:
«Как наши сотрудники хранят свои рабочие логины и пароли?»
Если вы не давали заранее им никаких рекомендаций или инструментов, то скорее сотрудник поступит одним из трёх способов:
- Будет записывать пароли на бумажке.
- Сохранит пароли в документ на своём компьютере.
- Будет хранить пароли во встроенном менеджере паролей браузера.
Надеюсь, у вас есть программа обучения корпоративной безопасности и вы уже давно препятствуете первым двум ситуациям (хотя некоторые люди могут всё равно пользоваться этими способами).
Тогда можно быть практически уверенным, что большинство сотрудников использует для хранения своих длинных и сложных паролей браузеры. Хотя подобная система неидеальна, многие компании считают такие встроенные функции «достаточно безопасными». А поскольку браузеры постоянно предлагают свою помощь в сохранении каждого вводимого пользователем пароля, будет неудивительно, что сотрудники хранят их именно так.
Так в чём проблема?
Логично предположить, что готовая стандартная функция популярного браузера должна быть достаточно безопасной, однако она небезопасна по определению!
Вот что мы под этим подразумеваем:
Даже несмотря на то, что Chrome, Firefox и Edge хранят пароли в зашифрованных базах данных, по умолчанию все три продукта намеренно оставляют связанные ключи шифрования совершенно незащищёнными и хранят их в предсказуемых местах.
Скажем прямо: шифрование бесполезно, если ключи не защищены. Зашифрованная база данных менеджера паролей с незащищённым ключом не предоставляет никакой значимой защиты паролям.
Сложно поверить, что в три популярных браузера намеренно добавили функцию, которая столь вопиюще небезопасна. Это кажется совершенно нелогичным!
Что ещё более удивительно, у всех этих браузеров на самом деле есть механизмы для защиты ключей при помощи установки дополнительного master- или primary-пароля, однако он не включён по умолчанию, и браузер никогда не предлагает его активировать!
Почему же вообще эту функцию спроектировали таким образом? Скорее всего, потому, что это простейший способ предложить сохранять пароли в браузерах без дополнительных требований к пользователю установить master-/primary-пароль для защиты ключа шифрования. А если вы уже сохранили несколько паролей, то вероятность того, что вы начнёте пользоваться другим браузером, снижается.
Хотя использование этого небезопасного способа хранения по умолчанию плохо само по себе, ещё более непростительно то, что браузер никогда не уведомляет пользователя, что тот использует небезопасный способ хранения. Это создаёт впечатление, что всё в порядке — поистине ужасная система безопасности!
Можно привести такую аналогию — вы заперли все двери своего дома на самые надёжные замки, но потом положили ключ под коврик, потому что так поступают все соседи. Вам может казаться, что вы в безопасности, но так ли это на самом деле? Если вор легко может понять, где взять ключ, то это точно не так!
Из-за этого браузерного решения, если кто-то сможет получить доступ к системе сотрудника при помощи фишинга, вредоносной программы или любого другого эксплойта, то он с лёгкостью извлечёт все имена пользователей и пароли, хранящиеся в браузере сотрудника. Чуть позже мы покажем, что использовать этот изъян можно тривиальным образом.
Убедитесь сами
Честно говоря, мы не могли поверить, что этот изъян настолько просто использовать, когда он впервые привлёк наше внимание. Разумеется, мы не были абсолютно уверены в безопасности встроенных в браузеры менеджеров паролей, но всегда считали, что взломщику, по крайней мере, придётся использовать баг в браузере или применять сложные технические навыки.
Но нет — нам потребовался всего час, чтобы изучить и собрать окружение-песочницу для подтверждения наличия этого изъяна. При этом оказались не нужны какие-то особые навыки или технические трюки.
Убедитесь сами:
В этом коротком видео мы продемонстрировали, как легко будет злоумышленнику извлечь пароли из Chrome, Edge или Firefox, запущенного на настольном компьютере с Windows. Мы использовали каждый из браузеров для создания аккаунта на реальном веб-сайте, а затем запустили скрипт командной строки для расшифровки базы данных каждого браузера и вывода на экран её содержимого, то есть только что введённых имён пользователей и паролей.
То есть на самом деле для сотрудников хуже использовать эти браузерные менеджеры паролей, чем ввести пароли в какой-нибудь документ Word или Excel, а ведь от этой практики вы отговаривали в течение долгих лет. Чтобы понять, почему, просто задайтесь вопросом, что более вероятно: злоумышленник будет прочёсывать скомпрометированную операционную систему, чтобы, возможно, наткнуться на чей-то личный документ с сохранёнными паролями, или просто стянет файлы менеджера паролей, которые хранятся незащищёнными и именно там, где и должны быть?
В итоге он получит полный неограниченный доступ ко всем сохранённым паролям!
Что это значит для вашей компании?
Руководству компаний нужно привыкнуть к мысли, что учётные данные сотрудников (имена пользователей и пароли) — это ещё один вид критически важных бизнес-данных, наряду с исходным кодом, клиентскими данными или документы отдела HR. И при работе с ними нужно принимать те же меры предосторожности.
Многие компании совершенного не осознают этот факт и считают сохраняемые учётные данные сотрудников разновидностью персональных данных. Компания может устанавливать некие правила — требования к сложности паролей, график их смены и так далее, но в общем случае компрометация аккаунтов обычно считается проблемой конкретного человека, а не прямой угрозой бизнесу.
Это очень недальновидно и очень скоро может превратиться в проблему. Представьте следующие ситуации:
- Ваша компания стала мишенью для киберпреступной группировки, занимающейся вымогательством. Успешная фишинговая атака позволила низкоуровневому вирусу распространиться по корпоративной сети. Единственная задача вредоносной программы — извлечение баз данных и ключей браузеров; благодаря этому хранилище каждого сотрудника оказывается скомпрометированным, открывая возможности объёмной утечки данных.
- Нацеленная фишинговая атака на вашего финансового директора приводит к компрометации менеджера паролей, в котором хранятся сведения для входа в его электронную почту; таким образом возникает ситуация компрометации бизнес-почты (business email compromise, BEC). Клиенты начинают сообщать, что отправили свои ежеквартальные платежи на новый счёт офшорного банка, потому что получили сообщение, очень похожее на настоящее письмо от финансового директора, с просьбой использовать новый код банка. И это только начало ваших проблем.
Вот так возникают кошмары для бизнеса!
Что сделать для управления этим риском?
Если вы отвечаете за безопасность компании, то обязаны защищать все бизнес-данные, в том числе и учётные данные сотрудников. Теперь, когда вам известно об этой опасности, вы обязаны предпринять действия для снижения риска. Нужно обеспечить безопасный и эффективный способ хранения учётных данных сотрудников и сделать так, чтобы они в ближайшее время начали пользоваться им.
Самый простой способ реализовать это — развернуть защищённый специализированный менеджер паролей, например, 1Password, Bitwarden, LastPass или Keeper. Enterprise-версии этих продуктов предоставят вам централизованное управление безопасностью паролей и упростят безопасную передачу учётных данных.
Стоит заметить, что у многих таких специализированных менеджеров паролей есть браузерные плагины или расширения, помогающие пользователям сохранять и вставлять пароли. Они сильно отличаются от встроенных менеджеров паролей и гораздо безопаснее их.
Можно попробовать просто стимулировать сотрудников защищать ключи шифрования установкой упомянутого выше master-/primary-пароля, однако для этого может понадобиться много труда; обычно в долговременной перспективе лучше развернуть специализированный менеджер паролей, пусть даже и с оплатой подписки.
Не знаете, с чего начать? Мы разработали базовый план по восстановлению, который можно адаптировать к потребностям вашей организации.
Предлагаемый план действий
▍ Шаг 1 — примерно оцените свои риски
Созовите совещание отделов ИТ и ИБ, чтобы понять, насколько сложна проблема, с которой вы столкнулись.
Задайте представителям отделов следующие вопросы:
- Когда в последний раз обновляли и рассылали сотрудникам инструкцию по хранению паролей, и происходило ли это когда-нибудь?
- Указывает ли компания, какие браузеры считаются приемлемыми? Могут ли сотрудники устанавливать любой нужный им браузер? Есть ли у нас система инвентаризации ПО, показывающая, сколько установлено разных браузеров в нашей компании?
- Как отделы ИТ и Cloud Ops обмениваются неиндивидуальными паролями, например, аккаунтами от сервисов или логинами root?
- Есть ли в компании сотрудники, уже использующие специализированные менеджеры паролей по своей инициативе?
- У каких наиболее критически важных бизнес-систем необходимо защищать логины?
- Где мы обязательно требуем использовать 2FA / MFA или SSO для входа в критически важные системы?
▍ Шаг 2 — установите временную политику
Если присутствует существенный риск того, что сотрудники используют небезопасные браузерные менеджеры паролей, то выпустите чёткую и конкретную временную политику со следующими требованиями:
- Все, кто пользуется для хранения паролей браузером Chrome, Firefox или Edge, должны включить функцию шифрования master- или primary-паролем.
- Все пароли, сохранённые в браузере до включения этой функции, должны считаться подозрительными и подлежат сбросу. Все пароли для критически важных бизнес-систем [здесь нужно указать их список] должны быть сброшены в течение [«X»] дней, а все прочие должны быть сброшены в течение [«Y»] дней.
- Всем сотрудникам не рекомендуется сохранять новые пароли в своих браузерах, но это допускается при соблюдении приведённых выше условий.
- Не выполняющие эту политику сотрудники подвергают компанию потенциальной угрозе безопасности и могут быть подвергнуты дисциплинарным взысканиям.
▍ Шаг 3 — донесите до сотрудников изменения политики
- Объявите о новой политике сотрудникам и предоставьте инструкции о том, как включить функцию шифрования в браузерах.
- Отдел ИТ должен быть готов помогать сотрудникам с изменениями в конфигурации.
- Сообщите об изменениях людям, занимающимся введением в штат новых сотрудников, чтобы они обучались политике с начала работы.
- Повторяйте эту информацию в течение нескольких дней по разным каналам (электронная почта, чаты, совещания менеджеров и так далее), чтобы подчеркнуть важность политики и её соблюдения. Возможно, сотрудникам стоит в явной форме подтвердить своему руководителю или отделу ИТ, что они предприняли все необходимые шаги, указанные в политике.
▍ Шаг 4 — разработайте долговременное решение
- Соберите высшее руководство, чтобы установить функциональные требования к менеджеру паролей, и выделите небольшую команду для проверки и оценки разных поставщиков. Особое внимание уделяйте функциям безопасности и управления. Обязательным требованием должна быть возможность централизованного принудительного включения 2FA / MFA.
- Существует несколько продуктов с бесплатными версиями, которые могут быть экономным решением для масштабного развёртывания в крупной, чувствительной к затратам организации. Однако имейте в виду, что чаще всего бесплатные версии предназначены только для индивидуального использования, поэтому вы, скорее всего, не будете иметь контроля за их использованием (например, возможности принудительного включения 2FA / MFA).
- После выбора продукта приложите большие усилия к разработке материалов обучения сотрудников и инструкций по администрированию для отделов ИТ до общего развёртывания системы для сотрудников. Донесите до всех, что может и чего не может сделать отдел ИТ в помощь сотрудникам, забывшим primary-пароль шифрования.
- Разработайте план аудита всех хранилищ общих паролей. Как минимум раз в квартал проверяйте, что к общим паролям имеется доступ только у нужных людей.
- Поработайте с людьми, отвечающими за введение и выведение из штата сотрудников, чтобы новые сотрудники обучались пользованию менеджером паролей и чтобы доступ уволенных сотрудников прекращался должным образом.
Подведём итоги
▍ Немного о «небезопасности по умолчанию»
В статье много раз говорилось о том, что браузерные менеджеры паролей небезопасны «по умолчанию». Но ситуация могла быть и другой — сами их производители (Google, Mozilla, Microsoft) решили сделать так, чтобы максимизировать удобство, полностью скомпрометировав зашифрованное хранилище.
Как говорилось выше, во всех трёх браузерах есть готовые механизмы защиты ключей шифрования. Это можно сделать, задав primary- или master-пароль — по сути, это единственный пароль, который нужно запомнить, помогающий шифровать все другие сохраняемые пароли. Однако это совершенно необязательно должно быть поведением по умолчанию, и такая ситуация ужасна, ведь разработчики точно знали, что большинство пользователей не понимает, как это работает и никогда не будет активировать функцию защиты вручную. Из-за этого риску подвергаются миллиарды пользователей.
Решение этой проблемы очевидно — Google, Mozilla и Microsoft достаточно изменить поведение по умолчанию так, чтобы пароль шифрования был обязательным. Если вы хотите дать пользователям возможность не использовать пароль шифрования, пусть будет так, но они должны вручную деактивировать конфигурацию (со множеством предупреждений о том, насколько это небезопасно).
Специализированные менеджеры паролей (LastPass, Keeper, 1Password, etc.) всегда по умолчанию требуют пароля шифрования с опциональной (но крайне рекомендуемой) 2FA.
▍ А что насчёт MacOS и Safari?
Браузер Safari тесно связан с функциями безопасности Apple ID в MacOS и не имеет этого изъяна в безопасности, поэтому здесь Apple можно похвалить. Даже если в вашей компании уже используются ноутбуки MacOS, маловероятно, что небезопасные Chrome и Firefox будут популярным требованием у сотрудников.
Показанные в видео скрипты эксплойтов, требуют совместимых с Windows модулей Python и тестировались только на браузерах, установленных в Windows. Нам не удалось найти скрипты, выполняющие такой же эксплойт для браузеров Chrome и Firefox, установленных в MacOS. Однако способ хранения внутренних данных браузеров очень схож в обоих операционных системах, поэтому, вероятно, программы в MacOS тоже подвержены этому изъяну, если предположить, что подобные модули расшифровки на Python есть для MacOS или их можно написать.
▍ Спасибо, но мы уже используем отдельный менеджер паролей
Это здорово, но риск всё равно может быть. По умолчанию встроенные браузерные менеджеры паролей так раздражающе настойчиво просят сохранить пароли, что велика вероятность того, что ваши сотрудники случайно (или намеренно) сделали это.
Организации, выбравшие браузер, который они рекомендуют использовать своим сотрудникам, могут пойти ещё дальше и отключить его встроенный менеджер паролей или при помощи принудительной технической политики, или настроив браузер перед передачей ноутбука сотруднику. В Chrome, Firefox, и Edge есть возможность сделать это относительно просто, если у вас есть централизованная реализация политик конфигурирования.
▍ Можете показать, как вы тестировали этот изъян?
Мы намеренно не раскрываем подробностей, демонстрирующих работу скриптов эксплойтов, и не говорим, откуда их взяли. Эта статья не является туториалом по выполнению эксплойта. Наша цель — привлечь внимание бизнес-сообщества к этой угрозе безопасности данных.
Все скрипты были найдены в свободном онлайн-доступе и незначительно изменены для удобства демонстрации.
Telegram-канал и уютный чат для клиентов
Комментарии (51)
vilgeforce
19.09.2022 17:02+4"все три продукта намеренно оставляют связанные ключи шифрования совершенно незащищёнными" - ну что же вы такое пишете? Ни один из браузеров не хранит ключи шифрования сохраненных паролей вообще, если master-пароль не используется! И более того скажу: браузеры это шифрование даже не реализовывают!
Секрет прост: используется системный DPAPI, в частности функции CryptProtect + CryptUnprotect. Ваш туман загадочности с "намеренно не раскрываем подробностей" совершенно не нужен, особенно на техническом ресурсе. Скрипткиддисы уже все знают и умеют.
aamonster
19.09.2022 17:46Секрет прост: используется системный DPAPI, в частности функции CryptProtect + CryptUnprotect.
А под виндой он совсем уж бесполезный для данной цели, получается?
Под Mac OS, если приложение положило что-то в keychain – другому afaik так просто дотянуться до этой записи не получится. Надо права дать (или приложение, которое положило, или юзер явно).vilgeforce
19.09.2022 17:49Другой пользователь тоже не сможет расшифровать данные. Трояны всегда расшифровывают их на машине жертвы именно по этой причине.
aamonster
19.09.2022 17:56Другой пользователь – не совсем то... ну или совсем не то. Права на keychain разделены по приложениям (правда, это требует подписи приложений). Ну или можно в group keychain положить – чтобы было доступно нескольким приложениям одного разработчика.
vilgeforce
19.09.2022 17:58Ну вот подписи в приложениях нужны...
aamonster
19.09.2022 18:58Ну да. Но разработчику-то это жить не мешает. Собственно, приложения при сборке по умолчанию подписываются: юзеру ж неподписанное не дашь. Он, может, даже запустить неподписанное не сумеет.
Была бы поддержка в системе.
Zer0Sum
19.09.2022 17:02Я храню свои личные пароли в Bitwarden, думая, что защищён. А тем временем мой мастер-пароль для входа на сайт самого Bitwarden, из 32 рандомных символов, который я специально запоминал и нигде не записывал, "хранится" у Firefox и может запросто предоставить доступ злоумышленнику к централизованному хранилищу всех моих паролей. Вот так новость! Не ожидал такого от любимого браузера. Неужели теперь придётся новый мастер-пароль заучивать...
dartraiden
19.09.2022 19:23+3который я специально запоминал и нигде не записывал
Если вы его не сохраняли в браузере, то он там и не сохранён. Посмотрите в списке сохранённых паролей.
Кроме того, если вы пользуетесь сторонним менеджером паролей, отчего в настройках браузера совсем не отключить сохранение паролей в браузере?Zer0Sum
19.09.2022 21:00Разумно, но дело как раз в том, что для быстрого входа на сайт Bitwarden, я сохранил мастер-пароль в браузере, когда он мне это предложил =/
dartraiden
19.09.2022 22:02+4В таком случае, просто удалите его из сохранённых в about:logins
У меня, например, сохранение паролей отключено вовсе. Все пароли хранятся в KeePass, а запросы браузера «сохранить пароль?» при этом только мешают.
aborouhin
19.09.2022 20:06+1Для FF есть addon Bitwarden, который если и хранит мастер-пароль - то точно не тем способом, каким сам FF сохраняет пароли (хотя с этим тоже интересно бы разобраться, как он его хранит). У меня он его спрашивает заново при каждом перезапуске браузера, но можно настроить хоть в 1 минуту таймаут.
shteyner
19.09.2022 17:24Мне почему-то казалось, что мастер паролем для бд будет пароль учетной записи в windows
vilgeforce
19.09.2022 17:26+1Вы отчасти правы в случае отсутствия мастер-пароля: DPAPI позволяет расшифровать данные только под тем юзером, который их и шифровал...
sden77
19.09.2022 19:34В фаерфоксе, очевидно, ничего не привязано к юзеру, т.к. папку профиля можно спокойно копировать между разными компьютерами, в т.ч. даже между разными ос и все сохранённые пароли остаются на своём месте
nidalee
20.09.2022 00:34Подтверждаю, так и бекаплю браузер — тупо папку из appdata копирую — все пароли и активная синхронизация в комплекте.
dartraiden
19.09.2022 19:26У учётной записи может отсутствовать пароль.
shteyner
19.09.2022 19:27Ну, тогда что вообще защищать)
dartraiden
19.09.2022 19:29+1DPAPI даже в таком случае обеспечивает защиту против сценария «пока жертва отлучилась я стянул профиль браузера, чтобы дома неспеша его поковырять». Придётся ещё и какую-то утилиту именно из-под этой учётки запускать, чтобы расшифровать.
А вот у Firefox именно так — достаточно профиль стянуть, дальше можно спокойно копать на своей машине. Потому что либо там пароли зашифрованы мастер-паролем, придуманным и вводимым пользователем, либо не зашифрованы вообще.shteyner
19.09.2022 19:34Если пароля нет, значит, скорее всего, это админ (в домене пустых паролей не бывает обычно, а тут походу дела один пользователь на компе), если это админ, можно поставить какое-нибудь ПО, если можно поставить какое-нибудь ПО, значит комп может перейти к злоумышленнику. В общем решать проблемы нужно по мере важности, в начале пароль от системы и привычка блокировать экран когда отходишь, а уже потом смотреть на менее очевидные дыры в безопастности.
Да и от юзера многое можно запустить
redsh0927
19.09.2022 18:29+8Раньше никогда не пользовался менеджером паролей в браузере, но последние годы у всех современных сайтов склерозная чума. Авторизация живёт в лучшем случае пару дней, чекбокс «запомнить меня» абсолютно нихрена не даёт. 10 лет назад, куда не зайдёшь — уже авторизован. И сейчас на всех сайтах, куда не успели добраться всякие современные фреймворки — всё отлично работает. Везде же где успели обновить — без автозаполнения авторизации юзать абсолютно невозможно.
vadimk91
20.09.2022 07:21И не только у сайтов. В одной ИС, в которой работают многие коллеги, пошла мода по десятку раз за день вылетать на ввод пароля. Техподдержка ответила, что это норма (?!), мол система сильно нагружена и неактивных юзеров разлогинивает. Менеджеров паролей нам не завезли, usb брелков тоже, кто-то будет руками вбивать десятки раз эти пароли "не менее 8 символов, обязательно прописные и строчные, спецсимволы, не совпадающие как минимум 3 символами с 4 предыдущими, со сроком действия 60 дней"? Нет конечно.
paluke
19.09.2022 19:10+1Хм, хранить пароли в специализированном менеджере паролей… А этот менеджер паролей вы собственноручно собрали из исходников? А исходники внимательно проверили на отсутствие бекдоров? А уверены, что вашей квалификации достаточно, чтобы найти бекдор в этих исходниках?
dartraiden
19.09.2022 19:27+6Входную дверь я тоже не сам сделал. И замки. Видимо, нет смысла запирать входную дверь, раз невозможно быть абсолютно уверенным в её надёжности. Или абсолют, или ничего.
Ilyasyakubov
19.09.2022 20:17+2Очевидно, абсолют недостижим. Даже, если ответить «да» на все вопросы выше, всегда остается вероятность того, что, например, оценил свою квалификацию, как достаточную, а на деле ошибся.
Urub
19.09.2022 19:36+1для более важных паролей создал сриптоконтейнер и профиль браузера firefox храню в нем - это мне удобней менеджеров паролей
aamonster
20.09.2022 01:20А софтина, которую вы используете для криптоконтейнера, умеет ограничивать лезущие в него приложения (firefox можно, трояну нет)?
Urub
20.09.2022 08:27+2криптоконтейнер тут решает только одну задачу - если я не ввел пароль, то никто к моему профилю браузера не получает доступ при запуске компа или иным способом если получает доступ к диску
aamonster
20.09.2022 09:46Жаль. Интересно было бы увидеть именно решение для Windows, изолирующее важные данные от других приложений (на Маке-то это сделано "из коробки").
Прямо хоть заводи отдельного юзера
(или виртуалку)только для запуска браузера...
CaptainFlint
20.09.2022 12:49Придётся ещё кучу способов межпроцессного взаимодействия убить, так как зловред может и не иметь доступа к контейнеру, но когда браузер, имеющий доступ, прочитает нужный пароль, зловред сможет считать его уже из памяти браузера. И просто так запретить такое считывание будет проблематично: множество программ уже на это завязано, всё поломается.
aamonster
20.09.2022 13:00Не, ну если зловред с большими правами – мало что можно сделать. Но сейчас прочитать контейнер, как я понимаю, может совершенно обычное приложение, запущенное не от администратора.
CaptainFlint
20.09.2022 14:01Любой процесс, запущенный от юзера А, может прочесть память любого другого процесса, запущенного от того же юзера, админские права для этого не нужны. То есть да, можно защититься от такого сценария, если запускать браузер от админа, но эта идея — мягко говоря, так себе идея.
saege5b
19.09.2022 19:41Если компания будет оплачивать платные хранители, с работой в Виндовс, Линукс, Андроид - с удовольствием буду пользоваться.
А так - на рабочем компе работают люди с допуском. Зачем огород городить - проще ограничить хождение людей без допуска.
CaptainFlint
19.09.2022 20:23+2Представьте следующие ситуации:
…и все ваши пароли благополучно утекают независимо от того, каким способом они хранятся. Разница только в том, что из незашифрованного профиля браузера они будут стырены сразу же, а из менеджера паролей — в момент, когда пользователь вводит мастер-пароль.
<…> Успешная фишинговая атака позволила низкоуровневому вирусу распространиться по корпоративной сети.
Revertis
19.09.2022 20:51Кстати, а как отключить назойливые предложения сохранить пароль в Гугле на андроид-смартфоне?
DmitryKoterov
20.09.2022 04:19+4Сенсация! Если злоумышленник получил возможность запускать произвольный исполняемый файл на машине жертвы под юзером жертвы, то он, оказывается, может стянуть с него любые данные! Просто-таки невероятно, мир опасносте!
Мастер-пароль ни от чего не защищает, потому что он все равно хранится в памяти (или его хэш), чтобы юзеру не приходилось его все время вводить для каждого нового аккаунта. Раз он в памяти, значит, произвольная запущенная программа может его оттуда считать точно так же. Все эти шифрования файлов - это security over obscurity, для тех, кто осилил написать прогу, тырящую файл, но не осилил написать прогу, тырящую память браузера.
Или нет, и есть какой-то способ не дать проге, запущенной под текущим юзером, прочитать память браузера, запущенного под этим же юзером? Или подменить браузер на что-то другое? (В линуксе это вообще делается как чтение из файла /proc/xyz/mem или типа того.)
lohmatij
20.09.2022 12:13На маке же как то сделали?
balamutang
22.09.2022 10:46На маке в сафари оно пароли хранит в системном хранилище, не в браузере. А в винде браузерные пароли хранятся силами браузеров. В убунте кстати вроде бы тоже подобная организация, отдельное хранилище ключей. По крайней мере так было лет 5 назад когда я последний раз пользовался десктопной убунтой.
penetration
20.09.2022 11:48Лис умеет шифровать данные оконченным шифрованием, аккаунт Firefox Sync не хранит ни пароль, ни его хеш.
При входе/регистрации аккаунта, на основе вашего пароля генерируются два независимых значения (PBKDF2 + scrypt), аутентификационный ключ и ключ расшифровки ваших данных.
Аутентификационный ключ посылается на сервер, чтобы он убедился, что вы владелец, он в свою очередь вам присылает зашифрованные данные, которые вы расшифровываете вторым ключом, которому у Mozilla нет доступа.
Да, есть свои недостатки, ваш ключ в файле logins.json, зашифрован, но его всёравно можно угнать стилером, но при этом случае, даже мастер пароль роли не играет, но это пока, что лучшее, что есть у браузеров.
Holix
Чтож, полезная информация. Спасибо.
И как же это сделать? Тема не раскрыта.
gangz
Оснастка для домена позволяет раскидать такое требование политикой для Chrome - точно, для ежа, видимо, тоже, огнелис - под вопросом)
dartraiden
Меня больше интересует иное. Вот в статье есть два полностью противоречащих друг другу утверждения, процитированные вами. То есть, стандартные средства, встроенные в браузеры, «не дают абсолютно никакой защиты», но при этом, нужно включить стандартное же средство в виде мастер-пароля (и это правда).
При этом, статья заплюсована. Кто все эти люди? Ну ладно, можно не разбираться, как работать мастер-пароль. Но у читателей ничего в голове не шелохнётся, когда им сначала говорят одно, а потом совершенно противоположное? Хотя бы простейший вопрос «эй, но ведь ты пару минут назад совсем другое говорил, как же так». Они покорно кивают, жмякают плюсик и отправляются загонять свои пароли в LastPass?
CrazyOpossum
Ну я например плюсанул бы, но информация довольно очевидная. В чём противоречие? Статья неглубокая, но 100% верная.
dartraiden
Противоречие в том, что либо браузер стандартными средствами не может надёжно защитить пароли, либо может. Оба утверждения одновременно не могут быть истиной. В статье же утверждается и то, и другое — в начале статья безапелляционно заявляется, что браузер «абсолютно» не может, но дальше утверждается что может (стандартным средством — мастер-паролем).
Qetzlcoatl
Перечитайте статью ещё раз. В ней утвержадется, что "стандартные средства браузера не защищают пароли пользователя в конфигурации ПО-УМОЛЧАНИЮ", и что "есть встроенный механизм, дающий достаточный уровень защиты, но ПО-УМОЛЧАНИЮ отключенный", который "настойчиво рекомендуется включить". Где здесь противоречия?