Да, именно так. Конечно, появились пароли, когда никакой индустрии информационной безопасности ещё и в планах не было, но это legacy мы тащим за собой уже несколько тысяч лет. Проблема с паролями в том, что придуманы они для людей, а для людей нет ничего более противоестественного, чем запоминать последовательности букв и цифр. И вот об этом мы сегодня вместе подумаем.
Пароли появились действительно давно, задолго до того, как возникла идея создавать умные машины для вычислений. В то время концепция «я знаю что-то» была вполне логичной. Два человека, дабы проверить друг друга, обладали одним и тем же секретом и, соответственно, могли убедиться, что перед ними тот, за кого он себя выдаёт.
На самом деле, уже тогда у этой концепции был изъян. Пароль можно забыть, но его же можно вытащить из человека с помощью угроз и пыток. Если задуматься, то до сих пор пароль — это единственный из факторов аутентификации, который можно отнять у человека. Причём не обязательно пользоваться силой. Человек добровольно отдаст вам всё, если вы воспользуетесь фишингом на базе страха или под предлогом срочности.
Фишинга тогда ещё не было, но уже вместо того чтобы заменить концепцию пароля на что-то другое, люди начали изобретать различные костыли. Это вообще в нашей природе: нам очень тяжело отказываться от того, во что уже вложены какие-то значительные силы и ресурсы. Это ещё называется «эффектом Конкорда», который является одним из самых популярных когнитивных искажений наряду с эффектом выжившего или феноменом Баадера — Майнхофа.
Китайцы сделали пароль из двух половинок, который хранился у двух разных людей, шифром Цезаря пароль можно было зашифровать, и всё в таком духе. Но по факту всё осталось, как было, — человек должен что-то запомнить. Сегодня мы точно знаем, что даже наши ближайшие родственники, шимпанзе, запоминают последовательности чисел лучше нас, но мы продолжаем использовать пароли, и, более того, эксперты в сфере информационной безопасности объясняют людям, что пароль должен быть длинным и сложным. Кажется, что нет ничего более отталкивающего. Хотя нет: есть ещё дизайн смартфонов, с которыми мы проводим половину своей жизни, в виде пластикового прямоугольника, под который наша кисть максимально не приспособлена. Но это тема для отдельного разговора.
Так вот, пароли. Это ведь не единственное legacy в мире ИТ и ИБ. У нас есть куча протоколов, которые были изобретены в 70-е годы, на которых держится весь Интернет и от которых мы не готовы отказаться, только потому что они устарели и вообще не предполагали каких-то настроек безопасности. Нет, мы от них не оказываемся, мы придумываем костыли.
Я по пальцам одной руки могу пересчитать те протоколы, от которых отказались вообще, — telnet, PPTP, SSL, WEP, кто ещё? В подавляющем большинстве случаев мы просто добавляем что-то в спецификацию протокола, чтобы сделать его безопаснее и чтобы тот стал соответствовать нашим современным представлениям о том, как всё должно быть устроено. Тут у инженеров карт-бланш — меняем протоколы, обновляем софт и пользователи ничего особо не заметят. Но как поставить апдейт на человеческий мозг?
Этим занялись умные люди в уже интернет-эпоху, предлагая различные креативные способы аутентификации для массового пользователя. И что вы думаете, какой вариант победил? Конечно же, костыль в виде 2FA. 2FA не решает проблему, а просто несколько усложняет жизнь как пользователю, так и атакующему. Запоминать пароль по-прежнему нужно, но к этому добавляется одноразовый пароль, который приходит к вам в SMS. И неважно, что уже скоро 10 лет как NIST не рекомендует использовать СМС для одноразовых паролей.
А потом появились явления MFA-fatigue и SIM-swap, и пароль остался самым слабым звеном всей цепочки. Сейчас отдельные сервисы начинают предлагать присылать одноразовые пароли в мессенджер. Напомните, пожалуйста, а в сам мессенджер вы как попадаете? Вот так. Задача стоит гораздо шире — убрать пароли как класс, забыть это слово и закопать как можно глубже. Перестать дрессировать пользователей требованиями придумывать сложные пароли, это никакого отношения к безопасности вообще не имеет. А всякие компенсирующие меры отправить в музей.
Идея избавиться от паролей возникла уже в 90-е. Само понятие общего секрета стала выглядеть в глазах экспертов крайне слабо. Появились хорошие алгоритмы и стратегии хеширования, но было понятно, что это подпорка. В 2014 году компании Google и Yubico предложили миру концепцию U2F, то есть универсального второго фактора для аутентификации. Это должно было решить проблемы существовавших тогда способов доставки одноразовых паролей — защита от MITM, никаких хранений и передачи в открытом виде чувствительных данных, защита от подслушивания. И хотя стандарт был принят, со временем появилась информация, что имеет место создать дубликат физического ключа, что несколько ломает всю лучезарную картину.
Более того, необходимость иметь отдельный физический объект для входа на сайт понравилась не всем, что, конечно, затормозило внедрение. Второй вехой стал FIDO2, ключевой идеей которого является то, что ассиметричный ключ уже является первым фактором аутентификации, а не какой-то добавкой к паролю. Стандарт уже поддерживал работу с широким спектром приложений, но всё же было довольно неочевиден в настройке и по-прежнему требовал физического ключа. Инженеры были на правильном пути, но нужен был массовый FIDO2, какой-то такой вариант для «магглов», который можно было бы использовать здесь и сейчас. Так и появились passkey. Он же ключ доступа, он же цифровой ключ, он же пасскей.
Важно сразу отметить, что это не какой-то новый протокол, а просто адаптированный под массовый рынок.
Основные фишки решения:
— аутентификация производится с помощью ассиметричной криптографии, т. е. пользователь не знает и не должен знать своего пароля, потому что его попросту нет, только ключевая пара;
— закрытый ключ хранится в защищённом хранилище, которым может выступать менеджер паролей, аккаунт того же Google или Microsoft или, в зависимости от уровня вашей паранойи, и аппаратный ключ;
— открытый ключ, соответственно, на сервере, на который вы пытаетесь попасть. Утекать он может хоть каждый день – секретом он не является;
— если это что-то виртуальное, то вам доступна синхронизация между устройствами;
— вход в защищённое хранилище опять же зависит от поставщика — биометрия или пин-код.
И никаких паролей. Ни длинных, ни коротких, ни слабых, никаких. Всё, закрыли тему.
Теперь давайте подробнее, как это работает. Магии никакой там нет, но я думаю, внимательные сразу заметят, на чём споткнётся внедрение технологии на этот раз. По-хорошему у нас есть всего два процесса, вокруг которых всё вертится. И первый из них — откуда Passkey вообще берётся на устройстве и на сервере? Кто его туда кладёт и почему его нельзя перехватить по пути? Тут всё давно просто, если вы примерно понимаете, как работает ассиметричное шифрование, и всю эту кухню про ключевые пары и алгоритмы. Реализация будет немного отличаться в зависимости от того, где вы решили хранить ключ и с каким сайтом или приложением планируете работать.
Сначала вы идёте на сайт или в приложение, находите раздел про свой аккаунт и безопасность. В нём должна быть кнопка вроде «создать passkey». Если её нет, увы, придётся работать как раньше. Если же всё ок, то нажимаем её и смотрим, что нам предлагают.
В это время сервер или приложение создаёт специальную случайную последовательность, или challenge, и добавляет к нему свои параметры — RP ID (обычно это dns-имя сайта), допустимые алгоритмы, политики и всё в таком ключе и отправляет это нам.
Наше устройство просит ещё раз подтвердить, что мы — это мы с помощью какого-нибудь faceid, touchid или пин-кода. Тут важно отметить, что никакая наша биометрия никуда не отправляется — всё происходит локально.
Затем наше устройство генерирует ключевую пару — закрытый ключ остаётся у нас, а открытый как раз пойдёт на сервер. Тут как раз начинает работать защита от фишинга — ключ привязывается к домену, т. е. конкретная пара валидна только для условного example.com и при попытке зайти на examp1e.com мы получим ошибку.
Наше устройство возвращает на сервер наш открытый ключ, а также наш id аккаунта и всякие метаданные на основе присланного challenge.
Сервер сохраняет это у себя, и на этом настройка завершена. Собственно, ни в какой момент времени мы не передавали по сети что-либо, что можно использовать для атаки. Да и утекать теперь в случае взлома тоже нечему. Отлично.
А вот и второй процесс — что происходит, когда мы пытаемся войти через passkey. Тут всё ещё проще.
В интерфейсе нашего сайта или приложения мы указываем, что входить будем через passkey.
Сервер снова выдает challenge и отправляет его нам вместе с идентификатором домена, а также списком ID, которые закреплены за нами в базе. Их может быть несколько, и это нормально.
Мы подтверждаем, что мы — это мы с помощью пина или биометрии, после чего клиент проверяет, что домен верный, и подписывает challenge своим приватным ключом. Заметим, что приватный ключ устройство не покидает ни при каких обстоятельствах в этом процессе.
Сервис получает эти данные, проверяет подпись нашим публичным ключом и заодно проверяет, верна ли подпись, верен ли домен, не выглядят ли подозрительно метаданные, и если всё ок, то даёт доступ.
Я попросил ChatGPT сгенерировать картинку того, как это всё происходит для наглядности. Получилось неплохо, если бы ещё не этот ключ с двумя ручками, но суть понятна.
Работает всё крайне просто, причём пользователь наконец избавлен от запоминания чего-либо.
Ну как, вы уже нашли изъяны в этой схеме? Они есть, и растут они из понимания того, что никто не стандартизует и не собирается метод хранения passkey в системе. У Google, Microsoft, Apple и прочих могут быть совершенно разные представления о прекрасном, а значит, на горизонте мы можем увидеть vendor lock-in и все прелести этой ситуации.
Зависимость от экосистем — это вообще бич 20 века, и в 21 веке она никуда не делась, несмотря на попытку стандартизации всего и вся. Потому что доверие к вендору может быть подорвано за один вечер, а как мигрировать куда-то в другое место, никто не понимает. И потом, что там с суверенитетом?
Вторая проблема, которая очевидна буквально сразу, — как быть с восстановлением в случае утери того же смартфона? Нужны дубликаты passkey в безопасном месте или оно как-то само туда попадёт?
Третий момент — обилие legacy вокруг не даст перейти на этот способ входа. Всевозможные встраиваемые системы не планируют подтягиваться за прогрессом, а значит, пароли всё еще с нами.
Четвёртый момент, про который уже начали писать пользователи, — потеря контроля. Пользователю спокойнее и понятнее, когда он знает этот пресловутый пароль и может его сменить. А passkey — это где? Как на него посмотреть? А он всё еще там? Ну и наконец, самое главное: passkey — это только аутентификация. Кроме этого, у нас есть проблемы с авторизацией, возможностью компрометации аккаунта, да и вообще раздачей прав внутри приложений и сервисов.
Passkey — это, безусловно, шаг вперёд, но совсем не конец истории.
Автор: Сергей Полунин, руководитель группы защиты инфраструктурных ИТ-решений компании «Газинформсервис»
