🔐SMS? TOTP? Всё х*йня! Только passkey...

Сегодня хочется отойти от темы обхода блокировок и сфокусироваться на мошенниках. Вернее на том как ИМЕННО нужно защищать государство граждан от мошенников. Вернее как должно.

СМС взламываются и перехватываются. TOTP сложён в обращении. Если Вы хотите пойти дальше и защитать важные аккаунты и информацию — вам просто обязательно нужно иметь passkey. Его не взломаешь, не подберёшь и удалённо не подсунешь.

Многие РФ приложения их поддерживают, но госуслуги например (почему-то) нет. Хотя выбор у пользователя должен быть. Это гораздо безопаснее чем самозапреты ведь ключ физически ПОЧТИ невозможно передать.

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

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

Общие правила этой системы развивает отраслевой альянс FIDO Alliance, а семейство его стандартов называют FIDO (Fast IDentity Online, «быстрая идентификация в сети»). История FIDO объясняет, почему производителям браузеров, операционных систем и аппаратных устройств понадобился единый язык. Там разобран путь от ранних экспериментов Google и Yubico до массовой поддержки в Android, iOS, браузерах и Windows, а также показано, почему пользовательский интерфейс менялся быстрее, чем основные криптографические гарантии.

Первое поколение разделяло два сценария. Физический ключ мог дополнять пароль вторым фактором: после обычного входа сервер просил коснуться устройства и проверить подпись. Этот стандарт называется U2F (Universal 2nd Factor, «универсальный второй фактор») и подробно разобран в отдельной статье. Параллельная ветка позволяла мобильному приложению заменить пароль локальным подтверждением владельца; её назвали UAF (Universal Authentication Framework, «универсальная платформа аутентификации»). Статья об UAF показывает архитектуру этой системы и причины, по которым она не стала единым интерфейсом массового веба.

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

Связь сайта с устройством разделена на два участка, потому что веб-страница не должна напрямую управлять USB-ключом, датчиком отпечатка или телефоном. Набор функций, через который страница просит браузер зарегистрировать ключ или начать вход, называется WebAuthn. Статья о WebAuthn разбирает запросы страницы, привязку подписи к адресу сайта, содержимое ответа и обязательные проверки на сервере. Отдельный протокол передаёт команды от браузера или операционной системы к внешнему аутентификатору; он называется CTAP. В статье о CTAP описаны команды создания и получения учётных данных, USB и бесконтактная связь, локальный PIN, биометрия, защита от перебора и управление памятью ключа. Вместе WebAuthn и CTAP2 образуют FIDO2.

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

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки