Блог «Тропа битов». Криптография, лежащая в основе паролей.

Йооп ван де Пол. 14 мая 2025 г. криптография

Когда большинство людей думают о криптографии, первое, о чем они обычно думают, это шифрование: сохранение конфиденциальности информации. Но не менее важна (если не более) подлинность: обеспечение того, что информация действительно исходит из подлинного источника. Когда вы посещаете веб-сайт, сервер обычно подтверждает свою подлинность с помощью сертификата Transport Layer Security (TLS), аутентифицированного инфраструктурой открытых ключей Web (PKI). Пароли являются традиционным решением для аутентификации пользователей, но они страдают от фишинговых атак и утечек данных. Вот тут-то и появляются пароли.

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

Основы криптографии паролей

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

С точки зрения криптографии это довольно просто. Закрытый ключ аутентифицирует пользователя, но никакая конфиденциальная информация, полезная для злоумышленника, не передается на сервер. Если вызов сервера сгенерирован правильно — например, как равномерно случайная последовательность из 32 байтов — то он предотвратит атаки повторного воспроизведения. Поскольку сервер хранит только открытый ключ, а пользователь не отправляет ему конфиденциальную информацию, утечки в случае взлома не будет. Но одних только цифровых подписей недостаточно для решения проблемы фишинга. Если бы мы остановились только на криптографических примитивах, пользователи все равно были бы уязвимы. Например, без дополнительных мер безопасности злоумышленник может обманом заставить пользователей подписывать вызовы для неправильного веб-сайта или повторно использовать одну и ту же пару ключей на нескольких сайтах. Вот почему пароли построены на спецификации W3C WebAuthn , которая добавляет важные свойства безопасности за пределы базовой криптографии. Давайте посмотрим, как WebAuthn преобразует эти простые криптографические примитивы в систему аутентификации, устойчивую к фишингу.

WebAuthn

WebAuthn — это основная спецификация, лежащая в основе паролей. Проще говоря, пользователи получают доступ к веб-сайту (проверяющая сторона) через свой браузер (пользовательский агент WebAuthn) на устройстве , таком как ноутбук, телефон или ПК (клиентское устройство). Браузер взаимодействует с аутентификатором , частью оборудования или программного обеспечения, которое генерирует пару паролей и создает цифровые подписи с использованием этой пары ключей.

На схеме выше вы можете увидеть, как работает аутентификация с помощью ключа доступа:

1. Сайт запрашивает аутентификацию через браузер.
2. Браузер взаимодействует с аутентификатором.
3. Аутентификатор проверяет учетные данные и присутствие пользователя.
4. Аутентификатор возвращает подписанный ответ.
5. Браузер пересылает этот ответ на сайт для проверки.

(Это взаимодействие между браузером и аутентификатором более подробно описано в другой спецификации: Client to Authenticator Protocol (CTAP) FIDO Alliance.) Это упрощенное описание; спецификация WebAuthn допускает более широкий спектр вариантов использования (например, все может работать через мобильное приложение, а не через веб-сайт/браузер). Однако эти особенности не имеют отношения к пониманию того, как пароли работают с криптографией.

Защита от фишинга

WebAuthn решает проблему фишинга посредством привязки к источнику. Спецификация требует, чтобы браузеры предоставляли источник запроса (т. е. домен веб-сайта) аутентификатору. Аутентификатор, в свою очередь, использует ключи доступа только тогда, когда веб-сайт, делающий запрос, совпадает с веб-сайтом, создавшим ключ доступа. Это означает, что если вы создадите ключ доступа для bank.com, фишинговый сайт fake-bank.com просто не сможет его использовать — ваш аутентификатор отклонит запрос. Каждый веб-сайт также получает свою собственную уникальную пару ключей, что полностью устраняет проблему повторного использования пароля. Кроме того, спецификация допускает только источники, использующие HTTPS, что означает, что запрос поступает с сервера, имеющего действительный сертификат для соответствующего источника.

Типы аутентификаторов

Как правило, аутентификаторы — это «что-то, что у вас есть». Все аутентификаторы могут проверить, присутствует ли пользователь на самом деле при аутентификации. Некоторые аутентификаторы могут дополнительно проверить пользователя по «чему-то, что они знают», например, по PIN-коду, или «чему-то, чем он является», например, по его биометрическим данным.

Существует два основных типа аутентификаторов, с которыми вы столкнетесь:

