Пассворк сравнил себя с ОднимКлючом. Что пошло не так?

Недавно на сайте Пассворка вышла статья, в которой они сравнили свой продукт с нашим менеджером паролей ОдинКлюч.

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

Давайте разбирать детали, но сначала отмечу, что…

…разбор был полезен!

Если раньше мы видели, как коллеги по рынку добавляли в свой продукт функции, изначально реализованные у нас, например схему Шамира, десктопное приложение с офлайн-кешем и другие возможности, то теперь уже специалисты Пассворка подсветили для нас ряд интересных направлений для развития продукта. Через несколько дней после публикации обзора мы уже выпустили крупное обновление, в котором, в частности:

• переработанная авторизация;

• дополнительная защита отображения форматированного текста;

• расширенные параметры управления кешем;

• новые групповые политики;

• усиленные серверные проверки политик безопасности и прав доступа;

• изменение правил хранения хешей.

А что, собственно, сравнивали?

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

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

Несколько замечаний по существу

1. Единый мастер-пароль — это ещё и единая точка компрометации

Пассворк представляет единый мастер-пароль как преимущество. Но если злоумышленник получает его и соответствующие зашифрованные ключи, под угрозой оказываются все доступные пользователю сейфы. В ОдномКлюче используются независимые секреты хранилищ, что позволяет ограничить последствия компрометации.

2. В схеме Шамира важно, что именно разделяется

В статье неверно описан механизм восстановления доступа в ОдномКлюче: на части разделяется не мастер-пароль, как утверждается в статье, а закрытый ключ восстановления. Это разные сущности и разные сценарии использования. Схема позволяет распределить части ключа между несколькими ответственными сотрудниками, чтобы восстановление требовало участия нескольких из них.

3. 300 000 против 1 000 итераций — не вся картина

Сравнение 300 000 и 1 000 итераций PBKDF2 эффектно выглядит в таблице. Но количество итераций само по себе не позволяет сделать вывод о стойкости всей системы. Нужно учитывать хеш-функцию, параметры реализации и стойкость самого мастер-пароля. Иначе получается сравнение одной цифры вместо оценки комплексного механизма защиты.

4. AES-256 против ГОСТ: не всё измеряется одной шкалой

При оценке криптографической защиты в статье использовались разные стандарты: ГОСТ 34.12–2018 для ОдногоКлюча и AES-256 для Пассворка.

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

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

5. Проверка паролей на компрометацию — это функция защиты, а не только риск

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

6. Возможность — не обязательная настройка

Некоторые сценарии упрощённого доступа в ОдномКлюче представлены как недостатки безопасности. Например, возможность проверять пароли на компрометацию в статье рассматривается преимущественно как недостаток из-за особенностей хранения хешей. У этого механизма есть вполне конкретная защитная задача — помогать организациям выявлять использование известных скомпрометированных паролей. При этом администратор может самостоятельно определить, нужен ли ей такой механизм с учётом собственной модели угроз. 

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

7. Фрагменты нужны, чтобы делиться, но ими не поделились 

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

Что в итоге?

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

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

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