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

Захват аккаунта может произойти на трех стадиях:

  1. Вход в аккаунт.

  2. В аккаунт уже вошли и перехватили сессию.

  3. Восстановление аккаунта.

Удостоверься, что ко мне пришел тот же пользователь, что и проходил регистрацию

Задача аутентификации в типичном веб-приложении

1. Вход в аккаунт

Очевидно, чтобы захватить аккаунт, можно предоставить то, чему поверит сервис чтобы нас пустило под нужным пользователем

И мы начали с паролей

С понятного пользователя механизму, известного из давних времен. В самом начале, в 90-е, это неплохо работало. Но после начались проблемы:

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

  • Credential stuffing. Окей, пользователь запомнил один сложный пароль и начал использовать его везде. Злоумышленники начали взламывать менее защищенные ресурсы и использовать пароли на привязанных почтах и других сервисах. Сервисы, для своей защиты, стали выкачивать утекшие базы паролей к себе и блокировать пользователей, запрещая скомпроментированные пароли. Пользователи начали добавлять к своему, старому, сложному, скомпроментированному паролю, "1" или "2" в конец или в начало. Злоумышленники начали делать тоже самое. Дефенсивы тоже начали мутировать утекшие пароли. И так по кругу.

Злоумышленники пытаются запугать пользователей через утекшие базы с паролями. Они заработали более $500,000, https://www.vice.com/en/article/xwk3wq/hackers-sextortion-half-million-blackmail-caught-watching-porn
Злоумышленники пытаются запугать пользователей через утекшие базы с паролями. Они заработали более $500,000, https://www.vice.com/en/article/xwk3wq/hackers-sextortion-half-million-blackmail-caught-watching-porn
  • Борьба с брутфорс атаками. Полностью нерешенная задача ни одной компанией с массовым сервисом. Самый менее затратный, и наиболее действенный способ - это "supercookies", блокировка вообще любых входов кроме как с устройств, с которых уже был вход (trusted devices), имеет недостатки:

    • Очевидное допущение самого существования "supercookie" и подобных устройств

    • Возможность злоумышленнику заблокировать вход в аккаунт с любого другого, non-trusted устройства

    • Блокировка non-trusted устройств должна сниматься и можно аккаунт брутить снова

    • Не работает на протоколах без cookies - например IMAP

  • Фишинг. Браузеры позволяют отправлять один и тот же пароль в разные origin. Само это допущение нужно только для нормального UX, но это несовместимо с безопасностью. Да еще и сами сервисы часто приучают пользователя быть уязвимым - делают кучу форм с вводом пароля на основном домене, на поддоменах, да что там - бывает и на совершенно других доменах второго уровня. Некоторые команды смогли исправить это ужасное допущение прошлого и разместить форму на домене вида auth | account | login .example.com, еще и проставляя куку, что именно на этом домене юзер ввел пароль (мы еще к этому вернемся), но это большая работа.

  • Парольные менеджеры. Ужасный костыль, который мы изобрели, чтобы подпереть им проблемы выше. Массовые сервисы спасет (на сегодняшний день) только принудительная двухфакторная аутентификация для всех пользователей без исключения и мы уже видим, что это работает - например в Steam. Парольные менеджеры так и будут уделом гиков и продвинутых пользователей, которых в самом лучшем раскладе не более 5-10%. Был бы я инвестором, не вложился (или вложился только на краткий срок) в проекты парольных менеджеров.

Я использую 1password, но очень бы хотел этого не делать
Я использую 1password, но очень бы хотел этого не делать
  • Безопасное хранение паролей - сложная инженерная задача, использовать Bcrypt/Scrypt/Yescrypt с "правильным" настройками недостаточно, про это есть хорошая статья. Я с ней не везде не согласен, но, как минимум, обратите внимание на подход проверки пароля без прав select на столбец с хешем пароля, через хранимые процедуры. Этого нет ни в одном из популярных фреймворков для разработки - Wordpress, Django или других, будем считать - что почти никто в мире не хранит пароли безопасно по сей день. И единицы сервисов будут подкручивать коэффециенты хэширующих функций в будущем, поговорим про это в отдельной статье.

И пришли SMS

Первым массовым сервисом с аутентификацией по SMS можно назвать WhatsApp и вход через SMS поменял правила игры. Пользователям - удобно, злоумышленникам стало сложнее (скольких знакомых вы можете назвать, у которых был взломан WhatsApp?). Казалось, страдали только владельцы бизнесов, ибо SMS начали дорожать, операторы хотят хоть как-то на них зарабатывать из-за повального перехода пользователей в мессенджеры. Но тут начинается слух, что и SMS небезопасны! Правда ли это и взламывают ли через них пользователей? Давайте также разберем все способы, как можно перехватить SMS:

Перевыпуск SIM карт

Самый частый способ, который упоминают в дискуссиях. Одним из самых популярных способов перехвата SMS действительно, до сих пор, является перевыпуск SIM карт в салонах связи. Вопрос стоит в сумме взятки или обман консультанта (где потребуются данные паспорта, которые злоумышленники могут найти какими-либо иными способами) и SIM карта готова. Как это пытаются исправить:

  1. Операторы пытаются решить вопрос организационно - усложняя процесс перевыпуска и пытаясь повысить ответственность своих сотрудников. Вполне себе есть уголовные дела после таких “залетов”

  2. Операторы запрещают прием SMS первые сутки-двое после перевыпуска SIM карты. Реальный владелец в этом случае замечает проблему и может успеть вернуть номер себе

  3. Можно мониторить перевыпуск SIM карт через операторов, но это стоит довольно дорого и обычно работает всего для нескольких стран

Перехват SMS при помощи программно-аппаратных комплексов

Этот способ требует от атакующего находиться физически рядом с “жертвой”:

  1. Атакующий находится рядом с жертвой и при помощи SDR слушает эфир.

  2. Атакующий посылает “silent sms” на номер “жертвы” - специальный вид SMS, который приходит на устройство. При помощи него атакующий узнает TMSI (Temporary Mobile Subscriber Identifier) - специальный временный идентификатор, который используется для регистрации абонента в сети.

  3. Атакующий запрашивает SMS, которое нужно перехватить.

  4. SMS приходит на устройство “жертве”.

  5. Атакующему надо быстро расшифровать трафик между базовой станцией и телефоном жертвы - для этого есть готовые бесплатные инструменты, требуется только специально сформированный файл весом в 1.6 ТБ (“радужные” таблицы) и более-менее быстрый компьютер, т.е. уровень типового пользователя.

  6. Готово, SMS расшифровано.

Из минусов для атакующего - “жертва” увидит это SMS. Также сам способ требует заглушить 3G/4G/5G, что не так сложно, но тоже дополнительный шаг. Кстати, про безопасность GSM есть ресурс https://gsmmap.org/, на котором энутзиазисты собирают состояние безопасности по каждой стране и оператору и у кого проще или сложнее перехватить SMS или звонок. Данные не совсем актуальны, но полезно посмотреть сами подходы и аналитику в прошлом. Например, в Сингапуре, 2G полностью отключен с 2021 года.

Атаки через SS7

Про атаки через SS7 было достаточно много статей. Вкратце так - есть система, которую используют по всему миру. Подключившись к ней, т.е. по факту став оператором связи (говорят, стоит 20-50к+ евро) можно сообщать другим операторам связи, что теперь конкретный абонент у тебя в роуминге. И все звонки-SMS направлять к себе. Результат - перехват SMS. Некоторые группировки не покупают доступ, а взламывают операторов, которых много и не все занимаются безопасностью, главная добыча - доступ к SS7.

Malware

Все ясно-понятно. Или iPhone с джейлбрейком с трояном, или Android, где есть приложение, имеющее доступ к SMS, которое все отсылает злоумышленникам.

Экзотические атаки

