Keeper представляет BreachWatch

BreachWatch — это эффективный и безопасный дополнительный компонент. Он отслеживает Интернет и даркнет на предмет информации о взломе учетных записей, совпадающих с записями, которые хранятся в вашем хранилище Keeper Vault.

BreachWatch обеспечивает самый тщательный мониторинг из всех, доступных общественности, благодаря базе данных, которая содержит более миллиарда записей, и при этом поддерживает самую современную архитектуру безопасности Keeper с нулевым разглашением.

Обзор

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

Регистрация

Зарегистрироваться легко. В мобильном устройстве откройте BreachWatch и следуйте инструкциям на экране. Вы также можете приобрести BreachWatch непосредственно на веб-сайте Keeper Security.

После регистрации BreachWatch выполнит локальное сканирование паролей, которые в настоящее время хранятся в вашем хранилище Keeper Vault. Если какие-либо учетные данные пользователей совпадают с теми, что могли подвергнуться риску, пользователи получают соответствующее уведомление.

Функции BreachWatch

1. Если какой-либо пароль в хранилище совпадает со взломанным паролем, клиенты получают автоматическое уведомление об этом.
2. В приложении можно запустить процедуру изменения взломанного пароля на затронутом веб-сайте или сервисе.
3. Keeper отслеживает историю разрешенных проблем с каждым взломанным паролем для проведения аудита истории.

Демонстрационное видео

Посмотрите видео о работе BreachWatch iOS:

BreachWatch также доступен в Web-хранилище Keeper и приложении для настольных компьютеров:

Архитектура безопасности BreachWatch

Обзор системы безопасности

BreachWatch основан на архитектуре с нулевым разглашением, использующей несколько уровней для защиты информации наших пользователей. Коротко о работе BreachWatch:

1. Для сравнения паролей с информацией из базы данных взломанных учетных записей используются безопасная криптографическая функция хэширования с ключом и обезличивание (описано ниже).

2. Перед проверкой на совпадение со взломанными паролями или сохранением на серверах BreachWatch пароли пользователей защищаются аппаратным модулем безопасности (HSM) и неэкспортируемым секретным ключом.

3. Пользователи Keeper взаимодействуют с BreachWatch, используя обезличенные идентификаторы BreachWatch, не связанные с другими идентификаторами пользователей Keeper.

4. BreachWatch распределяет имена пользователей и пароли по отдельным службам с помощью разных обезличенных идентификаторов, чтобы имена пользователей и домены не были связаны с паролями.

5. Пользователи BreachWatch никогда не загружают информацию о доменах, а только скачивают ее (самый безопасный способ извлечения личной информации).

Рисунок 1. Путь хэшированных данных паролей пользователей через BreachWatch. На серверах BreachWatch хранятся только пароли, защищенные модулями HSM и неэкспортируемым ключом. При взаимодействии с серверами BreachWatch пользователи используют обезличенные идентификаторы.

Безопасное определение взломанных учетных записей

Конфиденциально сравнивать учетные данные клиентов с большой базой данных взломанной информации технически сложно. Решение должно одновременно обеспечивать безопасность и производить эффективные вычисления с учетом имеющихся ресурсов, включая вычислительную мощность и пропускную способность. В целом, это конкретный пример задачи пересечения частных наборов данных или задачи извлечения личной информации. Пользователи Keeper имеют локальную базу данных доменных имен, имен пользователей и паролей. BreachWatch обладает большой базой данных аналогичных элементов. Важнейшим требованием нашего решения является модель безопасности, которая может определить, какие пароли уязвимы, не предоставляя эту информацию службе BreachWatch.

Самое простое решение проблемы извлечения личной информации заключается в том, что клиентское приложение скачивает набор данных и выполняет сравнение локально. Это вполне осуществимо для сравнения доменов (данных немного), однако набор взломанных имен пользователей и паролей составляет более миллиарда точек данных. Передача такого объема информации непосредственно на устройства пользователя было бы нецелесообразна, да и невозможна.

Такие методы, как зашифрованные фильтры Блума [1], позволяют уменьшить размер скачиваемых данных и при этом продолжить обработку на стороне клиента, чтобы сохранить высочайший уровень безопасности информации. Однако размер фильтров Блума, созданных на основе наборов данных такого объема, все равно слишком велик для большинства клиентских устройств. Кроме того, фильтр Блума необходимо обновлять каждую неделю по мере обновления базы данных о взломах и утечках.

