Pull to refresh

Comments 43

Пасскеи, подтягивающиеся из Keepass - очень удобно и, в отличие от аппаратных токенов, легко бэкапируются. И никакой биометрии.

Пасскеи, подтягивающиеся из Keepass - очень удобно и, в отличие от аппаратных токенов, легко бэкапируются. И никакой биометрии.

А ткните pls носом в инструкцию, как забекапить в Keepass и соответственно вытянуть, на примере того же. https://webauthn.io/ Заранее спасибо.

Попытался в https://webauthn.io/ создать пасскей телефоном. Оно говорит, у вас старые пасскеи в телефоне имеются. Для создания нового, удалите старые. Но ведь я их создавал, для других сайтов. Если удалю, то что? Короче, я не решился, но и как новый создать, ума не приложу. С FIDO донглом гораздо понятнее, но хотелось бы альтернативу тоже попробовать. Вдруг донгл потеряется или сломается.

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

Я имел в виду зарегистрировать пасскей в Keepass'е - и затем сделать резервную копию базы.

Я имел в виду зарегистрировать пасскей в Keepass'е

Так а как пасскей зарегистрировать в Keepass? Не догоняю конкретно. Он же в телефоне, FIDO донгле заныкан.

Пасскей регистрируется (выпускается приватный ключ и т. д.), когда вы на сайте нажимаете кнопку. Если в этот момент подключен Keepass - он предложит это сделать через себя.

Оно говорит, у вас старые пасскеи в телефоне имеются.

Это все-таки демка. Учетку забывает. В реальности это означает, что в сервис этими существующими пасскеями и надо логинится. Ибо учетка уже есть. Хотя, по идее. можно было бы выбрать другой username - тогда бы они для новой учетки того же сайта создались.

что в сервис этими существующими пасскеями и надо логинится.

Так я понял, что "старые" пасскеи, это он про другие сайты говорил, где я уже ранее создавал пасскеи, а не про https://webauthn.io/ потому что, откуда им тут взяться то. Я только первый раз зашел попробовать https://webauthn.io/

это он про другие сайты говорил

Это должно быть невозможно. Там очень много сделали (в рамках борьбы с фишингом) чтобы креды были стойко с сайтом связаны.

Я только первый раз зашел попробовать https://webauthn.io/

Я бы все-таки попробовал залогинится и посмотрел, какой список для использования предлагается.

Я бы все-таки попробовал залогинится и посмотрел, какой список для использования предлагается.

Даже если Вы правы, меня смущает еще то, что почему чтобы зарегистрироваться с новым пасскеем, нужно обязательно удалять старый пасскей? Почему нельзя дублировать.

А еще обратил внимание, что Хром и Опера позволяют зарегистрировать пасскей из смартфона или FIDO донгла, а Лиса только FIDO донгл. В FF нет выбора, то или то.

меня смущает еще то, что почему чтобы зарегистрироваться с новым пасскеем, нужно обязательно удалять старый пасскей?

Возможно, потому что MS так решило и это особенность имплементации. Или так авторы спецификации решили. Потому что потом их как-то (расположенные на одном и том же устройстве) различать надо в диалоге выбора "каким пользуемся?" -- username же один и тот же.

Ну и логично в некотором роде. Второй нужен если ты первым не смог воспользоваться - т.е. он невалидный с точки зрения сервиса (удалили его с учетки). Вот и нечего его хранить, каждый раз смущая выбором.

Какой разумный сценарий, когда нужен второй, но нужно оставить первый?

Какой разумный сценарий, когда нужен второй, но нужно оставить первый?

К примеру, у меня два смартфона. Основной и запасной попроще, постарее, который беру с собой в отпуск. Если сломается, потеряется, украдут, не очень жалко будет. Такая вот подмена, резервирование. А пасскеи хотелось бы с обоих иметь.

 А пасскеи хотелось бы с обоих иметь.

Хранилище синхронизируется между устройствами. (Собственно, я подозреваю, в том числи ради этого их и придумали - в голом WebAuthn этого нет). Так что ключик будет на обоих смартах если они на одной гугловой учетке висят. Ну ли Apple-вой.
Во вторых, даже если синхронизации нет - создать пасскей (уже другой) на втором устройстве - штатная функция и ругани "Passkey тут уже есть" как описано, быть не должно, т.к. его и нет. Будет два, разных ключика, одинаково пригодных для входа в сервис.
Исключение - странные и ленивые сервисы, которые считают, что ключик может быть только один (как раз наличие синхронизации позволяет так считать). Но мне такой пока только один встретился.

