Да, именно так. Конечно, появились пароли, когда никакой индустрии информационной безопасности ещё и в планах не было, но это 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 — это, безусловно, шаг вперёд, но совсем не конец истории.
Автор: Сергей Полунин, руководитель группы защиты инфраструктурных ИТ-решений компании «Газинформсервис»
Комментарии (74)
HOMPAIN
18.12.2025 08:47Я считаю, что это наоборот гигантская дыра в личной безопасности. За пароль ты сам отвечаешь. С пасскеем от тебя ничего не зависит, тебе просто не дают шанса надёжно защитить себя и сохранить свои данные. Стоит злоумышленнику получить доступ к любому твоему устройству и у него есть всё.
Belowzero273 Автор
18.12.2025 08:47Я думаю, что тут скорее Вам не дают лишний раз выстрелить себе в ногу. Да и потом если вы потеряли доступ к устройству, скорее всего passkey - не самая главная ваша проблема теперь
CaptainFlint
18.12.2025 08:47Набор passkey'ев, которые давали доступ ко всем моим аккаунтам, ко всем банковским счетам, госуслугам и так далее? Позволю себе не согласиться, для меня это будет именно что самая главная проблема.
InfinityMe
18.12.2025 08:47Если у злоумышленника есть доступ к устройству то забрать пароли проще чем Passkey. Ну главное, у злоумышленника должно оказаться разблокированное устройство, иначе это просто набор запчастей.
xSVPx
18.12.2025 08:47И как же они заберут пароли, которые у меня в голове ? Я каждый день в госуслуги не логинюсь. А чем дольше ждать, тем больше шансов, что жертва поймет, что устройство скомпрометировано.
Tony-Sol
18.12.2025 08:47В контексте обсуждения про доступ к устройству - у вас нет приложений на телефоне, а все сервисы вы посещаете через инкогнито в браузере? если нет, то неважно что пароль у вас в голове
GidraVydra
18.12.2025 08:47О, а вот расскажите как это должно работать? Вот, есть у меня телефон, на нем стоит банковское приложение с доступом по паролю. Предположим, вы у меня вытащили телефон из кармана и получили к нему доступ, что несложно т.к. на нем нет блокировки экрана. Как вы будете доставать пароль от моего банковского приложения?
Tony-Sol
18.12.2025 08:47А зачем мне пароль как таковой если есть куки авторизации? Смысл то доступ к сервису получить, а не просто пароль узнать
GidraVydra
18.12.2025 08:47Ок, как вы будете получать доступ к сервису? Куки авторизации вам как в этом помогут?
Tony-Sol
18.12.2025 08:47Цель - получить доступ. Вы после использования банковского приложения нажимаете кнопку "выйти"? Если нет, а именно это я писал выше, то в памяти телефона остались куки с вашей последней авторизации и мне нет смысла узнавать пароль от самого банкинга, достаточно подобрать пароль от приложения - у приложения альфы например это 4 цифры, у сбера 5 (у других не знаю), есть куча софта для брутфорса таких паролей, начиная от самого примитивного (https://github.com/stevebalk/android_pin_brute_force) и заканчивая корпоративными решениями (https://cellebrite.com/en/products/guardian/guardian-forensics/).
Плюс, доступ к телефону = доступ к номеру, а значит "забыл пароль, код на сброс в sms" и подобные вещи реализуемы.
Конечно, можно сказать "а у меня на другой номер все" - ну значит тогда у вас с большей вероятностью или несколько sim в одном (и тогда нет никакой разницы) или не один телефон с собой, что поможет только в очень узком сценарии типа "у меня вытащили из кармана телефон, но не тот а-ха-ха"
Belibak
18.12.2025 08:47Все банковские приложения, которыми я пользовался, просят авторизовать снова, даже если его просто свернуть. Какие куки?
Tony-Sol
18.12.2025 08:47А вы не путаете пароль приложения и пароль сервиса? Приложение у вас прям просит логин/номер телефона/почту каждый раз после сворачивания?
GidraVydra
18.12.2025 08:47доступ к телефону = доступ к номеру, а значит "забыл пароль, код на сброс в sms" и подобные вещи реализуемы.
Ваш банк дает сбросить пароль по одному фактору (привязка к номеру телефона)? Сочувствую. Но даже если так - как пасскей защитит от подобного сценария? У вас у всех одна и та же логическая ошибка - вы упорно и, склрее всего, сознательно, приписываете общие уязвимости, присущие любому методу аутентификации, исключительно паролям.
достаточно подобрать пароль от приложения
Три неверных ввода - кулдаун 5-10 минут, 10 неверных вводов - кулдаун сутки или блокировка. Велкам, брутфорс. И, опять же, чем в данной ситуации поможет пасскей? То, что подбирать будут не пин-код от банковского приложения, а пинкод от хранилища?
Ну и у меня, например, основное банковское приложение закрыто на полноценный 12-символьный пароль, а не на пин-код.
Tony-Sol
18.12.2025 08:47как пасскей защитит от подобного сценария?
Так же как и пароль - никак
У вас у всех одна и та же логическая ошибка - вы упорно и, склрее всего, сознательно, приписываете общие уязвимости, присущие любому методу аутентификации, исключительно паролям
Да откуда вы это взяли? где я хоть раз это написал? У любого способа авторизации есть уязвимости, просто у паролей их больше - ниже уже писал об этом, что у случае пасскея/сертификатов (практически, но не теоретически) не работают например такие приемы как подбор и радужные списки. Это не повод не использовать пароли или не использовать пасскеи.
Вот 5 минут назад авторизовывался с ноутбука в chrome canary - он просит мой юбикей, мне было лень за ним идти и я вошел по паролю с двухфакторкой через телефон. В другом случае, у меня юбик будет в порту и мне будет лень идти за телефоном - войду по нему.
Три неверных ввода - кулдаун 5-10 минут, 10 неверных вводов - кулдаун сутки или блокировка. Велкам, брутфорс.
Сможете отдать свой телефон хакерам для проверки попытки взлома? а спецслужбам? я вот нет, несмотря на то что и пароли, и двухфакторки, и пасскеи - везде включено все что можно.
Ну и у меня, например, основное банковское приложение закрыто на полноценный 12-символьный пароль, а не на пин-код.
Ну правильно же, где я хоть слово против этого сказал?
xSVPx
18.12.2025 08:47Как приложения в телефоне позволят доступ к госуслугам то получить ? А доступ к хабру пусть забирают.
Смекаете о чём я?
И да, я не пользуюсь банковскими приложениями банков в которых у меня ощутимые суммы денег. И вам советую....
NeoCode
18.12.2025 08:47Пароль - самая лучшая защита, пока еще мысли читать не научились. Вот когда научатся мысли читать, тогда да, непросто придется. А все эти пасскеи и прочее - это или файл, или физический носитель, который можно сломать или потерять. А пароль - он в голове. И не зависит от произвола государств и корпораций. И если человек его сам забыл - ну значит сам и виноват, недорос еще до компьютеров, иди смотри телевизор.
Еще удивляют "политики безопасности", когда в корпоративных системах заставляют раз в месяц менять пароль, причем запоминают предыдущие и не дают их использовать. Зачем? От кого эта защита? От самих пользователей? Если у вас сеть дырявая так почините сеть, а юзеров оставьте в покое. Я теперь просто использую некий стандартный пароль и к нему добавляю цифры месяца и года. По сути типа TOTP с огромным периодом и вычислениями в уме:)
Belowzero273 Автор
18.12.2025 08:47В этом и проблема - мы не можем сделать порог входа в сервис и устраивать экзамен, проверяя созрел ли человек заказывать еду в интернете или смотреть аниме. Доступ нужен всем и надо постараться, что человек не навредил себе сам или ему не помогли с этим злоумышленники. Отсюда все эти идеи и концепции о балансе удобства и безопасности
0mogol0
18.12.2025 08:47Пароль - самая лучшая защита, пока еще мысли читать не научились.
расскажите это жертвам фишинга и соц.инженерии... Когда люди сами диктуют и пароль, и второй фактор.
Ну то есть в идеальном мире, где сказали человеку "никому никогда не говорить пароль", и он никогда никому не скажет. А в жизни - и родным скажет, и по телефону его могут развести.
И дальше можно сказать, что раз он не соответствует "идеальному человеку", то дальше это уже его проблемы. А можно пытаться работать с таким "несовершенным человечеством".
NeoCode
18.12.2025 08:47Только не нужно при этом всех под одну гребенку. "несовершенные" пускай пользуются всеми этими новомодными защитами от самих себя, а мне оставьте старые добрые логины и пароли. И без всяких вторых факторов.
0mogol0
18.12.2025 08:47а мне оставьте старые добрые логины и пароли. И без всяких вторых факторов.
угу, а платить за доп. поддержку варианта с паролем кто будет?
Если это обеспечивает большую безопасность, то в какой-то момент это будет обязательно для крит. приложений, типа здоровья и банков. А дальше и остальные перейдут, и поддержка только пароля, станет таким же древним легаси как и basic auth по http.
GidraVydra
18.12.2025 08:47Пасскей или пароль от хранилища "жертвы фишинга", конечно же, передать не смогут, ага...даже биометрию методами социнженерии выманивают без проблем, а уж пасскей вытянут с ровно той же легкостью, что и пароль.
0mogol0
18.12.2025 08:47я могу ошибаться, но суть в том, что с пасскеем человек напрямую не работает. Он спрятан в системном хранилище, а человек лишь подтверждает возможность его использования вводя ПИН или проходя биоаутентификацию.
GidraVydra
18.12.2025 08:47Необязательно, пасскей может быть файлом на флешке или даже QR-кодом на бумажке. Это просто кусочек информации. Строка, если угодно.
Если речь идет о пасскее, лежащем в "системном хранилище", что бы это не значило, то точка уязвимости - пин-код от хранилища. И проблема в том, что он один на всё хранилище, со всеми хранящимися внутри доступами.
0mogol0
18.12.2025 08:47И проблема в том, что он один на всё хранилище, со всеми хранящимися внутри доступами.
Ну то есть менеджер паролей в этом смысле так же плох?
Abyss777
18.12.2025 08:47И если человек его сам забыл - ну значит сам и виноват, недорос еще до компьютеров, иди смотри телевизор.
Как будто мозг человека это-то что-то супернадежное. Инсульт, травма, дтп и месяц в реанимации, опухоль, и еще куча различных болезней могут привести к частичной потере памяти.
Tony-Sol
18.12.2025 08:47А пароль - он в голове. И не зависит от произвола государств и корпораций
Интересна битва такого юношеского максимализма и терморектального криптоанализатора, кто победит.
Еще удивляют "политики безопасности", когда в корпоративных системах заставляют раз в месяц менять пароль, причем запоминают предыдущие и не дают их использовать. Зачем? От кого эта защита? От самих пользователей?
Вот уж действительно
недорос еще до компьютеров, иди смотри телевизор
Предлагаю тогда и куки везде бессмертными сделать и кнопки logout везде выпилить, чего уж мелочиться.
использую некий стандартный пароль и к нему добавляю цифры месяца и года
А вот это уже нормально, только
цифрычисла месяца и года имеют низкую энтропию, лучше чтото подлиннееGidraVydra
18.12.2025 08:47Интересна битва такого юношеского максимализма и терморектального криптоанализатора, кто победит.
Терморектальный криптоанализатор побеждает любую систему доступа, и пасскей в плане устойчивости тут ничуть не лучше пароля. Но если вы на минутку отвлечетесь от своего юношеского максимализма и допустите существование способов взлома, не связанных с прямым воздействием на носителя доступа, то тут пароль всухую уделывает все эти пасскеи.
Ещё раз повторю, на всякий случай: в предельном случае пасскей не безопаснее пароля, в остальных - пасскей точно менее безопасен, чем пароль.
Tony-Sol
18.12.2025 08:47Ещё раз повторю, на всякий случай: в предельном случае пасскей не безопаснее пароля, в остальных - пасскей точно менее безопасен, чем пароль.
Аргументы? Как минимум не существует такой вещи как "самые распространенные пасскеи", которые можно перебрать, радужных таблиц для них тоже нет, таблиц хэшей и тому подобное
Но если вы на минутку отвлечетесь от своего юношеского максимализма и допустите существование способов взлома, не связанных с прямым воздействием на носителя доступа,
А где я это отрицал? или писал что пароли хуже? Изначально это ответ на то, что мол "пароль не зависит от произвола" - оспаривалась эта наивная позиция.
GidraVydra
18.12.2025 08:47Как минимум не существует такой вещи как "самые распространенные пасскеи", которые можно перебрать, радужных таблиц для них тоже нет, таблиц хэшей и тому подобное
Зато существует такая вещь, как пин-код от хранилища пасскеев, которая куда менее устойчива к взлому ввиду меньшего размера.
Tony-Sol
18.12.2025 08:47Вообще не факт, что пароль для разблокировки хранилища (мастер-пароль или мастер-фраза) будут меньшего размера - здесь применимы все те же приемы что и для обычного пароля.
MonkAlex
18.12.2025 08:47Картинка в статье отвратительная. Стрелки и цифры показывают что угодно.
Про пасскей - если я могу его хранить в кипасе и повторно использовать с любого устройства - то пусть будет, тот же самый "пароль" получится.
Belowzero273 Автор
18.12.2025 08:47keepass, на сколько я знаю, пока не умеет работать с passkey, но когда научится, то действительно сможете там хранить свои ключи. Это не будет тот же самый пароль, потому что вы не найдете свой passkey в дампах утечек сервиса, который взломают. А вот пароль найдете)
MonkAlex
18.12.2025 08:47Как это работает? Ну т.е. если пароль утекает от владельца БД, то что мешает утечь какому-нибудь закрытому серту, который сделает что, подставит сразу все пасскеи?
Или схема как с паролями, каждую пару отдельно хранят и как-то солят?
Belowzero273 Автор
18.12.2025 08:47потому что в случае с passkey при взломе БД вашего сервиса злоумышленник получит набор открытых ключей и ID аккаунтов, которые секретом не являются - так устроена любая криптографическая система с открытым ключом. Проблема начнется только если будет получен доступ к Вашему устройству, где хранится закрытый ключ
mrkooll
18.12.2025 08:47В дампе найдете не пароль, а соленый хеш пароля. Что не сильно от открытого ключа отличается.
K0styan
18.12.2025 08:47пароль — это единственный из факторов аутентификации, который можно отнять у человека
Откровенная неправда. Отнять можно как раз фактор "я владею", причём именно лишив владельца доступа. Фактора "я знаю" лишить невозможно. Более того, его можно бэкапить тысячью разных способов.
Ну и да. Налетал уже на сценарий "вот новое устройство, где я должен залогиниться в единственном сервисе, остальные я ему не доверяю; своего софта у меня там нет; подключить аппаратный ключ нельзя". Из остального под рукой - смартфон без связи. Реально работает только пароль + TOTP.
aik
18.12.2025 08:47пользователь не знает и не должен знать своего пароля, потому что его попросту нет, только ключевая пара
Если у пользователя есть пароль, то он зайдёт откуда угодно. Можно с подтверждением вторым фактором. Если у пользователя пасскей - то он зайдёт только оттуда, где пасскей хранится. Девайс с пасскеем взорвался - и всё, никуда не зайти. Не так уж редко бывает, кстати. И если пароли пользователь может хоть ручками на бумажку забэкапить, то с пасскеями такое не выйдет. Так же пароль можно делегировать на той же бумажке. Пасскей нельзя. Ну и т.п.
Я вот сегодня пытался с нового телефона в яндекс войти без пароля. Там либо картинку выбрать, либо штрихкод считать. Картинку мне почему-то яндекс.ключ не показывал, а картинку считать он может только камерой. А камеру на сам телефон не направить. Пришлось взять второй телефон, сфотографировать экран и потом по фото штрихкода входить. А был бы пароль - вошел бы как белый человек, по паролю и одноразовому коту.
Я не против пасскеев как таковых, но не надо их пихать в каждую дырку.
Belowzero273 Автор
18.12.2025 08:47Я думаю, что для применения passkey нужна совсем другая парадигма мышления. Вы верно заметили, что если девайс взорвался, то без passkey не зайти. Именно поэтому имеет смысл хранить два passkey на разных устройствах для одного сервиса. Ровно как и записывать пароль на бумажку или хранить в менеджере паролей - всё это создает отказоустойчивость выбранного Вами средства аутентификации.
aik
18.12.2025 08:47Вопрос только в том, нахрена всё настолько усложнять?
Пароль плюс второй фактор в любом виде - это то, что и просто, и вполне надёжно для повседневной жизни. Кому нужно что-то более сложное - тому флаг в руки, пусть что угодно придумывает.
xSVPx
18.12.2025 08:47Само себя не продаст ведь...
Ну и автор пишет про когнитивные искажения, уверен какие-нибудь два немца назвали своими именами искажение с формулой "чем хрень сложнее, тем она как бы безопаснее".
Kagvi13
18.12.2025 08:47Тогда уж несколько устройств и хранить их в разных местах (если у вас два смартфона и один забрали, то и второй тоже, скорее всего, постараются забрать). Ну или бекапить БД на флешки, которые прятать в разных местах (в идеале - вне дома).
aik
18.12.2025 08:47Только "обычный человек" (с) ничем подобным заниматься не будет. Пока всё не потеряет.
TsSaltan
18.12.2025 08:47Если аутентификация возможна исключительно с помощью passkey, как допустим войти в аккаунт с другого девайса? Можно отправить уведомление на устройство, где уже выполнен вход, а если этого устройства нет под рукой?
Belowzero273 Автор
18.12.2025 08:47если вы храните passkey в менеджере паролей, то проблемы нет - вы получите копию на своё другое устройство
Anselm_nn
18.12.2025 08:47Я пользуюсь keepassxc, у меня есть телефон на android (без gms), и несколько ПК на linux. Несколько раз я видел предложение создать passkey, однако процесс создания всегда завершался сообщением о том, что не получилось. Как его таки создать и сохранить в keepassxc-хз.
Если для использования нужно иметь именно windows, chrome, gms и прочее, то стандарт дохлый.
xSVPx
18.12.2025 08:47Если вы подарили все свои пароли какой-то еще организации, то о какой безопасности вообще может речь идти :)?
GidraVydra
18.12.2025 08:47если вы храните passkey в менеджере паролей, то проблемы нет - вы получите копию на своё другое устройство
Ну, то есть доступ к пасскею, а на сдачу и ко всем остальным твоим паролям и пасскеям, получит любой, кто узнает пароль от менеджера паролей...чуете, чуете? Это защищенностью запахло.
K0styan
18.12.2025 08:47Если девайс ваш или вы ему доверяете - накатить на него менеджер passkey и развернуть там свою базу (через синхронизацию или бэкап-рестор).
Если девайс чужой, вы ему не доверяете, или нет технической возможности вот это всё проделать - passkey не помогут, потребуется альтернативный способ входа (если он есть у сервиса).
Поэтому обязательно надо оценивать сценарии. Доступ к рабочему аккаунту - скорее всего понадобится только на рабочей же машине, да и менеджер паролей/passkey может вполне быть корпоративный же. А вот к сайту авиа- или ЖД-билетов может понадобиться из какого-нибудь интернет-кафе в другой стране, тут риски потери доступа выше, чем риски кражи аккаунта.
vesper-bot
18.12.2025 08:47Проблема с паролями в том, что придуманы они для людей, а для людей нет ничего более противоестественного, чем запоминать последовательности букв и цифр.
"Пароль!" - "На горшке сидел король"
Пароль, если вы не знаете, это слово "слово" на французском, и означает именно слово, по которому человека когда-то давно идентифицировали как своего. Цифры в пароле появились с приходом компьютеров и ограничения на 8 (а иногда и 7) символов из-за кривой реализации обработчика пароля, просто потому, что компьютер позволял ещё тогда перебирать пароли - пришлось усложнять требования. И всякие там лошадки со скрепками стали доступны только тогда, когда в пароле значимыми стали больше восьми символов. Passkey - формально, тот же пароль, только знает его устройство, а не ты, а в случае устройства TOTP как второй фактор лучше единственного не полностью подконтрольного.Китайцы сделали пароль из двух половинок, который хранился у двух разных людей
Вроде как из трёх - пароль, отзыв, второй кусок пароля, которые соединялись в нечто верифицируемое. Причём это была первая рабочая модель аутентификации сервера клиентом. Либо мы о разных системах парольной защиты.
Убийца открыл дверь. Комната для аудиенций была пуста, внутренние двери
не охранялись. Он втащил труп внутрь и опять закрыл дверь. Без колебаний он
пересек комнату и выбрал левую внутреннюю дверь. Она была сделана из дерева
и хорошо укреплена. В его правую руку скользнул изогнутый нож. Он мягко,
тихонько постучал.
- "... В дни императора Ширакавы... " - сказал он первую часть пароля.
С другой стороны двери донесся лязг стали, вынимаемой из ножен, и
ответ:
- "... Жил мудрец по имени Инраку-джи... "
- "... Который написал тридцать пятую сутру". У меня срочные послания
для господина Торанаги.
Дверь распахнулась, и убийца нанес удар.
Shaman_RSHU
18.12.2025 08:47"Защищенное хранилище" остаётся защищенным до тех пор, пока не найдут способ его взломать. А это вопрос времени.
А вот реализация двух паролей: рабочего и аварийного - это мало кто реализует. Аварийный пароль нужен для случая, когда его необходимо назвать в момент "ректального криптоанализа". После ввода аварийного пароля вся информация уничтожается / аккаунт удаляется и т.п.
0mogol0
18.12.2025 08:47После ввода аварийного пароля вся информация уничтожается / аккаунт удаляется и т.п.
угу, а потом удаляют героя-подпольщика... И это если речь про онлайн сервис, а если речь про физический носитель, то никто не работает с оригиналом, всегда делают копию, так что повторять можно много раз.
Работал в свое время в западной компании, и там как-то начальник сказал прямым текстом, что все битлокеры, пароли - это для того, чтобы не смогли получить доступ к вашим данным, если его у вас случайно сопрут. А вот если его целенаправленно похитят вместе с вами, то не играйте в пионера-героя и говорите пароль, когда спросят.
Kagvi13
18.12.2025 08:47Физический носитель может выдавать разную информацию при основном и аварийном пароле.
0mogol0
18.12.2025 08:47буквально следующий коммент про это. Что нужно не просто выдавать разную информацию, но актуальную и правдоподобную. То есть если "спрашивают" сотрудника, а у него в разблокированном разделе только почтовый ящик с письмами за прошлый год, и "Новая папка", то скорее всего паяльник не выключат.
Ну и это мы не говорим, что можно банально отправить сотруднику имейл на его оф. адрес, и посмотреть получен ли он этим "настоящим аутлуком".
Я бы скорее задумался о том, что "аварийный" пароль - позволяет зайти и аутентифицироваться в системе как обычно, но в тихую отправляет оповещение админам и СБ компании о ЧП.
А вариант с "безопасным хранилищем" - это скорее для ооооочень важных сотрудников, читай нелегальной агентуры, где несложно подготовить набор "актуальных данных" для короткой командировки наряду с остальной легендой.
K0styan
18.12.2025 08:47Аварийный пароль должен открывать альтернативное хранилище, набитое правдоподобной, частично даже реальной и актуальной, но безопасной информацией. Поддержание такого хранилища - это отдельный трудоёмкий квест, поэтому и востребованность именно аварийного пароля низкая.
Для стирания информации актуальны другие штуки, типа тревожных кнопок, которые предполагается нажимать ещё до того, как девайс попадёт в чужие руки.
vitaly_il1
18.12.2025 08:47А что коллеги думают про хранение passkey в менеджере типа Bitwarden?
С одной стороны - удобно, но когда и пароль и passkey хранятся вместе, мне как-то неуютно.K0styan
18.12.2025 08:47Если разделять - вот у этого сервиса парольный доступ, а вот у того - через passkey - то нормально.
vitaly_il1
18.12.2025 08:47речь про passkey как second factor
Belowzero273 Автор
18.12.2025 08:47я сам пользуюсь bitwarden много лет, где поддержка passkey появилась буквально недавно, так что пока тестирую, как это работает, но мне нравится как это удобно и работает
Raam
18.12.2025 08:47пароль — это единственный из факторов аутентификации, который можно отнять у человека
Ну а как же биометрическая аутентификация? Можно к примеру палец отрезать и отнять. И потом телефоны и все менеджеры паролей и тот же passkey с его помощью разблокировать. Помимо пальца есть ещё и другие части тела, которые тоже используются в аутентификации и их тоже можно отнять...
karrakoliko
18.12.2025 08:47пользуюсь totop в 2fasAuth.
сейчас там около 30 токенов от разных сервисов.
начал дергаться глаз от ввода токенов когда заноао авторизовывался с нового лэптопа в личные и корп сервисы.
купил себе yubikey. "это же так удобно: вместо ввода 2fa токена просто прикасаешься к флешке!".
теперь у меня 4 сервиса где вместо токена с телефона я могу ткнуть в yubikey, 1 где я должен тыкнуть в yubikey и ввести пинкод (тк wise без пинкода не хочет), и 25 где мне все еще нужен телефон с 2fasAuth.
до: 30 totp токенов в 2fasauth
после: 30 totp токенов в 2fasauth, 5 из них работают с yubikey
будущее рядом, мужики, классно удобно эргономично безопасно ради вашего удобства!
garwall
18.12.2025 08:47феноменом Баадера — Майнхофа.
Баадера-Майнхоф. Запомните уже умницу-красавицу-террористку Ульрику Майнхоф
oalisevich
18.12.2025 08:47пароль лучшая защита - именно потому что что живет (если конечно живет) только в голове.
если у вас вся цепочка аутентификации это устройства/программы/ключи и даже пальцы (внешняя биометрия) - ей можно воспользоваться БЕЗ вашего (личного, ака сознательного) участия.
2 нюанса:
если у вас много точек ввода, по хорошему пароли нужны разные (разные точки - разный уровень доверия) - и это проблема запоминания/управления паролем.
второй фактор - позволяет исключить случайную потерю (или проговорился во сне). и является гарантом что это таки Вы используете пароль.
ну и конечно пароль должен быть Хороший )
nerudo
Чем отличается вариант "под угрозой паяльника я заставлю тебя сказать пароль" от "под угрозой паяльника ты мне отдашь passkey"? Ну кроме того, что passkey уже не запомнишь и в случае утраты шансов вспомнить никаких.
Belowzero273 Автор
Разница, как обычно, в нюансах - действительно, под действием паяльника ломаются любые пароли. Но если, например, речь про фишинг, то сообщить пароль по телефону реально, а вот продиктовать passkey - вряд ли
id_Alex
а что скажете про это - https://www.kaspersky.ru/password-manager
Belowzero273 Автор
Менеджер паролей, такой же как и десятки других и passkey можно хранить в нём, причем с возможностью синхронизации между устройствами
dbirjukov
Пользовался таким год. Пока была подписка. Всё устраивало, но надо брать подписку. Потом перешёл на KeePass 2. Всё-таки когда база дома как-то спокойнее. В Keenetic вставлена флешка. Поднял Syncthing и норм.
SanSYS
Вы можете хоть десять пасскеев резервных добавить (телефоны, менеджеры паролей, ОС, всякие гугл/эпол, юбикеи в конце концов)
И если вы потеряли один единственный ключ – ССЗБ, нужно было как с ключами от квартиры - делать запаску
А вот утеря единственного пароля это реальная печаль
Да что там говорить, для веб сервисов пароли уже прошлый век, глянуть хотя бы на багтехи, типа гугл, мс, да хоть ибей или дроп бокс – форсируют по полной программе (видимо бороться с фишами устали)
GidraVydra
Они форсируют то, что нужно им. С чего вы взяли, что их интересы совпадают с интересами пользователя?
SanSYS
Я этого и не утверждал, но определённо они уменьшают себе кучу рисков и расходов касаемо чисто компаний: общение с пользователями, рассылки СМС, в крайнем случае – траты на юристов. Для людей – современный безопасный и гораздо более удобный аус, чем пароли, для компаний – меньше трат. Приложить палец проще к телефону/компу, чем заставлять пользователя ждать, ожидание это опасно – он может передумать или поставить плохую оценку (актуально для сторов)