Некоторые системы используют k-анонимность [2], применяя усеченные, незащищенные хэши паролей, но такой способ небезопасен. Если описывать этот процесс кратко, то вместо загрузки паролей (или хэшей паролей) на сервер для проверки, клиенты загружают на него усеченный хэш каждого пароля (скажем, первые 20 разрядов). Этот усеченный хэш будет соответствовать несколько большему набору паролей, которые скачиваются и проверяются на клиентском устройстве. Недостаток такого подхода заключается в его неоднозначности для сервера (или злоумышленника), что связано с размером скачиваемого набора. Так, если клиент скачает 100 паролей для каждого загруженного усеченного хэша, то если усеченный хэш клиента будет раскрыт или украден с сервера, то у злоумышленника будет всего 100 различных паролей, которые необходимо проверить. Если злоумышленник может проверять 5 паролей в день без блокировки учетной записи, то он сможет получить доступ к ней за 20 дней.

Рисунок 2. Домены пользователей проверяются локально. Это самый безопасный в отрасли способ извлечения личной информации.

Решение BreachWatch

Для создания безопасного сервиса Keeper разделил BreachWatch на три службы, по одной для проверки доменов, имен пользователей и паролей. Клиентские приложения Keeper связываются с каждой из этих внутренних служб с помощью зашифрованного API REST.

Проверка доменов

Проверка доменов является самым простым решением из трех проводимых нами проверок. Пользователи BreachWatch скачивают список взломанных доменов и осуществляют локальную проверку. Это самое простое и безопасное решение проблемы извлечения личной информации. Периодически клиенты скачивают обновленные списки с новыми доменами по мере их добавления в нашу службу BreachWatch.

Имя пользователя и пароль

Службы проверки имен пользователей и паролей представляют большую сложность, поскольку их наборы данных очень велики. Мы должны проверять имена пользователей и пароли в автономном режиме, чтобы предупреждать клиентов в случае новых взломов учетных записей. Для этих служб клиентское устройство соединяется с BreachWatch и загружает список хэшированных имен пользователей (или паролей) наряду со случайно выбранным клиентом идентификатором (службам проверки имен пользователей и паролей назначаются разные идентификаторы). При загрузке эти хэши паролей обрабатываются с помощью HMAC [3], аппаратного модуля безопасности (HSM) и секретного ключа, хранящегося в HSM и помеченного как неэкспортируемый. HSM обрабатывает HMAC только локально, и ключ невозможно извлечь. Эти данные, полученные от HMAC (имена пользователей или пароли), сравниваются с данными из баз данных взломанных учетных записей, которые были обработаны с помощью тех же HMAC и ключа. Обо всех совпадениях сообщается на клиентское устройство. Любые несовпадающие значения сохраняются вместе с обезличенным идентификатором клиента.

По мере добавления в систему новых взломанных имен пользователей и паролей они обрабатываются с помощью HMAC в HSM, добавляются в набор данных BreachWatch и сравниваются с сохраненными значениями клиента. При обнаружении совпадения отправляется оповещение для соответствующего идентификатора клиента.

Клиентские устройства периодически обращаются к BreachWatch, сообщая свои идентификаторы BreachWatch. Все сообщения, поставленные в очередь, скачиваются, а клиентские устройства загружают новые или измененные имена пользователей и пароли, которые обрабатываются тем же образом.

Безопасность служб BreachWatch обеспечивается по принципу доверия при первом использовании (TOFU). Другими словами, клиентские устройства должны допускать, что сервер BreachWatch не является вредоносным (то есть, не скомпрометирован злоумышленником), когда они загружают хэшированные данные. После обработки этих значений с помощью HSM они становятся защищенными от взлома в автономном режиме. Иначе говоря, если злоумышленник украдет набор данных хранимых клиентских значений, он не сможет взломать эти данные в автономном режиме без ключа HMAC, хранящегося в HSM.

Самое безопасное в отрасли решение

BreachWatch от Keeper позволяет клиентам определять учетные записи, подверженные риску из-за взлома паролей, а также получать оповещения о них. Выполнить такую проверку в среде с нулевым разглашением чрезвычайно сложно, но для специалистов Keeper безопасность клиентов превыше всего.

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

Частые вопросы

Контакты

Если у вас есть вопросы о службе BreachWatch от Keeper или инфраструктуре безопасности, свяжитесь с нашей службой безопасности по адресу security@keepersecurity.com. Keeper Security поддерживает общедоступную программу раскрытия уязвимостей в партнерстве с платформой Bugcrowd, доступной по адресу https://bugcrowd.com/keepersecurity.

Ссылки

[1] Privacy-Enhanced Searches Using Encrypted Bloom Filters (Поиск с повышенной конфиденциальностью с использованием зашифрованных фильтров Блума). https://mice.cs.columbia.edu/getTechreport.php?techreportID=483

[2] https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/

[3] HMAC. https://cseweb.ucsd.edu/~mihir/papers/kmd5.pdf