а Лиса только FIDO донгл. В FF нет выбора, то или то.

Похоже на старую лису, в которой полноценной интеграции не было. Там, помнится, они умели общаться только аппаратными ключами, но не умели общаться с системой, которая хранилищем ключиков заведует.
Это хоть на чем все? Я не помню статуса поддержки разных систем. В линуксовой, кажется, до сих пор нет, потому что у системы нет хранилища этих самых ключиков. А хром - использует встроенный гугловый password manager для этих целей.

Это хоть на чем все?

Вот как раз в Линуксе, Минте и сижу. Лиса самая актуальная, v138

Вот как раз в Линуксе, Минте и сижу.

Тогда ищем Password Manager с поддержкой Passkey-ев и интегрируем с браузером. Он будет хранилищем ключиков работать.

Настроил себе KeepassXC для интеграции паролей и пасскеев с браузером, но несмотря на это, один интересный сайт, при попытке создать пасскей, послал меня лесом. Пробовал Хром, Лису, Оперу - ФигВам, народная индейская изба, с сообщением, что Операционная система(Linux Mint, последняя) не поддерживается. В Винде не пробовал, так как слез с нее лет 15 назад и не хочу обратно ни за какие коврижки. Хорошо то, что этот сайт такой единственный мне попался и он некритично мне и нужен. Если таки очень приспичит, то можно и постаринке на него зайти, с паролем и 2FA. Но за державу обидно(ц).

Иногда помогает сделать отмену и 'попробовать еще раз'.

Но, вообще, если именно про операционку сам сайт говорит - то это сайт слишком умный и проверку делает, совершенно зря.

Еще в стандарте, вроде, есть возможность спросить, чья именно реализация хранилища ключей/токенов используется. (проверяется ключ производителя токена). Нужно для особо параноидальных сервисов, которым ну вот по зарез нужна какая-нибудь сертификация используемых средств защиты. Но всем остальным рекомендовано таким не пользоваться.

Что значит стремитесь к пуш? Оффлайн генератор кодов и онлайн пуш коды закрывают разные потребности и имеют разные уязвимости.

Что такое пасскей я не знаю и по статье не понял ничего.

Сходил на указанный webauthn.io - ткнул регистрация, оно мне виндовый запрос выкинуло, я не смог соотнести то что на сайте написано и то что мне винда написала, поэтому я нажал "отмена", ибо непонятно что происходит. Прозрачность решения с моей точки зрения под вопросом.

Годное замечание - действительно, разная модель угроз, разные варианты применения.

Про Passkeys - тема новая и не совсем очевидно, что это не просто "биометрия", а способ заменить пароли криптографией на стороне устройства. В идеале - без паролей вообще.

Дополнил статью.

Никакие средства, которые находятся внутри устройства на котором вы авторизуетесь небезопасны.

То, что ТОТР надо вводить - это огромный, жирный плюс к безопасности, а не минус.

Единственная с ним проблема - то, что он авторизует для любого набора действий. Хорошая безопасность была бы с ТОТР генератором в отдельном устройстве (защищенном пином), которое выдавало бы для банка, к примеру, разные наборы паролей для разных операций. Т.е. надо было бы выбрать "дай код для логина" или "дай код для перевода в пределах 10000руб", итд итп.

Но кого волнует безопасность, ведь так удобно подтверждать неизвестно что прикладыванием пальца. (При этом если речь о телефоне, то палец может быть отдельно от его владельца).

Единственная с ним проблема

Не единственная. Есть еще проблема, что их можно продиктовать по телефону. Proximity Test устройства авторизации нет.

Это совершенно не проблема. По телефону можно просто заполнить реквизиты получателя как скажут и перевести все деньги куда не надо.

Системы безопасности должны защищать умных. Недееспособные вообще не должны иметь доступа, никакого. Им просто нечего диктовать.

Это совершенно не проблема.

Несколько проблема. Народ диктует код после убалтывания а потом мошенник в условные Госуслуги входит, где заполняет что попало уже без диктовки разных реквизитов.

Системы безопасности должны защищать умных.

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

Точно также народ будет заходить сам в госуслуги и сам вводить всё что нужно.

Какое убалтывание дееспособного человека возможно если у него ТОТР в отдельном устройстве и он прям выбирает "получаю код для входа в госуслуги" или "получаю код для перевода денег" ?

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

В этом категорическое отличие от правил ТБ. Вы предлагаете дурные, небезопасные практики, которые уже приводят к проблемам.

Недееспособных надо защищать иными, нетехническими способами. К примеру, через механизм опеки.