Примером такой атаки может служить ресерч от shubs из Австралии в 2014 году (https://shubs.io/how-i-bypassed-2-factor-authentication.../). Вкратце:

  1. Запрашиваем на номер жертвы в каком-либо сервисе SMS с TOTP.

  2. Если выждать 30-60 секунд часто появляется кнопка “Не пришло SMS? Позвонить мне и продиктовать код”. Не (!) жмем её..

  3. В этот момент звоним жертве и занимаем номер телефона.

  4. Теперь жмем кнопку на шаге 2 и звонок попадает в голосовую почту.

  5. Подменяем номер телефона на номер жертвы (что стоит $1-$5) и звоним на номер для чтения голосовой почты. Или подбираем пин код к голосовой почте (чаще всего нет рейтлимитов на это, как в статье выше).

  6. Читаем почту, забираем код.

Инфраструктурные уязвимости

Есть приложения от операторов связи, которые позволяют перенаправлять SMS и в них бывают уязвимости (или в сервисах для бизнеса). Разработчики могут случайно залогировать коды из SMS где-нибудь по пути. Также из реальных кейсов - это взлом шлюзов через которые SMS отправляют компании и вся безопасность в итоге сводится к безопасности этих шлюзов. Чтобы эффективно и дешево отправлять SMS всему миру нужно подключить более 30-50 таких шлюзов если у вас популярный ресурс

Но все ли так плохо с SMS? Взломов все-таки становится меньше

1. Вход через SMS - зло и плохо, так делать не надо, их “легко” перехватить

Все потенциальные векторы выше уже доступны для атаки и взлома юзеров на любом популярном сервисе и дают доступ в аккаунт (!). Вы практически везде (естественно, в аккаунте без 2-факторки), при привязанном номере телефона, можете восстановить доступ по номеру телефона, запросить SMS и попасть в аккаунт. Это уже доступно

2. Вроде да, но это требует смены пароля или придет пуш о новом входе (Telegram), будет разлогин (WhatsApp), это более заметно

Сравним импакт. Хоть при логине через SMS, хоть при восстановлении доступа к аккаунту и смене пароля - юзер (или злоумышленник) попадает в аккаунт и получает доступ к данным, разница лишь в несколько секунд и надо в первую очередь думать над этим. Это именно то, что обсуждается в статье.

Чаще всего аккаунт взламывают из-за ненадежного или украденного пароля и их можно спасти входом без пароля, в т.ч. кодом через SMS. Но все же:

  • Это дорого.

  • Не работает в оффлайне.

  • Завязка на чужой инфраструктуре.

  • Остается возможность брутфорса кода, как прямого - брут конкретного пользователя, так и горизонтального - брутфорс миллионов пользователей с одним и тем же кодом. Нужна инженерная работа - например увеличивать длину кода с 6 до 8-9 символов при аномалиях и т.п.

  • Ввод кода все также уязвим к фишингу.

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

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

Вход через почту

Отличный способ, пока вы не сами почтовый сервис :) Но давайте разберем, какие способы входа бывают:

  • Отправка TOTP кода, проблемы:

    • Прямой перебор.

    • Перебор с ротацией IP.

    • Горизонтальный перебор (один код к куче email'ов).

    • Фишинг.

  • Переходим по секретной ссылке из письма с достаточно устойчивым к бруту токеном - логинит во вкладке с этой ссылкой. Проблемы:

    • Отравление Host заголовка (и подмена ссылки, по которой перейдет пользователь).

    • Фишинг (теоретически).

    • CSRF на логин.

    • UX - юзер вообще-то хотел зайти возможно в другом браузере и устройстве.

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

    • Массовая рассылка таких ссылок (IP rotation), кто-нибудь да кликнет, где-нибудь да пустит.

    • Фишинг (теоретически).

Очевидно, что если взломана почта, то взломан аккаунт. Это можно принять на множестве сервисов, и снова, пока вы сами не почтовый сервис.

OAuth

В целом - отличный способ, похожий на предыдущий. Самая частая ошибка при реализации входа через внешний сервис это отсутствие CSRF защиты при привязке аккаунта и что злоумышленник может начать сам привязку и дать ссылку с последнего шага "жертве" и привязать свой аккаунт к аккаунту жертвы. Это описывал Егор еще в 2012, но до сих пор актуально.

FIDO2

Конечно же, абсолютный лидер в плане безопасности:

  • Защищен от фишинга.

  • Защищен от перебора.

  • Удобный.

Но есть множество проблем:

  • Аутентификаторы на девайсах, условный Touch ID на Mac или Windows Hello, работают только как дополнительные устройства для входа. И они не для регистрации аккаунта, они не мобильны. Ситуация c Apple меняется с приходом Apple PassKeys.

  • Переносимые FIDO2 аутентификаторы, условный Yubikey, удел долей процента пользователей интернета. И то, нужно чтобы у юзера на регистрации было бы их два и сразу! Один основной и резервный, если первый утерян или вышел из строя.

  • Оба вида аутентификатора требуют покупки, минимум по 20 долларов за переносимый аутентификатор. Скоро ли мы увидим рядом с заточкой ключей около метро продажу Fido2 ключей? Думаю, что нет.

Apple и Google за последние 3 года сделали многое чтобы популяризировать Fido2, если у вас Pixel (возможно и другие Android устройства) / iOS 16+ устройство с включенным iCloud и синхронизацией keychain - вы уже можете использовать их как переносные Fido2 ключи, но не все так гладко.

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

Мы приравняли проверку кучи факторов, может самых безопасных, к какому-то рандомному токену в Cookie и верим ему на каждом шаге после входа в аккаунт

2. Захват существующей сессии

Как мы видим, текущие механизмы или позволяют легко ошибаться в реализации, или зависят от другой платформы и это не то, что мы хотим видеть как технологию, которая должна быть отчуждена и достаточна сама по себе. Fido2 будет решением, когда покроет 99%+ пользователей. И все же, сессия создана и account takeover может быть сделан через нее. Сессия - какое-то одно или несколько рандомных значений в cookie (или localstorage, для отчаянных людей, которые не боятся XSS)

Session confusion

Одним из моих любых примеров является старый баг из 2000-х некоторых shared хостингов, который может стрельнуть и в современном мире.

  • У вас есть attacker.com, на котором вы заходите под своим user_id=1 и получаете сессию abcdef123456. Сайт находится на shared хостинге.

  • Есть victim.com, который использует такую же CMF/CMS и смотрит на условные поля в сессии user_id, и использует этот же shared хостинг.

  • Мы берем сессию abcdef123456 и подставляем ее в cookie, но уже при запросе на victim.com, получая сессию под нужным пользователем.

Если хостинг не разграничил сессии на каждого клиента мы получаем возможность крафтить сессии между сайтами. Конечно, это пофиксили давно, но вот в этом репорте именно это и случилось. Был партнерский сайт, куда можно было приходить с cookie с основного сайта и натыкаться на случайные, чужие аккаунты. И все потому, что мы почему-то используем рандомные значения для аутентификации после проверки всех факторов

Malware

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

Mitigation-костыли

В итоге все полагаются на сессию и хотели бы защититься от случаев, когда она утекла. В мире придумали самое очевидное решение - sudo сессии. Т.е. на все критичные действия еще раз спрашивать пароль. Ну, про пароли ты мы помним, да? Еще можно редиректить на условный домен account.example.com, в котором мы ставили супер cookie когда юзер вводил пароль, но и это частичное решение проблемы. Скорее, времен HTTP и возможного MitM.

3. Восстановление аккаунта

Сколько вы видели докладов, как правильно делать восстановление аккаунтов?

Сколько вы видели докладов, как ломать восстановление аккаунтов? (Скорее всего, чуть больше)

Ни у кого нет правильной инструкции как правильно восстанавливать аккаунты и не иметь нулевой retention rate и каждый придумывает свое решение.

Интересное чтиво доступно в статье Wired, пусть и 2012 года, но оно актуально до сих пор. Бывают и ошибки в бизнес-логике, например, на одном популярном сервисе можно было менять в cookie step=2 на step=5 и попадать на финальный шаг восстановления аккаунта и менять пароль.

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

Все придумано до нас

Вы можете быть удивлены, но решение большинства проблем векторов 1 и 2 было реализовано в браузерах лет 15 (?) назад. С рядом проблем, конечно же, но все так - это Client Certificate Authentication, которую вы практически не можете встретить в интернете и не встретите ни в одном популярном сервисе. Как это работает?

  • Вы генерируете пару приватный и публичные ключи, и импортируете в браузерное хранилище ключей.

  • При входе на сайт он вам сообщает, что хочет от вас аутентификацию по ключу.

  • Браузер делает хендшейк и каждый ваш последующий запрос аутентифицирует.

Пример запроса сертификата в браузере
Пример запроса сертификата в браузере

Проблемы:

  • Очевидно, UX. Откуда этому ключу взяться? Надо его сгенерировать (так, к слову, делает старый и добрый клиент TeamSpeak3).

  • Нет возможности разлогина. Т.е. выбрали сертификат и все - браузер будет тупо его использовать каждый раз, сбросить состояние можно только через настройки, открытие incognito или полный перезапуск браузера. Прямо как basic auth, как аутентифицироваться придумали, а разлогин - забыли.

  • Malware. Пока ключ на файловой системе его можно своровать, но уже можно использовать, например, Yubikey и троян не сможет своровать ключ. Еще бы поддержку встроенных HSM, надеемся и она скоро будет.

Какой крутой способ, мы почти у идеала. Проблемы еще есть, но мы бы могли их решить

Keyless Certificate Authentication

Анализируя все проблемы безопасности и UX кажется очевидным, что все, что нам нужно, чтобы все-таки предотвратить в некотором максимуме проблему захвата аккаунта, это совместить все лучшее, что мы уже умеем:

  • Превратить каждое мобильное устройство не в FIDO2 ключи, а в генератор TLS тикетов, на подобии как работает Keyless SSL в Cloudflare. Хранить приватный ключ в HSM (есть в любом современном девайсе) и передавать эти тикеты на PC, если нужно. Мы уже научились в похожий механизм в Paywave/Paypass при оплате картой с телефона или часов.

  • Реализовать заголовок в браузерах вида Extension-Policy: none, который будет запрещать использовать расширения которые имеют право вмешиваться в текущий Origin, хотя бы на конкретных страницах.

  • Конечно же, это все должно работать origin-based и быть устойчивым к фишингу.

Представьте себе мир, в котором нет брутфорса, сложно ошибиться как разработчику сервиса в аутентификации пользователя, каждый запрос пользователя аутентифицирован тем же фактором, при помощи которого был вход в аккаунт и пройдена регистрация. Трояны все еще могут попасть в аккаунт пользователя, но только на то время, пока троян запущен на устройстве пользователя, но и с инжектом в соседние процессы усиливается защита со стороны разработчиков ОС. Когда-нибудь мы увидим этот мир, но когда? Не знаю, делать прогнозы - дело неблагодарное, а пока нам нужно работать с тем, что умеет браузеры и что нам дали Google, Apple и Microsoft.

Комментарии (32)


  1. askv
    22.11.2022 11:40
    +1

    Я с точки зрения пользователя.

    Простые пароли использую только в тех местах, взлом которых не принесёт ущерба. Соответственно, в важных местах пароли уникальные и более сложные. То есть взлом сайта какого-нибудь магазина не скомпрометирует пароль для входа в интернет-банк, например.

    Контрольные вопросы стараюсь не заводить - это раскрытие дополнительной информации о себе, которую вряд ли стоит раскрывать. Можно воспринимать их как ещё один пароль и записывать вместе с паролями, если сервис всё-таки принудительно требует их ввода.

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

    Плохо, что контрольные вопросы чаще всего нельзя удалять из системы.


    1. BeLove
      22.11.2022 11:51

      В целом нормальный подход, лишь бы в этих магазинах не было бы адреса доставки, последних 4 цифр номера карты или подобного, неприятно если это информация где-то будет опубликована или хуже - может быть использована для общения с саппортом при восстановлении аккаунта. Например как в упомянутой статье Wired 2012 года.

      Контрольные вопросы - это зло, от которого должны избавиться все сервисы. Чаще всего это еще один фактор, как юзер может быть скомпроментирован.

      Для себя, где нельзя пропустить их - генерирую рандомные строки и сохраняю их в парольном менеджере.


      1. askv
        22.11.2022 12:06

        Карты стараюсь нигде не сохранять. Вот к сожалению Утконос их принудительно сохраняет (правда всё равно нужно вводить CVV потом) и ещё убрал вход по паролю и сделать только по смс. Это раздражает. Сейчас многие увлеклись входом по смс и убрали пароли. Может быть для всяких магазов это и норм, не знаю.

        Даже в МТС я раньше входил по паролю в личный кабинет, но в какой-то момент они почему-то сделали мне вход только через смс (хотя пароль у меня есть). Поддержка не помогла - я так понял, они даже не смогли понять, в чём именно состоят мои затруднения (я не могу получить смс, т.к. симка стоит в планшете). Пришлось в итоге перетыкать симку в телефон, заходить в ЛК и менять способ входа снова на пароль. В какой момент они без меня решили это изменить - не знаю.

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


      1. askv
        22.11.2022 12:17

        Учитывая, что все эти адреса регистрации и так покупаются, то компрометация магазина уже не выглядит такой уж существенной.


  1. aik
    22.11.2022 12:58

    Парольные менеджеры так и будут уделом гиков и продвинутых пользователей

    Встроенными в браузеры парольными менеджерами пользуются и домохозяйки.
    Вход через SMS — зло и плохо, так делать не надо, их “легко” перехватить

    Только если идёт адресная атака на конкретного человека. Я не представляю, как можно массово читать чужие смс, не являясь оператором связи или оператором аппаратуры СОРМ.
    Ну разве что удалось затроянить несколько сотен тысяч устройств.

    А всё остальное слишком сложно для «домохозяйки». Я, к примеру, не люблю использовать аппаратные ключи или телефонные аутентификаторы для повседневных сервисов. Потому что если вдруг остался без устройства — начинаются проблемы.


    1. inkelyad
      22.11.2022 13:31

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

      <Задумчива глядим на обычные физические ключи от квартиры>
      Можно же к ключам от сервисов относится так же. И это даже в забитую в голову модель "ключ от квартиры, где деньги лежат" укладывается. Проблема только в том, что аппаратные ключи не лежат кучками в свободной продаже подобно тому, как дверные ключи и замки продаются.


      1. aik
        22.11.2022 13:54

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

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


        1. inkelyad
          22.11.2022 13:57

          И если бы второй фактор я мог размножить в нужном количестве копий

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

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

          А точно есть привязка? Например, что гугл, что микрософт подтверждение запрашивает на всех устройствах, куда дотянуться могут. Может и стим будет так же делать, если его приложение на нескольких устройствах поставить?


          1. aik
            22.11.2022 14:14

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

            Да даже не в резерве, а просто на работе второй ключ положить хотелось бы.
            Может и стим будет так же делать, если его приложение на нескольких устройствах поставить?

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


        1. Aelliari
          22.11.2022 14:59

          С U2F там же by design рекомендация иметь на всякий случай ещё один токен, да и IT-гиганты внедрившие поддержку дают возможность добавлять по нескольку токенов сразу


  1. makkarpov
    22.11.2022 13:05
    +1

    Реализовать заголовок в браузерах вида Extension-Policy: none, который будет запрещать использовать расширения которые имеют право вмешиваться в текущий Origin, хотя бы на конкретных стстраницах

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


  1. Aelliari
    22.11.2022 13:27
    +1

    Превратить каждое мобильное устройство не в FIDO2 ключи, а в генератор TLS тикетов

    Стоп, а зачем? FIDO2 уже сам по себе своего рода система использующая условно "клиентские сертификаты", которые ещё и генерируются локально


    1. makkarpov
      22.11.2022 13:31

      Судя по всему, для сильной привязки сессии к конкретному соединению, чтобы нельзя было украсть сессионный токен. Но если делать так, то я бы предложил анонимные клиентские сертификаты, которые уже сервер ассоциирует с сессиями и пользователями.

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


      1. BeLove
        22.11.2022 14:25

        Судя по всему, для сильной привязки сессии к конкретному соединению, чтобы нельзя было украсть сессионный токен.

        Именно так. И пока малварь на машине - да, проблем много, но ключ нельзя достать, если он в HSM.


        1. makkarpov
          22.11.2022 14:40

          Так его и не обязательно доставать, малварь вполне может работать оракулом. Достаточно один раз установить TLS-соединение, чтобы послать через него произвольное количество запросов.

          Плюс ваш подход смешивает два слоя - слой аутентификации и слой транспорта. В FIDO, насколько мне известно, TLS connection ID участвует в подписях. Потому привязка самой первой аутентификации к каналу уже присутствует. Осталось добавить анонимные TLS-сертификаты на устройстве - и вот решение, где эти слои идут строго отдельно. Сервер запоминает, что юзер аутентифицировался с таким-то сертификатом, и не дает использовать сессию, если сертификат не совпадает.


    1. inkelyad
      22.11.2022 13:39

      Тут разница в том, как эти сертификаты используются. В FIDO эти сертификаты и протоколы- отдельно, а те что работают в TLS - отдельно.Тут предлагается совместить.

      Я, кстати, тоже не до конца понимаю, почему всякие идентификаторы сессии передаются внутри http заголовков, а не используется те, что в процессе TLS хэндшейка получилась. Когда-то была отговорка, что TLS может не быть. А сейчас оно уже совсем не так.


  1. skozharinov
    22.11.2022 16:46

    Вот только не надо двухфакторной аутентификации как в Steam. У меня в менеджере паролей 300+ записей, ну даже если все сервисы не считать, в приложении-генераторе кодов TOTP 50+ записей. Если 50 сервисов вдруг решат, что для 2FA нужно установить их приложение, телефон превратится в помойку, а процедура смены устройства будет не сильно проще, чем с тем же YubiKey. Ещё хуже — если 2FA такого вида сделают все 300 сервисов.


    1. snaiper04ek
      22.11.2022 18:15

      Как в стиме вряд ли будет. Хотя, да, не хотелось бы повторения истории с игровыми лаунчерами по 200-500 мегабайт оперативки каждый, но только лаунчеры плодились не от хорошей жизни, а потому что компании не хотели делиться со стимом на столько большим, по их мнению, процентом с продаж за использование сервиса.

      Двухфакторкой стим решал свою проблему с массовыми угонами аккаунтов, и было очень давно. Способ с подтверждением на почту не идеален, акки продолжали угоняться, а гуглу верить что сервис его аутентификации не закроется через пять нансоекунд - быть оптимистом. Самый очевидный способ - поднять свой сервис по двухфакторной аутентификации. Напоминаю, до майкрософт аутентификатора оставалось около 5 лет.

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

      И даже так, у товарища где-то год назад угнали акк стима и слили с него предметы. Двухфакторка стояла у него всё время с введения ограничений (около 5-6 лет назад). Со слов товарища, возле компьютера его не было чуть больше 4х часов. Техподдержка послала лесом, потому что двухфакторка безупречна, всем известная же истина...


      1. inkelyad
        22.11.2022 18:18
        +1

        Самый очевидный способ - поднять свой сервис по двухфакторной аутентификации. 

        Но можно было использовать стандартные алгоритмы генерации, а не изобретать собственный, который только в их приложении есть.


      1. skozharinov
        22.11.2022 19:22

        В обязательной двухфакторке нет ничего плохого, но можно было сделать стандартный TOTP, а не своё собственное решение. Насколько я помню, всякие пуши и подтверждения по клику в Steam Guard появились далеко не сразу. Да и можно было сесть и разработать стандарт для двухфакторки с пушами и прочим (вроды бы такое даже есть, если не ошибаюсь — Authy, но поддерживает такое примерно полтора сайта, и встаёт вопрос об аутентификации в нём самом).


        1. XenRE
          22.11.2022 23:52

          Если двухфакторка полагается на сторонний сервис (а в 99% это так) — это офигенный способ распрощаться с аккаунтом просто потому что ты по факту не владеешь собственными ключами.


          1. skozharinov
            23.11.2022 00:07

            От потери аккаунта при утечке защитит end-to-end шифрование, а от потери при внезапной смерти стороннего сервиса — длинный код восстановления, который можно положить в сейф.


            1. Tarakanator
              23.11.2022 08:37

              Проблема в том, что к примеру trezor не предоставляет возможность создания кода для восстановления паролей.


              1. skozharinov
                23.11.2022 08:44

                Это должн обеспечивать сервис, для которого подключается 2FA. А невозможность вытащить что-либо из хардварных аутентификаторов вообще by-design.


                1. Tarakanator
                  23.11.2022 09:14

                  Ой, что-то я контекст упустил. Я про менеджер паролей, а не 2fa.
                  2fa... вроде сейчас самый популярный гугл аутентификатор? а он позволяет делать экспорт\импорт кодов офлайн через qr код.


                  1. vikarti
                    25.11.2022 08:37

                    С каких это пор он такое позволяет?!
                    У меня в свое время как раз была проблема как такое сделать без рута.


                    1. Tarakanator
                      25.11.2022 09:08

                      я постараюсь не забыть и сегодня вечером проверить. Если забуду не стесняйтесь напомнить.


                    1. Aelliari
                      25.11.2022 09:10

                      Он вроде бы больше не OpenSource старые исходники все ещё доступны, но сам изменился.


  1. Squoworode
    22.11.2022 19:25
    +9

    Самое главное, что не очевидно неспециалистам с первых строк статьи:

    FIDO2 - это не гипертекстовый векторный фидонет.


  1. noavarice
    24.11.2022 12:44

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

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


    1. Aelliari
      24.11.2022 17:21

      Passkey и использование FIDO2 U2f как единственного фактора (U2f изначально много надёжнее паролей) должны решить эту проблему. U2f решает проблему паролей, при чем решает её очень хорошо, passkey решает проблему наличия аппаратного токена.


  1. vikarti
    25.11.2022 08:31

    Реализовать заголовок в браузерах вида Extension-Policy: none, который будет запрещать использовать расширения которые имеют право вмешиваться в текущий Origin, хотя бы на конкретных страницах.

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


    Конечно можно конкретно эту проблему решить как в хроме с его Manifest V3 (передачей списков на блокировку браузеру)