Тонкости passkeys. Разбираем сильные и слабые стороны нового способа аутентификации

Не будем здесь дол­го раз­гла­голь­ство­вать о том, что такое passkeys и почему они кру­че паролей, — этой темой уже занялись мно­гие ре­сур­сы весь­ма под­робно.

Вмес­то это­го заг­лянем под капот и раз­берем­ся в крип­тогра­фичес­ких механиз­мах, сто­ящих за passkeys: какие гаран­тии они дают или не дают и что инте­рес­ного мож­но с этим сде­лать, нап­ример как соз­давать крип­тогра­фичес­кие клю­чи и хра­нить сер­тифика­ты.

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

Основы

Passkeys — это, по сути, пара крип­тогра­фичес­ких клю­чей: один пуб­личный (откры­тый), дру­гой при­ват­ный (сек­ретный).

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

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

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

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

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

Веб-аутентификация (WebAuthn)

WebAuthn — это осно­ва тех­нологии passkeys. Если по‑прос­тому, то это работа­ет так: ты заходишь на сайт (он же — relying party) через бра­узер (в роли WebAuthn user agent), исполь­зуя любое устрой­ство — ноут­бук, смар­тфон или ПК. Бра­узер обща­ется с аутен­тифика­тором — желез­кой или прог­раммой, которая генерит клю­чевую пару для passkeys и соз­дает циф­ровые под­писи с ее помощью.

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

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

Вза­имо­дей­ствие меж­ду бра­узе­ром и устрой­ством аутен­тифика­ции опи­сано под­робнее в дру­гой спе­цифи­кации — про­токо­ле Client to Authenticator Protocol (CTAP) от FIDO Alliance. Мы сей­час упро­щаем для ясности; спе­цифи­кация WebAuthn пре­дос­тавля­ет боль­ше вари­антов исполь­зования (нап­ример, все может про­исхо­дить в мобиль­ном при­ложе­нии вмес­то сай­та или бра­узе­ра). Но эти детали для обще­го понима­ния механиз­ма не так важ­ны.

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

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

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

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

Виды аутентификаторов

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

Су­щес­тву­ет два основных типа аутен­тифика­торов:

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

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

Не­кото­рые аутен­тифика­торы показы­вают тебе детали зап­роса, для которо­го они генери­руют циф­ровую под­пись. Если же аутен­тифика­тор не может это­го сде­лать, бра­узер отоб­разит эти дан­ные за него. Всег­да про­веряй эту информа­цию, преж­де чем одоб­рять зап­рос на аутен­тифика­цию.

Хранение ключей

Ког­да юзер регис­три­рует­ся на сай­те с помощью passkeys, аутен­тифика­тор соз­дает ключ и иден­тифика­тор (так называ­емый credential ID). Сайт хра­нит пуб­личный ключ и иден­тифика­тор, свя­зывая их с акка­унтом поль­зовате­ля. Таким обра­зом, сайт может исполь­зовать иден­тифика­тор, что­бы сооб­щить аутен­тифика­торам, какой имен­но ключ они хотят дос­тавить.

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

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

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

Доверие к устройствам

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

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

Од­нако аттеста­ция не обя­затель­на: спе­цифи­кация WebAuthn не тре­бует от аутен­тифика­торов под­дер­жки этой фун­кции.

Потеря доступа

Что делать, если ты потерял свой аутен­тифика­тор или он сло­мал­ся? Со все­ми клю­чами, которы­ми он управлял, мож­но рас­про­щать­ся. Пос­коль­ку это слу­чай­но сге­нери­рован­ные крип­тогра­фичес­кие пары, вер­нуть их уже не получит­ся.

Боль­шинс­тво плат­формен­ных аутен­тифика­торов типа iCloud Keychain, Google Password Manager и 1Password дают воз­можность залить клю­чи в обла­ко. Но это, конеч­но, ком­про­мисс: вос­ста­нови­мые клю­чи име­ют боль­шую зону рис­ка, ведь зло­умыш­ленни­ки могут попытать­ся ста­щить их через механизм вос­ста­нов­ления.

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

Другие риски

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

Модель угроз

Passkeys — это, конеч­но, не уни­вер­саль­ное решение для безопас­ности. Давай раз­берем­ся, от чего они дей­стви­тель­но защища­ют.

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

