Comments 28
А всё-таки, есть какой-то способ верифицировать подобный способ создания резервных копий? Например, для начала опубликоваться в реферируемом журнале, потом попробовать получить отзывы криптографов с именем? А там глядишь и до промышленного стандарта недалеко, когда другие фирмы поддержат.
Я так понимаю что ваша оригинальна статья была написана в 2018 и много поменялось с тех пор *)
Вот что я могу сказать по поводу сегодняшних решений:
- Второй аутентификатор в сейфе, лучше всего
- Все ваши андроиды и виндоусы теперь FIDO2 аутентификатор
- Делегированное востановление https://developers.facebook.com/docs/delegated-recovery
- WebAuthn backup extension в разработке https://gist.github.com/emlun/4c3efd99a727c7037fdb86ffd43c020d
много поменялось с тех пор
1. Второй аутентификатор в сейфе, лучше всегоЭто разве что-то новое? Такой подход считался лучшим решением для бэкапа в 2018, и считается до сих пор; хотя это и не принято считать проблемой. В статье я аргументирую, почему мне это не нравится, и предлагаю лучшее решение.
2. Все ваши андроиды и виндоусы теперь FIDO2 аутентификаторДело предпочтений, но я лично стараюсь воздержаться от использования телефонов и ноутбуков в качестве аутентификаторов; маленький USB-токен, который почти всегда при мне, вместе с другими ключами, и достается гораздо реже, чем телефон или ноутбук — более надежное решение.
По поводу остального — не вижу, как это делает материал в статье менее актуальным. И делегированное восстановление, и WebAuthn backup extension требуют поддержки со стороны Relying Party (RP), то есть сервисов, и в итоге сервисы могут поддерживать такое восстановление, а могут и не поддерживать. То есть, мы будем просто иметь больше неуниверсальных методов восстановления.
В статье же предлагается решение, совершенно независимое от сервисов; которое можно применить уже сегодня, и оно сразу оказывается рабочим для абсолютно всех сервисов, поддерживающих U2F.
Хм, идея зачетная, но я вижу здесь одну проблему — невозможность теста бекап ключа. Закапывая его в огороде можно только молиться, чтоб он оказался рабочим… Я бы не смог спать спокойно с таким бекапом.
Самое первое, что нужно сделать — это протестировать оба токена на demo.yubico.com/webauthn-technical: регистрируем основной токен, потом аутентифицируемся с ним же, проверяем, что
signatureCounter низкий (видно, если раскрыть «Technical Details -> Response from the Relying Party»), потом аутентифицируемся с бэкап токеном, убеждаемся, что это работает, и что signatureCounter высокий.После этого можно удостовериться, что все работает и на настоящих сервисах. Берем какой-нибудь сервис (например, Google), добавляем туда основной токен, выходим, аутентифицируемся с основным токеном, выходим, аутентифицируемся с бэкап-токеном (убеждаемся, что это работает), выходим, пытаемся аутентифицироваться с основным токеном (убеждаемся, что это НЕ работает, т.к. бэкап уже засветился), после чего аутентифицируемся с бэкап-токеном, отзываем токен, и добавляем его заново (основной токен, конечно).
Я провел такую процедуру на нескольких сервисах, и для меня это было достаточным доказательством работоспособности бэкапа в принципе, так что я мог со спокойной душой его закапывать / замуровывать итд. Единственное, что не гарантируется — это аннулирование основного токена после использования бэкапа (т.к. сервис может игнорировать
counter), но сам бэкап будет работать на всех сервисах.Похоже, ваша ссылка работает только с yubi ключами, мои google titan ключи не прошли.
По поводу проверки с отзывом и перерегистрацией — да, это сработает, но нужны доп шаги. Если мы говорим о сколь-нибудь серьезной стратегии бекапов, то обязательно предусматриваем регулярную проверку. А это противоречит концепции замуровывания в стену.
Похоже, ваша ссылка работает только с yubi ключами, мои google titan ключи не прошли.Работает с моими u2f-zero. А что конкретно означает «не прошли»?
По поводу проверки с отзывом и перерегистрацией — да, это сработает, но нужны доп шаги. Если мы говорим о сколь-нибудь серьезной стратегии бекапов, то обязательно предусматриваем регулярную проверку. А это противоречит концепции замуровывания в стену.Вообще говоря, что именно делать с бэкап-токеном — каждый решает сам, со всеми вытекающими; и эта свобода (и, конечно, ответственность) мне нравится. Если есть желание периодически его перепроверять — можно держать его в сейфе, и это все равно (для меня) было бы значительно лучше, чем независимый токен, т.к. я совсем не хочу добавлять бэкап-токен вручную на каждый сервис.
Плюс к этому, в соседней ветке обсуждаем Trezor — если с ним все сработает, то я рассматриваю «замуровать в стену» не только девайс, но еще и seed phrase набитой на металлической пластине. Таким образом, даже если с девайсом по прошествии лет что-то случится, то все равно будет возможность его восстановить из seed phrase (можно было бы этим seed и ограничиться, но никто не знает, что станет с этой компанией Trezor впоследствии и насколько легко можно будет купить новый токен, так что предпочитаю просто иметь готовый бэкап-токен)
У этих ключей есть более глобальный недостаток — многие сервисы их не поддерживают.
Все ключи делятся на свои подзадачи. И один мастерключ, единственная задача которого менять другие ключи в случае необходимости. Далее ключи авторизации и других подзадач записываются на U2F.
— U2F токен основной.
— ламинированный листок бумаги в сейфе с приватным 64 символьным мастер-ключом.
К сожалению распространенных стандартов на такую схему нет. Только самодельные решения.
device_secret и константу для увеличения counter в U2F-токен было бы очень здорово, и это именно тот уровень поддержки от производителей токенов, которого я бы хотел видеть, рано или поздно. Опять же, не нужно будет доверяться производителям в том, что они не хранят у себя ключей.Такая возможность не решает вашей задачи иметь несколько ключей по подзадачам, но устраняет источник риска в виде электронного устройства.
(Только для хранения ключа (
device_secret) вместо ламинированного листка бумаги я бы использовал что-то вроде этого + punch kit)
Уже придумано в Trezor. Мастер ключ создаётся на основе seed phrase (по BIP39), но можно ещё вводить дополнительный пароль каждый раз, когда используется токен. Это даёт неограниченное количество разных ключей, для любых подзадач/проектов.
Еще момент по передаче ключа… я бы авторизацию сделал по одноразовой сессии асиметричного шифрования. Сервис подписывает пабликом id сессии, запись поступает в токен, тот подписывает ответ приватником. MITM в таком варианте не страшен вообще. Пусть хоть злоумышленник root имеет на компе.
UPD
Вижу u2f туда завезли.
Это не «крипта», а аппаратный токен, получающий какие-то данные на вход и выдающий подпись для этих данных в разных форматах и для разных целей. В частности, он работает как стандартный U2F токен.
Там всё открыто и opensource. Даже можно спаять дома самим железку — схема открыта, комплектующие доступные. Весь их сайт это лишь обвязка к приложению в браузере, которое, в свою очередь, общается с токеном. Ключ хранится только в токене и нигде больше.
Вы Trezor пробовали? Он, помимо всего прочего, может работать и как U2F токен. Бэкап-восстановление, смена счётчика, opensource.
Что ж, спасибо за полезный комментарий! Похоже, заказываю Trezor.
А как в него зашить свой device_secret?
device_secret будет выведен из seed phrase.
Интересно, но форм-фактор у этого девайса не выглядит удобным для ежедневного использования по сравнению с тем же yubico, нет?
- Если Trezor также используется и по своему самому популярному предназначению (cryptocurrency hardware wallet), то использовать его еще и как аутентификатор уже не так неудобно
- Для меня лично, лучше не самый удобный форм-фактор с бэкапом, чем удобный без бэкапа. Пока что я вообще продолжаю u2f-zero пользоваться, но Trezor интересен т.к. предлагает бэкап из коробки.
А ещё, помимо крипты и U2F, Trezor может также генерировать EC ключи для ssh и GPG (https://github.com/romanz/trezor-agent).
Для большего удобства его можно подключать через китайские кабели/переходники с магнитом. И разъём прослужит дольше.
Тот который в кармане можно легко забыть дома, в другой одежде вместе с банковскими карточками и прочими необязательными вещами. Наличие доступного бекапа под рукой очень спасало.
Вообще, все зависит от модели угроз, у меня вероятнее всего:
Забыть токен дома
Потерять токен
Сломать токен
Передать токен незаинтересованным лицами (гопники)
Передать токен заинтересованными лицами (хакеры-гопники)
Разлочить менеджер паролей, передать токен и показать как этим пользоваться (мировые правительства)
Почему-то многие считают, что забыть токен когда он тебе нужен — не угроза, когда это вполне себе угроза доступности, которая является частью безопасности.
Надежный, безопасный и универсальный бэкап для U2F