• Аутентификаторы платформы : они находятся внутри самого пользовательского устройства.
  • Примеры: iCloud Keychain, Google Password Manager, Windows Hello, 1Password
  • Плюсы: Удобно, часто есть возможность резервного копирования в облако.
  • Минусы: уязвимо, если само устройство скомпрометировано.
• Аутентификаторы роуминга : это отдельные специализированные аппаратные устройства.
  • Примеры: YubiKeys, Titan Security Keys, Feitian Keys
  • Плюсы: более высокая степень изоляции безопасности, не подверженность взлому устройства
  • Минусы: могут быть утеряны или повреждены, обычно нет резервного механизма.

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

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

Теоретически вы можете просто сохранить пару криптографических ключей в файле, написать вокруг него программное обеспечение, которое использует эту пару ключей для криптографических операций, и сделать вид, что это аутентификатор. Но как веб-сайты могут узнать, используют ли его пользователи безопасные аутентификаторы? Аутентификаторы могут криптографически доказать определенные факты о своем происхождении, например, кто его изготовил, генерируя заявление об аттестации, когда пользователь создает ключ доступа; это заявление подкрепляется цепочкой сертификатов, подписанной производителем. Это особенно полезно для корпоративных пользователей, поскольку позволяет предприятию гарантировать, что у всех пользователей есть определенные аутентификаторы, которые соответствуют некоторым требованиям безопасности. Однако аттестация необязательна: спецификация WebAuthn не требует, чтобы аутентификаторы ее поддерживали.

Наконец, как и в случае с любым фактором аутентификации, который является «чем-то, что у вас есть», важным вопросом является то, что произойдет, если вы его потеряете или он сломается? Вообще говоря, потеря аутентификатора означает потерю всех контролируемых им паролей. Поскольку пароли по сути являются случайно сгенерированными парами криптографических ключей, надежды на восстановление действительно нет. Большинство платформенных аутентификаторов, таких как iCloud Keychain, Google Password Manager и 1Password, позволяют создавать резервные копии паролей, синхронизируя их с облаком. Однако это всегда компромисс: пароли, которые можно восстановить, имеют большую поверхность атаки, поскольку злоумышленники могут попытаться получить пароль через механизм восстановления. В целом важно, чтобы на веб-сайтах был механизм восстановления на случай, если пользователи потеряют доступ к своим паролям, при этом следует помнить, что злоумышленники могут вместо этого нацелиться на этот механизм восстановления. Хотя использование аутентификаторов платформы с возможностями резервного копирования снижает риск потери паролей, оно не устраняет его полностью. Пользователи, которых забанили на платформе, потеряют доступ к своим паролям, а платформа может случайно удалить их. Кроме того, платформы также могут поддерживать совместное использование паролей или семейные учетные записи, где несколько пользователей могут получить доступ к одним и тем же паролям. Веб-сайт должен предупреждать пользователей об этих рисках в зависимости от того, какой доступ предоставляет пароль.

Модель угрозы

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

Модель угроз паролей показывает, что они защищают от угроз, от которых обычно защищают пароли, а также устраняют риск фишинга и повторного использования паролей. Это значительное улучшение! Раздел «Соответствие» спецификации WebAuthn делает очень сильное заявление, подразумевающее, что веб-сайты, браузеры и аутентификаторы, соответствующие спецификации, «защищены» от вредоносного поведения.

Это утверждение слишком упрощает реальность безопасности. Вот реальные сценарии атак, которые все еще могут произойти:

• Атаки на основе браузера : некоторые аутентификаторы (например, YubiKey 5C) не имеют встроенного дисплея и полностью полагаются на браузер, чтобы показать пользователям, на каком сайте они аутентифицируются. Если ваш браузер скомпрометирован вредоносным ПО или вредоносным расширением, он может отображать вам «attacker.com», в то время как на самом деле отправляет вашему аутентификатору запрос на подпись для «google.com».
• Скомпрометированные аутентификаторы : безопасность паролей зависит от аутентификатора, защищающего закрытые ключи. Поддельный аппаратный ключ, бэкдор-аутентификатор или вредоносное ПО, которое выдает себя за встроенный аутентификатор вашей ОС, могут тайно извлечь ваши закрытые ключи. Подумайте о покупке того, что выглядит как YubiKey, из ненадежного источника — он может отправлять копии ваших ключей кому-то другому.

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

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

