Комментарии 158
Чего больше, новостей про MAX или новостей про LLM?
Позволяет получить код для входа на «Госуслуги» тем, кто не имеет возможности получать СМС.
Браво. И кто же не может получать СМС? А, боты, конечно, и угнанные аккаунты.
Запретили приём СМС с кодами во время звонка? А тут разрешим!
Вы что, было очень много жалоб, что во первых в подвале и на парковке не приходят СМС, во вторых это старье, в третьих много мошенников используют смс для Форда и спама..
Люди слезно просили отказаться от этого хлама, особенно в тот момент как вся страна шагает в свотое будущее (а не каменный век как всем кажется)
а еще были жалобы что сторонние аутентификаторы не скрепные, гуглом/мс/опенсурцнописанные.
Почему бы операторам не включить VoLTE и VoWiFi по всей стране для всех телефонов с его поддержкой? Глядишь и звонить опять через мобильного оператора люди стали бы благодаря шикарному качеству звука. И SMS приходили бы в подвал благодаря SMSoIP идущим в комплекте к VoLTE и VoWiFi.
Видимо дорого. Например, у нас еле2 только этой весной такое смогли запустить. До этого даже интернет пропадал во время звонка.
Потому что поддержка VoLTE и VoWiFi зависит от того вшит профиль оператора в ваш телефон или нет. Если вы купили, например, телефон только для рынка Америки, велика вероятность что VoWiFi в РФ с провайдерами РФ не заработает.
А так у того же мегафона уже лет немколько всё это работает. Были ограничения от товарища майора что бы даже с VoWiFi хотя бы раз в несколько часов аппарат регистрировался на вышке. Актуально ли сейчас не знаю. Но в целом работает.
Стандарты VoLTE и VoWiFi не подразумевают никаких вшитых профилей оператора. Достаточно MNC и MCC, которые телефону всегда известны, чтобы подключиться к epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org, а данный FQDN направит на IMS шлюз текущего оператора.
Не знаю как у всех операторов, но у Мегафона и МТС VoWiFi перестает работать, если телефон не подключен к соте свыше двух часов. У меня в деревне это реально приводит к периодической утере связи. Порой приходится выбираться из дома и выходить на дорогу, где сигнал сотовой связи ловится более-менее стабильно.
Значит ещё актуально... Ну в общем операторы по видимому не превозмогли ФСБ и без координат трубки VoWiFi не предоставляется. Регламент победил здравый смысл.
Если проблема только в геолокации, то выглядит действительно странно. За два часа легко можно более, чем на тысячу километров переместиться обычным авиарейсом. Геолокация по IP адресу явно точнее.
вышка - она операторская, а адрес он и за туннелем может быть. Даже не за одним.
Так же как и владелец телефона, управляющий им через ADB с любой точки планеты.
Да, но для этого нужна инфраструктура. Соответственно можно посадить хостера всего этого хозяйства. Это же не о том как человек себе хостит обход. Для этого можно и GSM шлюз просто поставить. Это история как убить коллцентры. На бумаге во всяком случае.
И какая разница, искать владельца приземления VPN или ADB? Разница только в том, что в первом случае заблокированную SIM-карту пощупать нельзя, а во втором - можно.
Разница в том что владелец ВПН может быть бомж с курского. Или вообще хакнутый телевизор. А симка она физически в квартире/доме находится. Было бы всё так просто РКН не блокировал по десятку ВПН каждый месяц.
UPD: ну и владелец ВПН может так же быть за границей банально. А тогда палку не выдашь.
Разница в том что владелец ВПН может быть бомж с курского.
Так ведь и владелец устройства с SIM-картой - тоже. Да и SIM-карты - тоже.
А симка она физически в квартире/доме находится.
Компьютер, приземляющий VPN на российский IP - тоже.
ну и владелец ВПН может так же быть за границей банально
Так же, как обычный абонент, о котором будет известно только то, что он в роуминге у какого-то зарубежного оператора. Какая разница?
Во всех случаях - это SIM-карта российского оператора, им проданная и не заблокированная только потому, что он располагает подтвержденными паспортными данными её владельца.
Так ведь и владелец устройства с SIM-картой - тоже. Да и SIM-карты - тоже.
Ну так она у кого то в квартире будет лежать с сотней других симок? Будет. Вот его и посадят. Это буквально единственный критерий. Можно кого то посадить по факту или нет. Именно так рассуждают в ФСБ. Поставить какую то левую железяку в цод довольно сложно.
Компьютер, приземляющий VPN на российский IP - тоже.
Нет. Он будет тупо VPS в цоде на левые документы.
UPD: ну и меня как бы бесполезно переубеждать. Я просто сказал требования пятого отдела. Никто, не говорил что они разумны. Это как требования геопозиции пользователей сип телефонии. Зачем - неведомо. Но требование есть.
в квартире будет лежать
в цоде
А почему не наоборот? И почему вообще это должно быть в помещении, а не где-нибудь на крыше нежилого здания? Почему-то размещать сервера в квартире - для Вас не нормально. А антенну сотовой связи - уже нормально.
А почему не наоборот? И почему вообще это должно быть в помещении, а не где-нибудь на крыше нежилого здания? Почему-то размещать сервера в квартире - для Вас не нормально. А антенну сотовой связи - уже нормально.
Потому что что бы что то смонтировать в ЦоД, неожиданно, нужны документы и человек. Нельзя просто прийти на Казанский, дать бомжу 1000 рублей и оформить симку. А что бы получить VPS ничего не нужно. Кроме собственно того самом телефона на бомжа.
Кейс с крышей жилого здания кстати вплывал, да. но заверили что искать обойдя 200-300 квартир значительно легче, чем искать вообще непонятно где.
А что бы получить VPS ничего не нужно
Во-первых, нужна еще оплата, причем совсем не криптовалютой. Во-вторых, уже сам факт приземления VPN на VPS в российском ЦОД в этих целях незаконен. В-третьих, подключение ридера SIM-карты, находящегося за рубежом от ЦОД - задача заметно сложнее, чем размещение этой карты в зоне доступности соты локального опсоса.
Кейс с крышей жилого здания кстати вплывал, да. но заверили что искать обойдя 200-300 квартир значительно легче, чем искать вообще непонятно где.
Искать устройство, которое появляется в сети раз в два часа, исключительно для возобновления доступа к VoWiFi, можно очень долго. И не факт, что успешно.
К тому же ESP-32 c GSM модулем может оказаться дешевле аренды VPS. А вот найти, кто его установил будет куда сложнее, если он работает через взломанный WiFi роутер, хозяин которого этого даже не подозревает.
Во-первых, нужна еще оплата, причем совсем не криптовалютой.
Что ж, это тоже довольно элементароно решается выпуском карты тем же МТС банком.
Во-вторых, уже сам факт приземления VPN на VPS в российском ЦОД в этих целях незаконен
Осталось только что бы преступники начали соблюдать законы.
В-третьих, подключение ридера SIM-карты, находящегося за рубежом от ЦОД - задача заметно сложнее, чем размещение этой карты в зоне доступности соты локального опсоса.
Просто включаешь VoWiFi и отключаешь GSM. Весь трафик завёрнут на цод В РФ через роутер. Всё, ты в Россси. Разговор, наопоминаю, щёл про отслеживание VoWiFi.
К тому же ESP-32 c GSM модулем может оказаться дешевле аренды VPS.
Его нужно где то поставить. Как то питать. Как то получать к нему доступ. Значит ты его поставишь 1. не в цод (проблеса с доступом) а где то возле себя. Не факт что прямо в квартире, но где то рядом. Видимо органы как то это вычисляют. Я не знаю.
Осталось только что бы преступники начали соблюдать законы.
Зачем? Нарушение закона является достаточными основанием для разрыва договора с ЦОД.
Просто включаешь VoWiFi и отключаешь GSM. Весь трафик завёрнут на цод В РФ через роутер
Kак инкапсулируя IPSec в VPN Вы скроете зарубежный IP телефона?
Его нужно где то поставить. Как то питать.
В любом электрощитке, там где ловится чей-то WiFi (не важно, физического или юридического лица) для которого был компрометирован PSK, Причем я не раз встречал электрощитки, которые стояли заваренными(!) лет по десять и более. А что? Автоматы доступны, ПУ видны )))
где то возле себя
Вам не кажется, что считать остальных идиотами может только не слишком умный человек?
Видимо органы как то это вычисляют.
Так как обе обсуждаемые схемы подразумевают SIM-карту российского опсоса, то они нежизнеспособны. Паспорта бомжей закончатся моментально. Вычисляют фермы, в основном, с казахскими SIM-картами. По понятным причинам, к VoWiFi это вообще отношения не имеет.
А почему не наоборот?
Ну если дропер так жаждет выдать себя и присесть то конечно можно и наоборот. Но цель кажется как раз в том что бы не присесть.
Так про то и речь, что ESP32 с GSM модулем потенциально найти можно, а вот владельца его - уже очень сомнительно.
Так про то и речь, что ESP32 с GSM модулем потенциально найти можно, а вот владельца его - уже очень сомнительно.
Рубишь питание и ждёшь кто придёт ремонтировать. Всё.
Вы второй раз демонстрируете, что считаете окружающих идиотами. Выводы напрашиваются...
Ну так я к органам отношения и не имею. Зачем у меня это спрашивать во второй раз я не понимаю. Если вам легче от ведения со мной диалога то пожалуйста, развлекайтесь. Я понятия не имею зачем это органам. Факт в том что требования такие. А дальше можете рассказывать про щитки, чипы, подпольных шифраторов и т.д.
UPD: почему я знаю что это требования органов? потому что работаю в телекоме и частично сам их исполняю. Пруфов не будет по понятным причинам. Можете верить, можете нет.
То есть, это из-за требований органов Вы искренне считаете, что для того, чтобы поймать того, кто заложил взрывчатку, нужно её обезвредить и подождать, пока не придёт тот, кто её установил, чтобы отремонтировать? )))
Я искренне считаю что люди разные. И действия их разные. И поведение тоже. Кто то будет ковырять ридеры, считываетли, и прочее, а кто то кинет обычный туннель и будет наворачивать деньги. Никаких противоречий в этом я не вижу. Поможет ли предложенный мной вариант? В каком то проценте случаев - несомненно. Посмотрите просто в архивах первого канала был целый репортаж как выносили домашние атски дроперов когда ФСБ наконец то узнало что GSM шлюзы существуют. И что? Десятки мх были, если не сотни. Людей кто просто дома коллцентры хостил. Без всяких схем со щитками и прочего технического извращения.
Поможет ли предложенный мной вариант? В каком то проценте случаев - несомненно.
Точно так же, как в каком-то проценте случаев помогает предложение явиться с повинной. Но рассчитывать на такое в оперативной деятельности - это уж глупость. Точно так же, как поджидать террориста у деактивированного взрывного устройства.
Идиот может установить GSM шлюз у себя дома. На то он и идиот. Но если человек уже оказался не идиотом и разместил GSM шлюз в электрощитке с заваренной дверцей, то не стоит рассчитывать на то, что он вдруг превратится в идиота.
А вот то, что Вы считаете окружающих идиотами - это уже характеризует лично Вас и совсем не в лучшую сторону. Как минимум, очень сильно подрывает доверие к любой полученной от Вас информации.
Как минимум, очень сильно подрывает доверие к любой полученной от Вас информации.
Ну так и замечательно. Я особо и не претендую. Зачем вы тогда мне отвечаете? =)
Затем, чтобы остальным читающим Ваши сообщения это тоже стало понятно.
Вот видите, Вы даже не поняли, что это не частная беседа, а публичное обсуждение )))
Вот именно. И нормальный человек для проверки фактов просто прочтёт мои комментарии, ну скажем годика за два, где прямо видно предсказание всего что будет в телекоме месяца 3-4. А не будет строить теории достоверности информации по 10 комментариям и софтскилам. И вы ещё говорите что я зря считаю людей идиотами.
Это как требования геопозиции пользователей сип телефонии. Зачем - неведомо. Но требование есть.
Почему неведомо? Ведомо. Потому что было n-ное количество звонков во всякие скорая-помощь-аварийно-спасательные службы, которые попали несколько не в тот географический регион, где был пострадавший. Ну вот и вписали в регулирование в духе "звонок на... должен уходить в МЧС того места, где звонящий находится".
Это не регулирование. У вас очень утрированное представление о работе органов и вообще СОРМа. Обычно операторы лично встречаются с органами. Да, такое есть. И там им товарищ майор чётко рассказывает что именно они должны делать. А не вот эти все регламенты.
Потому что было n-ное количество звонков во всякие скорая-помощь-аварийно-спасательные службы
Открою секрет, на сипе этого вообще нет. Он просто не считается средством аварийной связи.
UPD: условный eMotion не будет вас соединять в 112 или 03. Ни при каких обстоятельствах. Хотите соединение, просто киньте звонок по телефону. На такие номера вас любая вышка обслужит.
Он просто не считается средством аварийной связи.
Ну да, конечно. Оно, может, и не считается, но когда у компании в филиале на столах сотрудников стоят сип телефоны - то звонкам в скорую сильно рекомендуется приходить в местную скорую, а не в скорую того города, где головной офис находится и где АТС запущена.
А в контексте VoWiFi - тем более. Потому что сотовый телефон считается таким средством.
Ну да, конечно. Оно, может, и не считается, но когда у компании в филиале на столах сотрудников стоят сип телефоны - то звонки в скорую сильно рекомендуется приходить в местную скорую, а не в скорую того города, где головной офис находится и где АТС запущена.
Ну тогда оператор АТС офиса просто ищёт по справочнику номер ближайшей скорой и на своём фрисвиче перебивает 03 на тот номер. Если он просто кинет в сеть 03 - никуда не попадёт. Это просто факт.
Ну тогда оператор АТС офиса просто ищёт по справочнику номер ближайшей скорой и на своём фрисвиче перебивает 03 на тот номер.
Ну да. Потому и прперебивает, что "Звонок на 03 должен попадать куда надо, а не куда попало".
Ну да. Потому и прперебивает, что "Звонок на 03 должен попадать куда надо, а не куда попало".
Он никуда не попадает. Ещё раз. Вообще. Короткие номера служб не обслуживаются на интернет телефонии. Вы даже с перебивом не сдадите по нормальному такую систему если у вас все телефоны и свичи не заредервированы по питанию и не с классом защиты соответсвенным что бы при пожаре таки соединить с 03.
Он никуда не попадает. Ещё раз. Вообще. Короткие номера служб не обслуживаются на интернет телефонии.
Это повод задавать вопросы "Какого...?" тому, кто это настраивает. Потому что человек не должен думать, интернет это телефония или нет. Как он вообще это узнавать должен? Человек должен хватать ближайшую трубку, слышать гудок и набирать телефон скорой, который он с детства помнит.
А в контексте VoWiFi - тем более. Потому что сотовый телефон считается таким средством.
СОтовый - да. VoWiFI нет. Он буквально не включится если вы к вышке не выйдите. А дальше хоть что. А если выйдете то можно и по вышке кинуть звонок.
страна шагает в свотое будущее
Даже непонятно, опечатка это или так и было задумано.
И кто же не может получать СМС?
Например, у меня в деревне немало зон, где сигнала мобильной сети нет. Я спасаюсь VoWiFi. А вот обладатели телефонов без поддержки VoWiFi такой возможности не имеют. Для бабули в деревне смартфон без поддержки VoWiFi - дело обычное.
Достаточно спорная штука.... например отключили мобильный интернет и кто-то пытается заломиться на госуслуги. Так ты получишь смску, а через макс нет
После окончания тестов эту опцию на коммутационной платформе можно будет подключить всем пользователям «Госуслуг».
*Нужно
Ну, вообще, если рассматривать это все как промежуточный этап отказа от этих SMS вообще (или даже вообще замене телефонных звонков на этот месседжер) - то, может быть и нормально. При большооой такой пачке условий, которые сначала нужно выполнить и придумать.
Судя по ролику, кстати, оно не выглядит именно как чат бот. Больше похоже на локальный генератор, к которому защиту от дурака в виде вопросов прикрутили.
Каким образом можно отказаться от СМС? Ворота и шлагбаумы будут регистрироваться в мессенджере в принудительном порядке?
Даже вне контекста Макса и госуслуг это бредовая идея.
Во-первых, есть довольно большая прослойка пожилых людей, у которых нет смартфона.
Во-вторых, всегда должен быть альтернативный механизм уведомлений на случай отключения интернета. Может, в центре Москвы всё всегда ловит, но когда ты в какой-нибудь МФЦ в подвале приходишь, то там мобильный интернет может и не ловить.
Немного мыслей про развитие "сервиса":
Принудительно загнать людей в приложение
Начать показывать рекламу
Profit
Пока на вход Госуслуг работает нормальный TOTP, пусть они со своим махом идут лесом.
Всех знакомых уже сагитировал и подключил, кроме возрастных, кому тяжело за минуту успеть код посмотреть, переключить приложение и код ввести.
Интересно, как через какое-то время будут обосновывать "опасность стандартного TOTP" :)
Богомерзкий authenticator показывает код кому ни попадя и не задает вопросов, позволяющих выявить злоумышленника?
На мой взгляд, по сравнению с полноценным нормальным TOTP, где пароль сможет сгенероваться и на любом автономном устройстве способном выполнить алгоритм по открытому стандарту RFC 6238, например аппартаном брелоке, или к примеру на отдельном андроидном гаджете не подключенном ни к каким внешним коммуникациям, идея с Максом выглядит мягко говоря не просто не имеющей преимуществ, но и заметно добавляющей проблем по части конфиденциальности и безопастности.
Это лишь попытка всех стариков и лиц, к ним приравненных, пересадить на маху.
На мой взгляд, по сравнению с полноценным нормальным TOTP
Вообще, надо бы тем эксперементаторам, что MAX обнюхивают, посмотреть, не подходит ли этот код, что для привязки показывается, к нормальным генераторам. А то у меня есть подозрение, что это оно и есть. Просто по той причине, что так проще всего сделать - стандартный RFC Госуслуги уже умеют, доработки минимальные.
У меня TOTP в один прекрасный момент не говоря худого слова сломался. Просто перестал пускать. До этого долго работал. Пришлось идти в МФЦ, ничто другое не помогало.
Сломался - всмысле коды неверные стал выдавать? Или просто все коды пропали?
В первом случае - это может быть связано со сбоем времени на устройстве, во втором - надо делать бэкапы кодов, простой xml с ними экспортируется и импортируется во многих приложениях.
Первое - коды перестали подходить. Я проверял время, менял браузеры, пробовал с компьютера и телефона, менял пароль, ждал больше месяца прежде чем идти в МФЦ - ничего не помогло. Я TOTP использую на десятках сайтов и никогда нигде не было проблем.
Бекап у меня был (я из него пробовал восстанавливать). Но вообще большинство сайтов дают запасные коды на случай если что-то случилось, а бекапа нет. Госуслуги не дают.
А вчера в новости про коды подтверждения с пеной у рта доказывали, что бабушки без интернета, поэтому ну никак не введут норму. Просто начать надо с чего-то безболезненно - госуслуг. Вначале на выбор. Потом по дефолту. Потом только так. Потом банки подключатся. А потом можно и отрубить сервисные смс вообще.
Отрубить сервисные смс вообще то давно пора. Особенно это полезно будет для бабушек.
С полноценным нормальным TOTP, где пароль сможет сгенероваться и на любом автономном устройстве способном выполнить алгоритм по открытому стандарту RFC 6238, например аппартаном брелоке по нажатию единственной его кнопки.
Это все очень хорошо. Только у кого-то устройств нет. У кого-то навыков нет. А кто-то просто хочет, чтобы был выбор
Брелоки, уже прошитые учетными данными(нужны будут индивидальный секретный ключ алгоритма RFC 6238 и предварительно синхронизированные часы реального времени) ровно как пластиковые карты обязать банки выдавать, навык нажатия на единственную кнопку брелока, чтобы сгенерировать ОТР-код точно проще чем даже кнопочная звонилка.
У банков уже есть чип с учетными данными. Всем подряд выдают. Вот как бы их заставить использовать его вместо SMS-ок...
Вы ведь банковские карты имеете в виду? Можете пояснить, как их использовать для генерации OTP-кодов? И если это возможно, то как гарантировать, что банальная потеря банковской карты не приведёт к угону аккаунта на Госуслугах?
Можете пояснить, как их использовать для генерации OTP-кодов?
При помощи таких 'калькуляторов'. Но, вообще говоря, сейчас в большинстве случаев даже они излишни. Потому что "приложите карту к телефону и наберите PIN" - вполне достаточно, чтобы чип карты с банком пообщался и убедил его, что эта карта клиента прикладывается.
И если это возможно, то как гарантировать, что банальная потеря банковской карты не приведёт к угону аккаунта на Госуслугах?
Тем, что просто иметь карту на руках должно быть недостаточно. От нее еще PIN надо (не тот же самый, что платежный, разумеется). И, в случае включенной многофактороной аутентификации - надо предъявлять еще что-то, кроме карты.
Благодарю. По поводу угона при утере карты вопрос отпал. А вот что касается самого девайса: штука интересная, но, если я правильно понял, работает он не по RFC 6238. Классические OTP‑приложения всё же выглядят надёжнее: секретный ключ можно поместить куда‑нибудь в менеджер паролей, да хоть сохранить на бумаге с помощью paperkey. А тут — потерял карту и в аккаунт не войти, и нужна другая карта либо топать куда‑то ногами.
штука интересная, но, если я правильно понял, работает он не по RFC 6238.
И (в контексте банков) не надо. Потому что, как я сказал рядом - сами эти коды - костыль. Добавляют совершенно бессмысленный процесс набора каких-то циферок вручную.
А тут — потерял карту и в аккаунт не войти, и нужна другая карта либо топать куда‑то ногами.
Да. Именно так. И это хорошо. "Всегда имейте запасной ключ от сейфа, где деньги лежат, в надежном месте".
Не понял, что хорошего и какой "запасной ключ в надежном месте".
Зарубежная командировка. Потерял смартфон. Ни разу такого небыло, но уверен, даже со мной такое может приключиться.
SMS - практически катастрофа (в моем случае можно было бы порешать, благо симка корпоративная, но все равно жуткие проблемы).
ОТП - да и пофиг (куча бекапов - ноут, планшет, родственники, пусть даже дома у сейфа). Скретч-карты (напрмиер, МКБ выдает вместо СМС) - аналогично (десяток-другой кодов перезаписал в менеджер паролей на разных устройствах). При этом если совсем все профакапил, что ОТП, что скретч карту таки можно в отделении заменить.
Ваш вариант с карточкой к какому сценарию ближе?
Ваш вариант с карточкой к какому сценарию ближе?
К тому, где есть еще одна карточка где-то в тумбочке, которую и достаешь, если одну из них потерял.
Теперь почему это хорошо: потому что если "нет физического объекта-ключа на руках => нет доступа", то это означает, что пока эти объект(ы) у тебя, то мошенники доступа не имеют.
А кто-то просто хочет, чтобы был выбор.
Евросоюз законодательно запретит авторизацию по одноразовым СМС кодам с 14 сентября сего года. Суть проста выбора - наиболее благоприятного и для их мошенников способа уже не будет.
Касательно РФ, то Согласно аналитике ЦБ РФ за истекший 2024 год телефонное и СМС-мошенничество до сих пор преобладает с большим отрывом.
Не подключенный к внешним коммуникациям, выводящий на свой дисплей OTP-код по нажатию едиственной его кнопки, аппаратный токен очевидно безопаснее и смсок и месседжеров и любых других способов отправки каждого одноразового пароля клиенту центральным узлом.
Евросоюз законодательно запретит авторизацию по одноразовым СМС кодам с 14 сентября сего года.
Вы сами читали то, на что ссылку даете? Там "новость" от 2019 года.
С полноценным нормальным TOTP
Только оно, все-таки -- костыль. Аппаратный (да и программная версия, в общем, тоже) брелок может все что нужно по нормальным интерфейсам передать, не заставляя человека набирать циферки, которые еще и мошеннику продиктовать можно, если он жертву уболтает.
Отрубить сервисные смс вообще то давно пора. Особенно это полезно будет для бабушек.
И как в таком случае быть с иностранными сервисами, которыми пользуются россияне? Может не надо преждевременно всех записывать в число бабушек?
Про иностранное - Евросоюз законодательно запретит авторизацию по одноразовым СМС кодам с 14 сентября сего года. Суть проста - выбора способа наиболее благоприятного и для их мошенников уже не будет.
В моем же комментарии имелись ввиду отчественные банки и сервисы, вроде Госуслуг.
Вы правы, в ЕС это уже состоялось
Китайские, американские, да хоть какие кроме ЕС. Восстановить аккаунт и так не просто обычно. Да и одноразовые коды тоже. Сдохло устройство с ними и всё, даже мегу не расшифровать свою.
TOTP key можно сохранить в зашифрованой хранилке паролей, да хоть на бумажке в сейфе. И/или добавить сразу в несколько аутентификаторов на разных устройствах.
С SIM картой даже сложнее.
Госуслуги, по вашему выбору дают Вам ваш секретный ключ для TOPT, а на чем выполнять алгоритм TOPT, с позиции Госуслуг - уже ваша забота.
Например можете купить/сделать аппаратный брелок поддерживающий TOPT и прошить секретный ключ туда.
Можете пользоваться софтом типа "Google-Authenticator".
Можете хоть консольной Oathtool под Linux OPT-пароли генерировать(в последнем случае можно при желании все лично из исходников собрать).
В вашем случае виновать не TOPT, а рукожопый сервис банка. А нарукожопить, при талатнливом сервисе, можно на любом способе генерации/получения паролей.
"Некоторые банки Германии" - это не все банки ЕС. У меня, например, польский банк PKO до сих пор разрешает выбрать авторизацию через мобильное приложение, СМС-коды или TAN-карты.
Только лучше уж аппаратный ключ. Ubikey там, для любителей крипты какой нибудь Ledger. Всеми ими можно заходить на сайты вообще без пароля и угнать ключ авторизации который невозможно извлечь с устройства - та ещё проблема для хакеров. А главное авторизацию через USB порт срочно по телефону не продиктуешь.
Но почему то на госуслугах даже не смотрят в эту сторону. а смотрят почему то в Макс.
Только лучше уж аппаратный ключ... ...Но почему то на госуслугах даже не смотрят в эту сторону...
Не сосвсем так - Госуслуги, по вашему выбору дают Вам ваш секретный ключ для TOPT, а на чем выполнять алгоритм TOPT, с позиции Госуслуг - уже ваша забота, например можете купить/сделать аппаратный брелок поддерживающий TOPT и прошить секретный ключ туда.
Предоставление секретного ключа на Госуслугах, есть даже двумя способами:
1). В виде текстовой строки(собственно сам секретный ключ в формате Base32),
2). В виде QR-кода совместимого с софтом типа "Google-Authenticator" - такому софту нужен не только сам ключ, но доп. инфа(что это ключ для Госуслуг, что это ключ для такого-то логина, что это ключ для алгоритма TOPT).
Мы говорим о разных факторах. Я о первом (которому если честно не нужен второй, потому что подобрать аторизационный ключ весьма сложно) а вы о дополнительном втором.
Не вижу принципиальной практической разницы - и там и там чтобы пройти авторизацю нужно применить аппаратный ключ. В моем случае надо еще пароль помнить, но сути вопроса по необходимости применения аппаратного ключа это не меняет.
Так в этом и разница. С passkey никакой пароль помнить не нужно а аппаратный ключ встроен в мобильник и всё что нужно для настройки - дотронуться пальчиком до считывателя.
В этом смысле да, если все происходит в смартфоне подключенном к внешним коммуникациям, а не в автономном гаджете-брелоке, то взломать и увести аккаунт легче несопоставимо. Тут не поспоришь.
В этом смысле да, если все происходит в смартфоне подключенном к внешним коммуникациям, а не в автономном гаджете-брелоке, то взломать и увести аккаунт легче несопоставимо. Тут не поспоришь.
Кого встренное в телефон хранилище ключей не устраивает - купит внешний. А сайту все равно.
Но в среднем, по массе пользователей, Passkeys таки лучше.
Passkeys это(в том числе) по определению возврат к однофакторной аудентефикации, причем намертво прибитой к внешней инфраструктуре(включая внешние коммуникации) - начиная с генерации(и предачи) секретов третьими лицами "доверенными центрами" и заканчивая применением секретов разными устройствами.
Причем если ваш однофакторный секрет похищен(или скажем легально передан майору местной уважаемой спецслужбы), вам не важно сколько бит его длинна... а других уровней защиты нет по определению.
Passkeys это(в том числе) по определению возврат к однофакторной аудентефикации
Не совсем. Кроме устройства надо таки знать (второй фактор) PIN или предъявить биометрию, чтобы ключ доступа из устройства вытащить.
начиная с генерации(и предачи) секретов третьими лицами "доверенными центрами"
Не путаем с x509 сертификатами. В Passkeys третьих лиц в генерации нет - все решается между сайтом и устройством пользователя.
Передача она же синхронизация - немного проблемна, да. Но на (1) внешние аппаратные атентификаторы не распространяется. (2) Передаются только шифрованные криптоконтейнеры.
И без синхронизации, как показали предыдущие итерации - к массовому внедрению не привлекательна.
Причем если ваш однофакторный секрет похищен, не важно сколько бит его длинна...
Так, в общем, можно и еще факторов добавить, не пуская только по Passkeys.
Если добавляем факторы, то это по сути равноценно хранению и логина с паролем в аппаратном(желательно) токене выполняющем и TOPT.
Нажал на кнопку - получил результат(для совсем ленивых токен может быть подключен к девайсу через который вы ходите на сайт, и заполнить, представивишись клавиатурой, форму аудентификации).
Только тут принципиально нет проблем с синхронизацией устройств и способами бекапа секрета - да хоть на листок бумаги записывайте.
Если добавляем факторы, то это по сути равноценно хранению и логина с паролем в аппаратном(желательно) токене выполняющем и TOPT.
Смотря как 'равноценность' понимать.
Если сайт просит и Passkey и пароль, то злодею нужно и пароль как-то узнавать и телефон, в котором Passkey хранится, красть.
И никаких дополнительных устройств таскать не надо. Для массового рынка - вполне нормально.
Только тут принципиально нет проблем с синхронизацией устройств.
Зато есть проблема с запасными токенами. Даже про Passkeys постоянно спрашивают 'а если телефон потеряешь/утопишь?'.
Это не взлетало.
В результате сделали как сейчас - если не хочешь или не доверяешь синхронизации - берешь внешний токен нужного стандарта.
Если не такой параноик - пользуешься тем чипом-хранилищем ключей, что в телефоне.
Зато есть проблема с запасными токенами. Даже про Passkeys постоянно спрашивают 'а если телефон потеряешь/утопишь?'.
Это не взлетало.
Все сервисы, поддерживающие passkey, с которыми я сталкивался, умели хранить несколько passkey. Т.е. даже если какое-то устройство потерял - зашел с другого, старый убил, новое устройство привязал.
Ну или опять же хранить passkey в хранилке паролей и синхронизировать между разными устройствами.
Все сервисы, поддерживающие passkey, с
Ну вот в passkeys все это прикрутили и рекомендовали. Про что и речь, что сейчас для массового пользователя это стало пригодно к использованию.
Потому что прошлые итерации систем (Чистый webauthn и еще раньше все эти USB токены с сертификатами) - народ упорно считал слишком неудобными и сайты их не внедряли.
Зато есть проблема с запасными токенами.
Маштаб проблемы примерно как флешкой для смартфона - нужно купить стандартную новую и скопировать записать на нее что нужно. Например бекап учетки скопировать.
Если сайт просит и Passkey и пароль
Если сайт просит пароль и одноразовый пароль, то злодею надо еще и либо бекап ключа ТОРТ красть либо гаджет где он есть.
Маштаб проблемы примерно как
Тем не менее - народ пользоваться не хотел. (А сайты, соответственно - внедрять) Пришлось чертыхнуться, вздохнуть и внести возможность синхронизации прямо в стандарты.
Если сайт просит пароль и одноразовый пароль, то злодею надо еще и либо бекап ключа ТОРТ красть либо гаджет где он есть.
Либо просто позвонить пользователю и спросить тотп? Как мы убедились с гос услугами это довольно часто получается.
Либо просто позвонить пользователю
Социальная инженерия да это сила, не привязанная к конкретной технологии. Вариант "Либо просто позвонить пользователю и попросить синхронизировать новое устройство "службы безопасности" ничем ни хуже и не лучше.
На мой взгляд лучше хотя бы тем что пользователь должен физически владеть устройством для синхронизации. И даже если брать в расчёт отправку бекапов максимум злоумышленник получит контейнер зашифрованный твоей биометрией/пинкодом.
Верно заморочиться злодею вначале подольше придеться зато результат в итоге не одноразовый, с ТОРТ этого дзена злодею действуя дистанционно не достичь.
В целом же способа неуязвимого к социальной к социальной инженерии нет, и вряд ли будет.
Если вы мне не абстрактные фразы а рабочий способ приведёте для passkeys - я с вами соглашусь. Пока это выглядит как предложение сбрутфорсить приватный ключ ssl . что в теории возможно конечно, но успешно завершится приблизительно около смерти вселенной.
Если вы мне не абстрактные фразы а рабочий способ приведёте для passkeys - я с вами соглашусь.
Злодей убалтывает жертву сообщить все что надо, чтобы злодей зашел в гугловую учетку жертвы на своем телефоне. Passkey-и синхронизируются. Потом, если сервис их (Passkeys) в качестве второго фактора использует - еще убалтывает рассказать первый фактор (пароль).
В общем, в принципе, можно представить. Но если такое удалось по удаленным каналам - то и уговорить жертву сказать циферки из генератора - тоже получится.
Злодей убалтывает жертву сообщить все что надо, чтобы злодей зашел в гугловую учетку жертвы на своем телефоне.
То есть получает по сути телефон жертвы ещё и в комплекте с её пальцем? попахивает преступлением.
Passkeys это аппаратный ключ внутри телефона и он используется ВМЕСТО пароля. Без него невозможно войти хоть что рассказывай.
о есть получает по сути телефон жертвы ещё и в комплекте с её пальцем?
Если ключики синхронизировались - палец жертвы не нужен. Он же только для локальной защиты. А вот пин, что на экран ставится - этот нужно будет, чтобы криптоконтейнер с ключиками расшифровался.
Отсюда:
When you start using passkeys on a new device, you'll need to know either your Google Password Manager PIN, or the screen lock for your Android device. These recovery factors will allow you to securely access your saved passkeys and sync new ones across your computers and Android devices.
Passkeys это аппаратный ключ внутри телефона и он используется ВМЕСТО пароля.
Ну это как сервис захочет. Почему бы не просить и то и то? Сервисы вроде Госуслуг, по хорошему - должны.
1). Когда выше писал, что Passkeys, как таковое, это возврат к однофакторной авторизации, причем намертво прибитой к внешней "доверенной инфраструтуре", Вы проигнорировали некоторые аспекты, сосредоточившись лишь на рукопожатии "клиент-(конкретный)сервис".
Рад, что Вы сами теперь указали на приватный ключ SSL. Современная "доверенная" эллиптическия криптография вскрывается в лоб(т.е. без всякой социальной инженерии) на домашнем компе минуты за полторы(о чем в т.ч. и на Хабре написано), поскольку бэкдор "для правильных майоров" в любом официально-одобренном государством криптографическом стандарте это правило, а не исключение (например одобренный тем государством, где Родина Сноудена).
2). Если Вы сами предложили, по определению, считать, что и социальная инжененерия рабочий эффективный метод, то обход по классической схеме "человек по середине" тоже будет работать.
3). RFC 6238 описывющий TOPT, это открытый стандарт, а главное - выполнение его алгоритма никак не привязано к "доверенной инфраструктуре". Тут все целиком под вашим личным контролем.
Вы буквально живёте в мире где вы не можете позвонить по VoWiFi потому что если вы 2 часа не регистрировались на вышке товарищ майор не может определить точно ваши географические координаты и отключает вам связь. Пытаться защититься от товарища майора в текущей реальности - заведомо проигрышная стратегия. В конце концов он может выключить ваш TOTP на сервисе просто административно. И ничего ни у кого спрашивать не придётся.
С другой стороны лучше ли Passkey чем TOTP в случае Васи - оператора коллцентра? Несомненно да. Хотя бы потому что после того как он получил бекап вашего passkey (что то же не тривиальная задача) ему ещё нужно подобрать пин, что даёт время жертве отключить passkey от аккаунта. В результате это гораздо безопаснее надиктовки 6 цифр по телефону.
2). Если Вы сами предложили, по определению, считать, что и социальная инжененерия рабочий эффективный метод, то обход по классической схеме "человек по середине" тоже будет работать.
Нет не будет. Потому что как в клаасической криптографии ты либо владеешь закрытым ключом - либо нет. Можно конечно украсть куки, но тут ни TOTP, ни Passkey, ни что то ещё не поможет. И это, ещё раз, гораздо более сложная задача чем звонок по телефону.
3). RFC 6238 описывющий TOPT, это открытый стандарт, а главное - выполнение его алгоритма никак не привязано к "доверенной инфраструктуре". Тут все целиком под вашим личным контролем.
То же самое и с Passkey. Вы путаете Passkey и обычные электронные подписи.
UPD: Стандарты WebAuthn / Client to Authentificator Protocol (CTAP) . Забыл имена написать.
Вы путаете Passkey и обычные электронные подписи.
Passkey как было сказано выше, использует непрозрачные "доверенные источники" используемых в крипто-алгоритме сертификатов, которые, по определению не отвечают принципу безопастности при нулевом доверии, или говоря простым языком, как только в алгоритме появляются непрозрачные "доверенные источники" вас уже поимели, вопрос только хотите ли вы это знать, и каков размер и поименный состав веселой кампании Вас поимевшей.
Потому что как в класической криптографии ты либо владеешь закрытым ключом - либо нет.
В классической криптографии Вы и собеседник синхронизируете ключи вне недоверенной среды, например обмениеваетесь ключами лично. Секрет для TOPT, например получаете в офисе того сервиса, с которым будете работать(МФЦ, офис банка и тд.).
Синхронизируя же ключи по тому каналу, по которому вас потенциально слушают, вы в принципе не знаете какой узел синхронизирует с вами секреты.
Это и есть причина почему алгоритм Диффи-Хеллмана-Меркля уязвим для атаки MitM, “человек посередине” изначально, и был уязвим для неё всегда. Он лишь защищает от прямого перехвата секрета пассивной прослушкой. Как впрочем и все прочие версии его "улучшения".
Сколько именно криптографии Вы навесили на процесс синхронизации секретов(ключей, сертификатов и т.д.) “человеку посередине” участвующему в процессе синхронизации секрета безразлично. Не путайте круглое с зелёным.
Весьма заинтересовало:
Passkey как было сказано выше, использует непрозрачные "доверенные источники" используемых в крипто-алгоритме сертификатов, которые, по определению не отвечают принципу безопастности при нулевом доверии, или говоря простым языком, как только в алгоритме появляются непрозрачные "доверенные источники" вас уже поимели, вопрос только хотите ли вы это знать, и каков размер и поименный состав веселой кампании Вас поимевшей.
Разумеется, я согласен, что теоретически на этапе формирования ключа может некто встрять. И во избежание подобных атак и нужно проверять фингерпринты ssh, картинки при звонке в телеграме и т.п.
Но можно ли на примере показать, где тот самый человек посредине, который меня уже поимел? Не теоретически про особенности алгоритма, а про реальность (совокупность технологий).
К примеру
Я дома, подключаюсь к Github по HTTPS
Создаю passkey, сохраняю
1) Как некто встрянет в мою HTTPS сессию для вмешательства в генерацию passkey?
2) Допустим, я не дома, а на работе, и уменя установлен корпоративный сертификат, специально предназначенный для инспекции моего HTTPS трафика. Тогда админ-злоумышленник может вместо моего отпечатка сообщить гитхабу свой и действительно сможет потом даже без меня подключаться. Вот только когда я попробую из дома этим passkey воспользоваться, гитхаб меня не признает, и все сразу станет явным, я отзову проблемный passkey и создам новый.
И дальше "админ-злоумышленник" даже когда я на работе сможет по-прежнему влезать в мою сессию, но пользоваться моим пасскеем уже не сможет. Сможет выпустить новый в рамках моей перехваченной сессии, но я увижу письмо с предупреждением и т.п...
Т.е. если вмешались в HTTPS сессию (наважно, посередине или прямо на вашей машине троян) - проблема не в технологии passkey. Если же ни трояна, ни левого сертификата - тогда и реальной атаки на passkey не вижу.
Что не так в моих рассуждениях?
1). Принцип безопасности при нулевом доверии исключает сертификаты из непрозрачных для вас "доверенных источников" с недоказанной криптостойкостью. Выше в комментах был пруф на конкретный пример взлома SSL в лоб. Тот конкретный бэкдор для своих, существовавший 10 лет и получивший слишком большую огласку убрали, но и только. Если системы типа Призм, мониторят в реальном времени весь как бы зашифрованный SSL с применением "доверенных сертификатов" трафик по ключевым словам, то дальше пояснять думаю излишне...
2). Человек посредине, если это так сказать независимый компьютерный этузиаст то да со временем вы его заметите. Но до того ущерб вам может быть существенным. Если же это товарищ майор из юрисдикции сервиса, то это вы не будете знать до тех пор пока товарищ майор не сочтёт что можно.
Я довольно подробно описал кейс. Чуть ниже подробно описано, как работает passkeys.
Вы можете по шагам описать атаку на меня, использующего passkeys в реальной жизни?
Не теоретически про особенности алгоритма, а про реальность (совокупность технологий).
Еще раз уточню - троян на вашем компьютере не считается.
Если системы типа Призм, мониторят в реальном времени весь как бы зашифрованный SSL с применением "доверенных сертификатов" трафик по ключевым словам, то дальше пояснять думаю излишне.
Нет, не излишне. Допустим, некто может расшифровать HTTPS трафик между мной и гитхабом, постоянно подслушивает, в т.чю как я регистрирую passkeys.
Что дальше? Как залогиниться с использованием подслушанного имени и пароля я понимаю (в рамках вашего предположения, что-то чудесным образом расшифровывает и подслушивает весь мой траффик). Как он залогинится с использованием моего passkey - не понимаю.
И с этой точки зрения passkey мне видится гораздо безопаснее пароля. Тот можно подслушать в любое время и далее логиниться подо мной. А вот ежели я логинюсь с помощью passkey, не понимаю, как злоумышленник может организовать новую сессию.
Какие-то сложные у вас схемы. Сам ГитХаб уже и так в нужной юрисдикции под крылом Майкрософта и настучит кому надо. Вот если бы дело происходило в начале 2000х, где куча вебмастеров понаделали форумов, и на них ходили и сидели в независимых учётках, и поверх этого взять и натянуть SSL, тогда да, тогда какая-то хитрость нужна. Потом пришло поколение людей, которые думают, что ВКонтакте это и есть Интернет. А когда уже и программисты как будто не подозревают, что можно взять Mercurial вместо Git, а даже если выбрать Git, не подозревают, что можно выбрать не GitHub, да чего тут особо мудрствовать.
Хорошо, но похоже что пруф Вы если и смотрели, то на уровне заголовка.
А важна не только одна частность, что "некто может расшифровать HTTPS", а то что принцип, по которому это делаеться более универсальный.
В основе лежит математический бэкдор, суть которого в том,что генераторы "случайных" чисел "случайны" только для доверяющего непрозрачным "доверенным центрам", вопреки аксиоме, что безопасность должна быть обеспечена и при нулевом доверии. И не стоит пренебрегать этим простым советом Брюса Шнайера и Нильса Фергюсона по практической криптографии, на мой взгляд.
Вашем случае послушав несколько рукопожатий вашей однофакторки с сервисом, имеющий доступ к бэкдору будет знать как ему совершить "легитимное" рукопожатие.
Эта схема будет работать потому, что мы имеем однофакторку привязанную по секретам для криптографии к непрозрачным "доверенным центрам", а именно в таком виде passkey и продвигаеться.
*****************************
Да и несколько нарушив Ваше пожелание всетаки добавлю, что реальный современный смартфон сам по себе безопасной средой выполнения не являеться.
Давайте вспомним, о чем мы дискутируем? Ну чтобы не обсуждать разное :)
В моем представлении - вы утверждаете, что passkey - фуфло, а не защита, ибо 'использует непрозрачные "доверенные источники" ' ну и соответсвенно "вас из-за этого [passkeys] поимели".
Я же утверждаю, что:
Cам по себе passkeys - норм в рамках всего комплекса мер (HTTPS...). Если же у вас не смартфон, а проходной двор, а ваш HTTPS читают всякие призмы - проблема отнюдь не в плохом алгоритме криптографии passkeys.
Более того, даже если ваш HTTPS читают призмы, passkey все равно более надежен, нежели обычные пароли. Ибо пароль можно подслушать и воспользоваться им, а вот приватный ключ passkeys через подслушиваемый HTTPS никогда не передается.
Я охотно верю, что вы читали всякие умные книги. Так опишите конкретный кейс компрометации моего passkeys.
ECDSA (алгоритм цифровой подписи на эллиптических кривых), используемый в passkeys, для генерации пары математически связанных ключей: открытого и закрытого, как и при ssl-шифрование при помощи этих же эллиптических кривых тоже генерирует "случайные числа", обеспечивающие в ECDSA(в теории) невозможность в разумное время восстановления секретного ключа по открытому, который вы шлете через интернет.
Математический бэкдор содержащийся в этих самых эллиптических кривых, которые вам безальтернативно дарованы стандартом, превращает, для тех у кого есть к нему доступ, односторонее преобразование в обратимое в любом алгоритме опирающемся на "доверенную и стандартную" элиптическую криптографию. Например в ECDSA по открытому ключу можно будет восстановить секретный. Ровно как при взломе SSL, где открытый ключ шифрует данные, а соответствующий ему закрытый ключ расшифровывает.
То что описанный по последнему пруфу бэкдор через десять примерно лет, с учетом излишней популярности, прикрыли доказывает, что это годами прекрастно работает на практике, а то что этой версии бэкдора, ставшей слишком известной, (сейчас)нет, никак не доказывает надежность "стандартной" элиптической криптографии ныне - тут все по принципу "Я верю в честность президента и неподкупность постовых, в заботу банков о клиентах, в русалок верю в домовых..."
Т.е. вы так и не хотите описать атаку на мой passkeys (кто злоумышленник, где находится и т.п.). OK.
Хотя и грустно, конечно, оставаться в неведении, чем мне грозит использование passkeys по сравнению с его неиспользованием. Вы же аналогично не доверяете HTTPS, полагаю, что и IPSEC, уверен, вы знаете про "потеряные" сиды Кузнечика и т.п., но при этом вполне используете распространенные решения без собственноручно сделанных добавок.
То, что мир не идеален и не безопасен, я в курсе.
Хорошо, строго формально по сути вопроса, пример атаки:
Шаг первый: злоумышленник пассивной прослушкой получает ваш открытый ключ(или как подвариант доброжелательный товарищ майор поднимает записи вашего трафика за последние шесть месяцев, которые ему предоставляет ваш провайдер).
Шаг второй: имея доступ к математическому бэкдору зашитому в эллиптических кривых, используемых в стандарте для генерации пары математически связанных ключей: открытого и закрытого злоумышленник(или как подвариант доброжелательный товарищ майор) восстанавливает по открытому ключу закрытый.
Шаг третий: имея закрытый ключ злоумышленник(или как подвариант доброжелательный товарищ майор) делает ЭЦП обращения сервера сервиса, а сервер верифицирует это вашим открытым ключом.
Прим. сервису сугубо фиолетово где и как храниться ваш закрытый ключ(сколько и каких пальцев вы прикладываете к смартфону и т.д.) или подписывали вообще не вы, главное что бы подписаная закрытым ключем часть рукопожатия верифицировалась комплиментарным ему вашим открытым ключем.
Шаг второй: имея доступ к математическому бэкдору зашитому в эллиптических кривых,
Или ломает сертификат сайта (восстанавливает его закрытый ключ), tls соединение, встраивается в виде MitM, похищает сессионную cookie и так далее.
Т.е. если мы исходим из таких возможностей атакующего - то возможность атаки именно на passkeys уже не имеет значения.
И использование TOTP вместо passkeys не поможет.
Если Вы про прослушку https сессии, то этот же бэкдор её без влияния на сайт расшифрует. Пруф несколькими комментами выше. Расшифрует в лоб без всяких дополнительных телодвижений, вроде человека посредине.
Алгоритмически там и там эксплуатируеться одина и та же уязвимость ослабленная эллиптическая криптография используемая при создании пары ключей.
Спасибо.
И чем в описанном случае плох passkey?
Без него можно было заполучить мой пароль имея просто записи (достаточно бэкдора чтобы расшифровать мой HTTPS. C passkey надо дополнительно заморочиться еще и бэкдором к нему.
В чем недостаток? Идеальной 100% защиты не существует, это мы помним. Но как passkey в описанном сценарии понижает мой уровень защиты?
Либо я чего то не понял в вашем пояснения либо возможность клонирования вашего закрытого ключа, без взлома вашего хранилища, по данным просто пассивной прослушки трафика вы не считаете за отдельную уязвимость.
Если исходим из предположения, что весь трафик полностью расшифровывается и прослушивается и спасенья нет, просто пароль перехватывается влет. Код для TOTP - аналогично. А вот в случае passkey этого мало. Потребуется еще и его взламывать (иметь еще один бэкдор...).
Поэтому я не считаю использование passkey ослаблением безопасности даже в рамках вашего предположения, что весь мой трафик кто-то смотрит в открытом виде.
Если вы про гарантированное клонирование данных классической однофакторки, прослушкой https трафика так для того ТОРТ и проч. реальная многофакторка, которая между клиентом и сервисом работает и придумана.
Секрет для TOPT, например получаете в офисе того сервиса, с которым будете работать(МФЦ, офис банка и тд.).
Passkeys так же можно, если MitM боишься. Набор байт, что seed для генерации TOTP от набора байтов, что ключевая пара Passkeys -- ничем друг от друга в смысле этой атаки не отличаются.
Кроме того, если настолько боишься "доверенных источников" - то и веб-сервисам ты пользоваться не должен. Вообще почти никакими. Ибо таки да, оно есть механизме сертификатов сайтов. И поэтому ни Passkeys, ни TOTP, ни кабинеты/приложения банков, ни Госуслуги - для тебя мало актуальны.
И, вообще, можно ткнуть в сообщение, которое, утверждается, тут где-то есть, где "Passkey как было сказано выше, использует непрозрачные "доверенные источники" используемых в крипто-алгоритме сертификатов". Доверенный источник - это кто?
Кажется вы не совсем понимаете как работает Passkey. Вот упрощённый алгоритм:
Инициирование логина
Пользователь вводит логин (email / username) на сайте.
Сервер отправляет клиенту (браузеру/приложению) challenge (случайную строку).
Запрос к аутентификатору
Браузер вызывает
navigator.credentials.get()(WebAuthn API).На устройстве ищется passkey, привязанный к домену (например,
example.com).Пользователь подтверждает использование passkey (FaceID, отпечаток пальца, PIN и т. п.).
Подпись challenge-а
Устройство (аутентификатор) берёт приватный ключ, хранящийся локально.
Подписывает challenge + данные о сессии.
Возвращает на сайт:
publicKeyCredential→ в нём есть подпись, ID ключа и информация об аутентификаторе.
Проверка на сервере
Сервер берёт сохранённый ранее публичный ключ пользователя.
Проверяет подпись
Если подпись верна — пользователь аутентифицирован.
Важные моменты
Passkey ≠ пароль — приватный ключ никогда не покидает устройство.
Мультидевайс — современные системы (Google, Apple, Microsoft) синхронизируют passkeys через облако, поэтому ключ доступен на всех устройствах пользователя (всё ещё требует дешифровки контейнера пином).
Фишинг-защита — passkey жёстко привязан к домену (
example.com≠examp1e.com).
Можно применить криптографию от нескольких систем и пожелать удачи тем, кто хотел бы собрать в одном месте правильных майоров от всех задействованных стран
Но почему то на госуслугах даже не смотрят в эту сторону.
Смотрят, вообще говоря. У них есть вход по электронной подписи. Которую можно держать на аппаратном ключе. Которые для ГОСТ-овских подписей.
Всё равно есть разница между получением сертификата в аккредитованном центре за деньги и простого аппаратного ключа
Всё равно есть разница между получением сертификата в аккредитованном центре за деньги и простого аппаратного ключа
Это есть, да. Но совсем параноики - могут воспользоваться.
Так в том то и дело что это не кейс совсем параноиков. Этот протокол встроен в маки, в мобильники (как айфоны так и китайские) в кучу других устройств. Можно подключать аккаратные ключи с этим функционалом. Да даже вконтакт поддерживает такой логин.
И, неожиданно, ты не подберёшь пароль если пароля нет. Не продиктуешь секретный код если нет кода. А у нас борятся с ветряными мельницами вводя всякие "мы вам добавим галку запрет взятия кредита вместо перевода авторизации ваших родителей на схему без паролей уже встроенную в их телефоны". И для меня это максимально загадочно.
Этот протокол встроен в маки, в мобильники (как айфоны так и китайские) в кучу других устройств.
Формулируем правильней и аккуратнее. Passkeys(я так понял, о них речь идет) - да, уже встроен почти везде. Да, к сожалению Госуслуги пока на них не смотрят.
Но просто использование аппаратного ключа у них таки есть. Просто другого. И параноики, которым сколько-то там тысяч рублей на 'флешку' и заказ ЭП не жалко - могут воспользоваться.
В обоих случаях надо куда-то сходить, получить какую-то железку, подтвердить свою личность. Я когда к Госуслугам первый раз подключался, это было в отделении Ростелекома, сейчас как я понимаю, МФЦ. Так и в чём разница между походом в МФЦ и походом в УЦ?
Я вхожу в ГосУслуги только по смарт-карте. Ничего параноидального в этом не усматриваю, просто удобно. Смарт-карта красивая, единичный макет напечатали реверсной термопечатью, наклеили на белую смарт-карту от отечественного производителя ISBC (еСМАРТ токен ГОСТ).
Мне, наоборот, неудобно, когда всякие ГитХабы начинают чего-то мудрить, ещё какие-то устройства, в список которых, как-то так получилось, не вошли PC/SC. А почему нельзя в одном сделать. У многих на смарт-карте может быть AuthentiCode.
Бабушки с интернетом и андроидом ниже 10.0 в пролете.
Даже не знаю, радоваться или огорчаться за таких.
А кто-то может до сих пор со старым яблоком ходить.
P.S. Веб-версия. Про неё я не подумал.
В FAQ на Госуслугах указано это:
3. Если MAX не установлен на телефон — скачайте его. Версия для компьютера не подойдёт: код для входа будет приходить только на телефон
Потому не факт, что веб-версия тоже подойдёт, было бы всё слишком просто. Скорее всего, будут заставлять ставить в виде приложения на телефон, у которого есть постоянный полный доступ к микрофону и камере.
Госуслуги, по вашему выбору дают Вам ваш секретный ключ для TOPT, а на чем выполнять алгоритм TOPT, с позиции Госуслуг - уже ваша забота, например можете купить/сделать аппаратный брелок поддерживающий TOPT и прошить секретный ключ туда. Можете пользоваться софтом типа "Google-Authenticator". Можете хоть консольной Oathtool под Linux OPT-пароли генерировать(в последнем случае можно при желании все лично из исходников собрать).
Лучше бы Webauthn прикрутили, по мне самый удобный способ
Защищает от мошенников. Перед получением кода чат‑бот задаст вопросы, которые помогут выявить злоумышленника. Если ответы вызовут подозрение — он не выдаст код и предупредит об опасности.
То есть, для того, чтобы войти, придётся ещё и на какие-то вопросы отвечать, чтобы этот код получить. А если ответы боту вдруг не понравятся, то придётся идти в МФЦ восстанавливать аккаунт. Спасибо, такого "удобства" точно не надо.
Вчера заказывали справки по клиентам через их гос услуги. Только по одному из пяти вылезла эта шляпа. При этом, клиент утверждает, что никаких махов не устанавливал.
Вся эта "защита" фигня полная. От чловеческого фактора ничего не спасёт.
Минцифры: началось тестирование защиты аккаунта «Госуслуг» через одноразовый код (OTP-код) в мессенджере Мах