passkeys, WebAuthn

https://habr.com/ru/companies/globalsign/articles/745376/
http://srp.stanford.edu/analysis.html
https://sec.okta.com/articles/2020/04/webauthn-great-and-it-sucks/
https://blog.mozilla.org/en/mozilla/password-security-part-iv-webauthn/
Статья-обзор о том, что такое passkeys от Google, с точки зрения
пользователя.

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

Вот самое простое объяснение методов аутентификации я встретил (хотя,
может быть это в какой-нибудь из книг Брюса Шнайера наверняка было) в
статье про Secure Remote Password. Всё банально: есть три фактора. То
что ты знаешь (пароль, PIN), то что имеешь (ключ), что чем являешься
(биометрия). Первое приятно удобством, неприятно что не все могут
осилить парольные фразы. Второе приятно тем, что можно асимметрично
вынести куда-нибудь, имеет хорошую силу (длина ключа), но неприятно тем,
что это нужно с собой таскать, можно потерять, сломать или украсть, да и
дорого, особенно если из-за приватности использовать отдельный "токен"
для каждого сервиса. Третье приятно удобством, но имеет низкую энтропию
в общем случае, невозможно сменить, может "утечь". Биометрия только как
дополнительный фактор может использоваться, точка, но не как
единственный фактор аутентификации.

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

И вот это всё как-раз таки не правда. Во-первых, собственно, есть
сильные пароли аутентификации, где MitM ничего не может сделать для
подбора пароля. Например PAKE (password authenticated key agreement)
принципиально очень прост: обмениваемся публичными ключами
Диффи-Хеллмана, но симметрично зашифрованными на пароле. Однако, при
этом применяем преобразование к DH, которое сделает DH ключи
неотличимыми от шума: например Elligator2 алгоритм к curve25519 ключам
(но только половина ключей может быть преобразована им). Злоумышленник
может дешифровывать перехваченный handshake, перебирая пароли в качестве
ключа, но у него ни бита информации не будет о том, успешно ли он
дешифровал пакет, ибо elligator-encoded curve25519 неотличим от шума.

Во-вторых, есть augmented алгоритмы, где на стороне сервера не хранится
пароль/ключ/общий секрет, а хранится некий verifier. Так вообще пароль
остаётся только на стороне клиента, не сливая даже серверу ни бита
информации о нём.

И PAKE-related протоколов десятки наизобретали, даже SESPAKE есть
стандартизованный с ГОСТовыми криптоалгоритмами. В США кстати, насколько
помню, нет стандартизованного PAKE никакого.

Да, на практике всё это мало где используется (корпорациям насрать на
нашу безопасность то в общем-то, она должна быть просто is good enough),
но это уже другой вопрос. Но тот же SRP, даже для TLS делался в виде
TLS-SRP расширения. Не то чтобы SRP стоило применять
(da652bb554b907b2f96921255157bce56d24174f), но хоть такое решение в
GnuTLS уже было давным давно, вот только разработчики броузеров срать на
всё это хотели.

Статья про passkeys говорит о том, что ещё пошла тенденция на хранение
этих ключей в облаке. Ну это уже вообще за гранью разумного. То бишь,
это полная отдача аутентификатора компании. Но у нас облачные подписи
вообще штатный сервис (71d4d1391ad542b1c2ae9d8c976ac4f769303abc).

Но что меня бесит (хотя и не особо, это уже просто стало же нормой): что
вновь и вновь изобретают велосипед. Для TLS давным давно есть
возможность аутентификации через клиентский X.509 сертификат. И даже в
броузерах давно PKCS#11 поддерживается для общения с HSM. Не то чтобы
мне нравился TLS или, боже упаси, X.509 или, чур меня, PKCS#11, но они
решают эту же задачу, якобы о которой так заботятся корпорации. В блоге
Mozilla говорится что "предыдущие" методы аутентификации (поверх HTTP
или TLS) не годятся, ибо там нельзя управлять где и когда именно надо
запрашивать эту самую аутентификацию. Вот про TLS 1.2 (или ранние)
версию не знаю, но в TLS 1.3 в любой момент после handshake можно
запросить клиентский сертификат. Проще написать дофига-строчный
стандарт, требующий тьму зависимостей, нежели чем обеспечить адекватный
API между TLS-библиотекой и броузером? Ну ну.

И я просто уверен что где-то есть коммитет оценивающий соревнования по
созданию самых громоздких и монструозных "стандартов" даже для
относительно простых задач. Размер WebAuthn стандарта впечатляет, мягко
говоря. Почему стандарт в кавычках? Да потому что W3C стал некой
библиотекой документация к Chrome-движку по сути, ну возможно частично и
для Mozilla. Собственно, всё как с OAuth2
(ccb6418a3b4ac2abff304201f626607416e022df).

комментарий 0:

From: Sergey Matveev
Date: 2023-07-03 06:33:51Z

Вбросил на Hacker News (их больше не читаю, но ссылки иногда вбрасываю),
попало на главную: https://news.ycombinator.com/item?id=36565405