Это может показаться неправдоподобным, но рассмотрим следующие сценарии:

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

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

Расширения

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

Спецификация WebAuthn перечисляет некоторые определенные расширения и ссылки на реестр Internet Assigned Numbers Authority (IANA) для определений большего количества расширений. Эти расширения варьируются от обеспечения обратной совместимости со старыми API до поддержки совершенно других криптографических функций. Поскольку эта запись в блоге посвящена криптографии, эти последние расширения наиболее интересны. Одним из таких расширений является то, которое спецификация WebAuthn называет prf (для семейства псевдослучайных функций), которое построено поверх hmac-secretрасширения, определенного в спецификации FIDO CTAP v2.1. С prfрасширением аутентификатор может вычислять HMAC-SHA-256, используя фиксированный случайно сгенерированный 32-байтовый ключ HMAC. Входными данными для вычисления HMAC являются дайджест SHA-256 фиксированного префикса WebAuthn, за которым следуют входные данные, предоставленные веб-сайтом. Хотя это расширение недостаточно гибко для реализации чего-то вроде HKDF, его можно использовать для реализации HKDF Extract ² .

Другое такое расширение называется largeBlobи предлагает поддерживающим аутентификаторам хранить «большой блок» непрозрачных данных, которые веб-сайт может читать или записывать во время утверждений аутентификации. Веб-сайт может использовать это для хранения любых (конфиденциальных) данных, таких как сертификаты или криптографические ключи . Таким образом, используя эти расширения, можно выводить или хранить статические криптографические ключи. Как предлагается в largeBlobпримере, вы даже можете использовать это для сквозного шифрования. Однако, как и во всех приложениях криптографии в настройках браузера, крайне сложно, если не невозможно, достичь настоящей сквозной безопасности. Обычно для этого требуется, чтобы система была устойчива к вредоносному серверу. Веб-криптография работает на JavaScript, обслуживаемом сервером, что означает, что вредоносный сервер может просто обслуживать вредоносный JavaScript, который извлекает ключи, отправляет расшифрованные сообщения обратно на сервер и т. д. Хуже того, вредоносный сервер может делать это в узконаправленной манере, обслуживая правильный JavaScript для большинства пользователей, но вредоносный JavaScript для конкретного целевого пользователя. Реализация целостности подресурсов для кода в Интернете (например, хранение хеша всех опубликованных версий с доверенной третьей стороной ) и методы двоичной прозрачности (например, публично проверяемый, защищенный от несанкционированного доступа журнал) являются двумя многообещающими решениями такого рода проблем. Кроме того, важно отметить, что спецификация считает все расширения необязательными, что означает, что нет гарантии, что браузеры и аутентификаторы поддерживают их. Веб-сайтам необходимо проверять наличие расширений при запросе определенных расширений, иначе у пользователей возникнут проблемы с доступом к их сервисам. В будущем, как мы надеемся, все основные браузеры и аутентификаторы будут поддерживать их, что может улучшить управление ключами для криптографии в Интернете.

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

Путь вперед для паролей

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

Вот наш совет пользователям и разработчикам:

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

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

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

---

1. Смартфоны часто также поддерживают так называемый « гибридный транспорт », когда телефон взаимодействует с браузером через WebSockets, при этом отдельно подтверждая свою физическую близость к браузеру через Bluetooth Low Energy.  ↩︎
2. Параметр соли HKDF Extract будет случайно сгенерированным 32-байтовым ключом учетных данных, а входной ключевой материал будет дайджестом SHA-256. Полученное значение можно использовать в качестве псевдослучайного ключа для HKDF Expand. Не рекомендуется генерировать более одного псевдослучайного ключа на ключ доступа таким образом. Вместо этого можно вывести несколько ключей из одного псевдослучайного ключа, изменяя параметр информации HKDF Expand.  ↩︎

источник: https://blog.trailofbits.com/2025/05/14/the-cryptography-behind-passkeys/?utm_source=www.vulnu.com&utm_medium=newsletter&utm_campaign=vulnerable-u-116

О НАС

С 2012 года Trail of Bits помог защитить некоторые из наиболее целевых организаций и продуктов в мире. Мы объединяем передовые исследования безопасности с менталитетом реального злоумышленника, чтобы снизить риск и укрепить код.

Подробнее читайте на сайте: www.trailofbits.com