Какое убалтывание дееспособного человека возможно если у него ТОТР в отдельном устройстве и он прям выбирает "получаю код для входа в госуслуги" или "получаю код для перевода денег" ?

И потом 'код для перевода денег' говорится злодею(притворяющимся техподдержкой), потому что человек думает, что это про те 100 рублей, что он на экране видит. А злодей в той же форме набрал 100000.

Кроме того - как именно авторизатор узнает, для чего именно код сгенерировать надо? Вшитый конечный список и выбираем на нем кнопками? Так он не может быть конечным - сервисов много и делать можно много чего. Значит, авторизатор должен как-то операцию получать. Лучше всего - по интерфейсу близкого радиуса действия. Можно даже прямо контактному.

И если он уж есть - то и заставлять пользователя несколько цифр набирать вручную смысла нет. Надежней передать с авторизатора (длинную) ЭП запрашиваемой операции, что человека на этом авторизаторе посмотрел и подтвердил.

А по поводу того, что я тут в этой теме предлагаю - это что Passkey-и значительно лучше паролей. дополнительного риска они не несут. И внешнего устройство там где мы не доверяем собственно смартфону или боимся что его сломают они не отменяют.

А потом кодом для подтверждения перевода на сумму до 100 рублей не подтвердить перевод на 101рубль.

Вы, сейчас пытаетесь изобрести то, что изобретено до вас.

Идеи

  1. А вдруг он скажет пароль для перевода блаблабла

    И

  2. А давайте сделаем так, чтобы нажатием одной кнопки можно было бы все подтвердить

    У меня в голове укладываются не очень. Вы или крестик снимите, или трусы наденьте....

Подписывать на отдельном устройстве каждый конкретный приказ, конечно еще лучше. Но этож думать надо...

Рассмотрим тот авторизатор, который, я понял, вы описываете:

Т.е. TOTP-образный с дополнительной функцией выбора режима. Автономный. Без ввода параметров

выдавало бы для банка, к примеру, разные наборы паролей для разных операций. Т.е. надо было бы выбрать "дай код для логина" или "дай код для перевода в пределах 10000руб", итд итп.

Причем режимов не очень много - поэтому сгенерированный код будет подтверждать не конкретное действие с конкретными параметрами, а какую-то группу("код для перевода в пределах 10000" - и без указания счета получателя).

Поэтому есть риск того, что злодей убалтает человека на код, а потом авторизует этим кодом (уже на своем устройстве) что-то из этой группы, но с другими значениями ("в пределах 10000", но на свой счет, а не на тот, что человек в форму вводил). Без всякого взлома устройства пользователя.

Теперь берем мой, что 'с одной кнопкой', но с proximity test и невозможностью что-то надиктовать, т.к. экрана и цифр просто нет. Тут злодей своем устройстве просто убалтыванием ничего сделать не сможет. Надо будет именно ломать устройство пользователя (или убалтать еще и на троян), чтобы потом прямо на устройстве пользователя перехватывать общение с сервисом или авторизатором.

Причем ваш авторизатор в случае взлома устройства тоже не поможет - человек точно так же введет код и авторизует перевод на тот счет, что надо злодею. (устройство же затроянено - сообщение в сервис уйдет с другим счетом назначения)

Т.е. мой вариант хуже не выглядит.

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

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

В моем случае человек теряет 10000. В вашем - он теряет абсолютно ВСЁ.

Если на вашем счету 10000, надо пользоваться вашим. Если 10 000 000, то не надо пользоваться вашим.

Это ведь просто....

Уболтать нажать кнопку гораздо проще, чем уболтать нажать много кнопок.

Правила безопасности просты: устройство должно быть отдельным аппаратно + пользователь в идеале должен видеть что он подтверждает конкретно, а в неидеале хотя бы тип операции и приблизительную сумму.

Если вы что-то упрощаете на этом пути - вы напрашиваетесь на неприятности. Большие.

Но мои рассуждения релевантны для человека у которого есть деньги. Если у вас только кредиты, то, наверное всё это неважно.

Если 10 000 000, то не надо пользоваться вашим.

То надо пользоваться моим(внешним, разумеется), но уже с дополнительным экраном, который показывает, что именно подтверждается. А не вашим, где можно заманить человека на фишинговый сайт и он свои 10 000 000 куда-то в левое место переведет, думая, что на свой счет.

Правила безопасности просты: устройство должно быть отдельным аппаратно + пользователь в идеале должен видеть что он подтверждает конкретно, а в неидеале хотя бы тип операции и приблизительную сумму.

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

