Pull to refresh

Comments 33

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Sign up to leave a comment.

Articles