Но это нем­ного упро­щен­ная кар­тина. Вот нес­коль­ко впол­не реаль­ных атак, которые все еще могут про­изой­ти:

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

Passkeys — шту­ка клас­сная, но они не спа­сут, если на твой девайс уже попала мал­варь или спай­варь. Зато они работа­ют как неп­лохие огра­ничи­тели ата­ки — каж­дый раз, ког­да зло­умыш­ленник захочет что‑то под­писать, пот­ребу­ется отдель­ное вза­имо­дей­ствие поль­зовате­ля с аутен­тифика­тором. Кро­ме того, клю­чи дос­тупа не защища­ют от зло­умыш­ленни­ков, которые могут кон­тро­лиро­вать домен сай­та.

Еще одна тон­кость, которую сто­ит учесть вла­дель­цам сай­тов, — это кол­лизии ID учет­ных записей. Спе­цифи­кация тре­бует, что­бы они были ве­роят­нос­тно уни­каль­ными. Это зна­чит, что они генери­руют­ся слу­чай­но с очень малень­ким, но все‑таки не нулевым шан­сом на дуб­лирова­ние, как это быва­ет с UUID.

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

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

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

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

Расширения

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

В спе­цифи­кации WebAuthn перечис­лены стан­дар­тные рас­ширения, а за допол­нитель­ными мож­но обра­тить­ся к спе­циаль­ному реес­тру IANA. Рас­ширения быва­ют раз­ные: одни нуж­ны для сов­мести­мос­ти со ста­рыми сис­темами, дру­гие добав­ляют новые крип­товоз­можнос­ти. Мы погово­рим имен­но про вто­рую груп­пу.

Псевдорандомная функция (PRF)

Од­на из таких фич — это PRF. Она соз­дана на базе рас­ширения hmac-secret, как написа­но в FIDO CTAP v2.1. С помощью рас­ширения PRF твой аутен­тифика­тор может рас­счи­тывать HMAC-SHA-256, исполь­зуя фик­сирован­ный, слу­чай­но сге­нери­рован­ный 32-бай­товый ключ HMAC. Для это­го он берет хеш SHA-256 от заранее опре­делен­ного пре­фик­са WebAuthn и добав­ляет вход­ные дан­ные с сай­та.

Хо­тя эта фича недос­таточ­но гиб­кая, что­бы раз­вернуть что‑то вро­де HKDF (HMAC-based Key Derivation Function), ее мож­но исполь­зовать, что­бы реали­зовать HKDF Extract — получе­ние стой­кого клю­ча из нес­табиль­ного источни­ка.

Large Blob

Еще одно такое рас­ширение называ­ется Large Blob и поз­воля­ет аутен­тифика­торам хра­нить блоб неп­розрач­ных дан­ных, которые сайт спо­собен читать или записы­вать во вре­мя про­вер­ки под­линнос­ти. Сайт мо­жет исполь­зовать это для хра­нения любых (в том чис­ле чувс­тви­тель­ных) дан­ных, таких как сер­тифика­ты или крип­тогра­фичес­кие клю­чи.

Потенциальные проблемы

Дос­тичь истинной сквоз­ной безопас­ности в бра­узе­ре край­не слож­но, а зачас­тую невоз­можно. Ведь веб‑крип­тогра­фия работа­ет на JavaScript, который заг­ружа­ется с сер­вера, и это зна­чит, что зло­наме­рен­ный сер­вер может отпра­вить вре­донос­ный JavaScript, который вытас­кива­ет клю­чи, отправ­ляет рас­шифро­ван­ные сооб­щения обратно сер­веру и так далее.

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

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

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

Выводы

Сей­час самое вре­мя перехо­дить на passkeys. Их крип­тогра­фичес­кая осно­ва дает хорошие гаран­тии безопас­ности, так что это отличный выбор для сов­ремен­ных сис­тем аутен­тифика­ции — естес­твен­но, при пра­виль­ной реали­зации с исполь­зовани­ем WebAuthn.

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

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

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

Passkeys могут быть и пер­вым фак­тором аутен­тифика­ции, и вто­рым, и даже нес­коль­кими сра­зу. Но раз­работ­чикам сто­ит учи­тывать их в рам­ках общей мо­дели угроз.

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