Можно даже как у вас - пускай выбирает режим "до 10000". Но циферки для набора пользователем - излишни. Потому что вот пример: что в ваших сценариях сломается, если аудентификатор будет работать клавиатурой и сам в поле ввода этот код наберет?
Потом тот же самый вопрос - а если этот ввод звездочками показывается, т.е. пользователь кода и не видит никогда.

Passkeys — это способ входа в аккаунт без пароля и без одноразового кода. Вместо того чтобы что‑то помнить или вводить, вы просто подтверждаете вход с помощью отпечатка пальца, Face ID или PIN‑кода — на своём устройстве.

Я вот на этом моменте всегда зависаю, т.е. биометрия - это понятно, вещь - которая к тебе привязана, а вот в чем секурность использования PIN?

Зависит от модели угроз. Условно:

  • если защищаемся от физической кражи телефона, то биометрия безопаснее;

  • если защищаемся от того, что пока владелец будет спать пьяным под забором, его палец приложат и натворят чудес - безопаснее PIN.

По средней совокупности - безопаснее биометрия, правила блокировки по кнопке/жесту и стирание телефона при 10 ошибках ввода PIN, как в iPhone.

p.s. в контексте Passkeys: Face ID и PIN -- не фактор входа, а механизм разблокировки криптографического ключа.

А как соединить push и passkey?

Я хотел бы при попытке зайти на ресурс с passkey с виндового компа получать запрос подтвердить passkey на другом моем устройстве.

Как это сделано на macOS + iPhone.

Я хотел бы при попытке зайти на ресурс с passkey с виндового компа

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

Или просить сервис, чтобы требовал два фактора - не только Passkey но и подтверждение.

Желание, правда, экзотическое, потому сценарий атаки, который таким образом предотвращается - мне кажется довольно экзотическим.

А так - просто на заводить их на этом виндовом компе, а использовать Cross-Device Sign-In при помощи этого второго устройства.

Видимо, я не точно описал идею.

Можно ли с помощью keycloak вместо ввода одноразовых кодов получать запрос в аутентификатор на другом устройстве «это вы?»

Как это сделано в гугле или apple, например.

Вот тут что-то такое показано. Но не уверен, что это работает просто так, без участия сервиса (и вообще что это стандартный протокол для них, а не изобретение этих nok nok) - второе устройство же должно как-то узнать, что пользователь залогинится хочет.

спасибо! идеальный ответ. судя по описанию стандарта, возможно реализовать аутентификацию с помощью webauthn + passkeys через push, но только кастомным приложением, так что, noc noc сделали все в соответствии со стандартом.
ни на https://www.passkeys.io/ ни на https://webauthn.io/ к сожалению, не получилось зайти через push, только через QR код

Просто переходят от модели "secret key is something you know" к модели "secret key is something you have".
Да, первый вариант потдавался методам социальной инженерии. Но второй тоже не без недостатков, т.к. не защищен от кражи. Собственно, 2FA родилась в попытки уменьшить недостатки этих систем.
Собственно вопрос с физическими токенами только в их нативной поддержке браузерами и операционками.

А биометрия - это, простите, фигня. Ее либо крадут (различные идентификации по лицу, отпечатки), либо она меняется со временем. Рискнете поставить доступ по биометрии к банковскому счету, а потом на 5 лет уехать в места без интернета? Я не рискну! У меня из 4 пальцев введенных в систему через 3 года распознается только 1. Остальные больше не распознаются, хотя изначально все 4 работали. Поменялись отпечатки со временем - стерлись, микротравмы и т.п. А уж распознавание лица после травмы - это вообще крассический пример.

Рискнете поставить доступ по биометрии к банковскому счету, а потом на 5 лет уехать в места без интернета?

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

Да без разницы. Вы просто через 5 лет не можете предъявить лицо соответствующее той сохраненной биометрии. Т.е. с точки зрения биометрии вы - другой человек -> в доступе отказано.

Вы просто через 5 лет не можете предъявить лицо соответствующее той сохраненной биометрии.

И разлочу телефон PIN-ом. Вместе с хранилищем Passkey-ев. Собственно, разве есть системы, которые только биометрию заставляют использовать, не вынуждая еще вводить альтернативные способы доступа?

Вооот! О том и говорю. Все работает кроме биометрии. Так стоит ли ее изначально добавлять как фактор?
А системы есть. 2FA вида пароль+FaceID.

 Так стоит ли ее изначально добавлять как фактор?

Ну, от атак вида "подсмотрел пароль/PIN через плечо или камеру, а потом воспользовался, пока хозяин устройства где-то гуляет" - надо как-то хотя бы немного защищаться.

Sign up to leave a comment.

Articles