что такое валидация токена

Что такое игра валидаторов или “как запустить proof-of-stake блокчейн”

Итак, ваша команда закончила alpha-версию вашего блокчейна, и пришло время запускать testnet, а затем и mainnet. У вас настоящий блокчейн, с независимыми участниками, хорошей экономической моделью, безопасностью, вы спроектировали governance и теперь пора бы попробовать все это в деле. В идеальном криптоанархическом мире, вы выкладываете в сеть genesis block, окончательный код ноды и валидаторы сами все запускают, поднимают все вспомогательные сервисы и все случается само собой. Но это в выдуманном мире, а в реальном, команда должна подготовить довольно много вспомогательного софта и различных манипуляций чтобы помочь валидаторам запустить устойчивую сеть. Об этом данная статья.

Запуск сетей на базе консенсусов типа “proof-of-stake”, где валидаторы определяются голосами держателей токенов системы является довольно специфическим мероприятием, ведь даже запуск традиционных, централизованно управляемых систем с десятками и сотнями серверов сама по себе непростая задача, а блокчейн нужно стартовать усилиями лояльных, но независимых участников. И, если в корпорации, при запуске администраторы имеют полный доступ ко всем машинам, логам, общему мониторингу, то валидаторы никого не подпустят к своим серверам и, скорее всего, предпочтут строить свою инфраструктуру самостоятельно, ведь она контролирует доступ к основным активам валидатора — стейкам голосующих. Именно такое поведение позволяет строить распределенные безопасные сети — независимость используемых облачных провайдеров, виртуальных и “baremetal” серверов, разные операционные системы, все это позволяет сделать атаки такой сети крайне неэффективными — слишком много разного софта используется. Например в Ethereum используется две основных имплементации ноды, на Go и на Rust, и атака, эффективная для одной имплементации не работает для другой.

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

Валидаторы

Давайте представим себе запуск гипотетического современного блокчейна (большая часть описываемого подходит для блокчейнов на базе любого современного семейства блокчейнов: Ethereum, EOS, Polkadot, Cosmos и других, в которых предусмотрен консенсус proof-of-stake. Главными действующими лицами таких блокчейнов являются команды-валидаторы, занимающиеся установкой собственных независимых серверов, валидирующих и производящих новые блоки, и получающие награды предусмотренные сетью для тех, кто участвует в консенсусе. Для запуска новых сетей требуется несколько десятков валидаторов (столько сейчас могут более-менее эффективно достигать консенсуса за секунды), поэтому проект объявляет регистрацию, при которой валидаторы делятся публичной информацией о себе с пользователями, убеждая их в том, что собираются качественно обслуживать запускаемую сеть.

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

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

Проблемы запуска блокчейна

Открытость блокчейна, сделавшая возможным свободное участие в работе сети компьютеров из любых стран и простота подключения к сети любого script kiddie по инструкции на GitHub не всегда является преимуществом. Погоня за новым токеном часто заставляет валидаторов “помайнить новую монетку на старте”, в надежде на рост курса и возможность быстро скинуть заработанное. Также, это означает, что вашим валидатором может быть кто угодно, даже аноним, за него можно так же голосовать, как и за других валидаторов (правда, анониму будет трудновато собрать за себя голоса стейкхолдеров, так что страшные сказки про анонимные криптовалюты оставим политикам). Тем не менее

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

Команда готова голосовать в mainnet за любых валидаторов, вот только знать бы за каких, какие хорошие? Самым большим портфолио? Его сейчас почти ни у кого нет. По профилям команды в Linkedin? Опытных девопсы или безопасники не будут вам давать никакие профили в Linkedin. По заявлениям в чате, постам и помощи другим на этапе подготовки? Хорошо, но субъективно и неточно.

Game of Validators

Я опишу игру валидаторов так, как мы проектировали ее для блокчейна DAO.Casino (DAOBet) на основе форка EOS, который называется Haya и имеет близкий механизм governance — валидаторы выбираются голосованиями с любого аккаунта, при котором часть баланса, которым голосуют за валидатора замораживается. Любой аккаунт, имеющий на балансе основной токен BET может проголосовать за выбранного валидатора любой частью своего баланса. Голоса суммируются и по итогам строится top валидаторов. В разных блокчейнах этот процесс организован по-разному, и обычно именно в этой части новый блокчейн отличается от родительского, и, надо сказать, что в нашем кейсе EOS полностью оправдывает “OS” в своем названии, мы действительно используем EOS как базовую операционную систему для разворачивания модифицированной версии блокчейна под задачи DAOBet.

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

Как выбрать top победителей?

Главное техническое требование к игре — чтобы ее результаты были публично проверяемы. Это означает, что результаты игры: TOP победителей, должен быть сформирован строго на основе данных, которые может проверить любой участник. В централизованной системе мы могли бы измерять “uptime” каждого валидатора и награждать тех, кто больше был online или пропустил через себя максимум сетевого трафика. Можно собирать данные о загрузке процессора, памяти и наградить тех, кто достойно трудился. Но любой такой сбор метрик означает существование центра сбора, да и ноды все независимые и могут вести себя как хотят и отправлять любые данные.

Поэтому естественное решение — победители должны определяться по данным из блокчейна, так как по нему можно увидеть кто из валидаторов какой блок произвел и какие транзакции в него были включены. Мы назвали это число Validator Points (VP), и их зарабатывание и есть основная цель валидаторов в игре. В нашем случае, самой простой, легко публично проверяемой и эффективной метрикой “полезности” валидатора является VP = число_произведенных_валидатором_блоков за заданный временной период.

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

У других блокчейнов, способ подсчета Validator Points может отличаться, к примеру для pBFT-based консенсусов(Tendermint/Cosmos, консенсус Aura из Parity Substrate), где каждый блок должен быть подписан множеством валидаторов, имеет смысл считать отдельные подписи валидаторов, а не блоки, возможно, имеет смысл учитывать не завершенные раунды консенсуса, которые тратят ресурсы других валидаторов, в общем это сильно зависит от типа консенсуса.

Как смоделировать реальные условия эксплуатации

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

Запрос токенов с faucet и голосование валидаторов все таки не до конца честно эмулирует работу БЧ, особенно в крайне нагруженных режимах. Поэтому команде блокчейна все равно так или иначе придется писать добавочные бенчмарки, позволяющие нагрузить сеть. Особую роль в этом играют специально созданные заранее смарт-контракты, позволяющие протестировать отдельную подсистему. Для тестирования storage, контракт сохраняет в блокчейн случайные данные, а для проверки сетевых ресурсов тестовый контракт требует большой объем входных данных, тем самым раздувая объем транзакций — запуская поток таких транзакций в произвольные моменты времени команда одновременно тестирует стабильность кода и стойкость валидаторов.

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

Как информировать участников о состоянии сети и чинить ошибки

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

Важные моменты по проведению игры валидаторов

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

Раздать весь призовой фонд в соответствии с заработанными VP

Раздать призовой фонд top-N валидаторам по итогам игры

Какому варианту отдать предпочтение — дело ваше

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

Заключение

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

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

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

Источник

Идентификация клиентов на сайтах без паролей и cookie: заявка на стандарт

Уважаемые Хаброжители! Уважаемые эксперты! Представляю на вашу оценку новую концепцию идентификации пользователей на веб-сайтах, которая, как я надеюсь, с вашей помощью станет открытым интернет-стандартом, сделав этот интернет-мир чуточку лучше. Это вариант черновика протокола беспарольной идентификации, оформленный в виде вольной статьи. И если идея, положенная в его основу, получит от вас, уважаемый читатель, положительную оценку, я продолжу публикацию его на reddit.com и rfc-editor.org. И надеюсь, мне удастся заинтересовать в его реализации разработчиков ведущих браузеров. Потому ожидаю от вас конструктивную критику.

Внимание: очень много текста.

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

С одной стороны, сайтам необходимо узнавать клиента, чтобы, например, «восстановить» его настройки, корзину продуктов, объявления, статьи и т.п. С другой, посетителям хочется оставаться максимально анонимными, не раскрывая свои персональные данные, и не давая сторонним сайтам отследить их. А последние, могут это сделать, путём обмена между собой собранными данными.

Звучит как задача сделать так, чтобы и волки были сыты, да овцы целы. Реально ли это?

Я, думаю, что до определенной степени, – реально.

Оглавление

Понятно, что в разных ситуациях, могут быть разные риски. В одних случаях, неправильная идентификация, потеря аутентификационных данных или даже кража/подделка их, не приведет к каким-либо значимым последствиям как для сайта, так и для пользователя. В других, просто будет неприятно (потерял карму на Хабре – «беда-то какая. ») или приведет к неудобству (не могу зайти под собой в Юлу, посмотреть свои объявления; профукал доступ к своим проектам на github, – ладно заведу новую учётку, форкну проекты). В третьих – может повлечь юридические и финансовые последствия. Поэтому, надо полагать, предлагаемая схема авторизации не «серебренная пуля» на все случаи, тем более «в голом виде». Там где проводится управление чувствительной информацией стоит использовать другие способы идентификации и аутентификации или их комбинации (двухфакторная авторизация, криптография на ассиметричных ключах, 3D-secure, eToken, OTP-Token и т.п.).

Ну хорошо. Какое ваше ТЗ?

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

1 Концепция беспарольной идентификации

1.1 Ключи и токены вместо логинов и паролей

1.2 Структура токена

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

1.3 HTTP-заголовки протокола

Заголовки, используемые клиентом:

Заголовки, используемые сервером:
CSI-Support: yes указывает клиенту, что сервер поддерживает протокол авторизации CSI.
CSI-Token-Action: success используется для уведомления браузера о принятии нового токена пользователя (ключ Change-To).
CSI-Token-Action: abort отменяет процедуру смены токенов (откат к предыдущему токену).
CSI-Token-Action: registration сообщает браузеру, что новый токен пользователя всё ещё находится в процессе регистрации.
CSI-Token-Action: invalid ошибка верификации токена на стороне сервера.

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

1.4 Как происходит идентификация клиентов сайтами?

Токен вычисляется заново при каждом HTTP(S)-запросе: страница, картинка, ajax-запрос.
В целях оптимизации вычислений, допускается кэширование токенов браузером, но только на время действия сессии и только в случае неизменности условий выполнения запроса.
Как уже было отмечено выше, токен может служить заменой сессионных cookie, подобных PHPSESSIONID и JSESSIONID. С той лишь разницей, если раньше сайт генерировал посетителю идентификатор, чтобы отслеживать конкретного пользователя между его разными запросами (ведь на сайт одновременно приходят тысячи запросов от разных пользователей), то теперь эту функцию выполняет сам клиент.
Такая идентификация вполне достаточна для того, чтобы позволить совершать покупки в интернет-магазине, давать объявления на соответствующих площадках, писать на форумах, в социальных сетях, статьи на Википедии или Хабре.
Да, пользователь остается для сайта анонимным. Но это может быть «знакомый» сайту аноним. И сервер может сохранить токен такого пользователя на своей стороне, вместе с его данными (личный кабинет с покупками, предпочтениями, кармой, плюшками, лайками и другими бонусами). Но только сохранить при условии завершения какого-либо бизнес-процесса: покупки, подачи объявления, и т.п. Условия определяет сам сайт.
Как видно, протокол максимально прост для сайтов, которым нет необходимости регистрировать вас прежде, чем дать возможность совершить какие-либо действия. А вот тем, кому это необходимо, придется чуть сложнее. Но об этом ниже.

1.4.2 Как узнать, что сайт поддерживает этот протокол?

Формирование нового ключа не приводит к его автоматическому использованию.

Постоянный ключ начинает использоваться только при его активации пользователем.

1.5 Как происходит авторизация клиентов сайтами?

Разработчикам важно понимать: анкета не обязательно нужна большинству сайтов. Избегайте принуждения посетителей к обязательной регистрации. В большинстве типовых ситуаций вы можете осуществить бизнес-процесс без сбора ПДн посетителей.

Вам, конечно же, придется предварительно создать постоянный ключ для сайта. Но это вопрос пары кликов мышкой.
И, наверняка, вас попросят подтвердить свой телефон или почтовый адрес. Но это уже зависит от сайта.
После успешной авторизации сервер, посредством специального HTTP-заголовка CSI-Token-Action сообщит браузеру, что он принял новый ключ. Более подробно в главе II.

1.6 А как реализовать надежную идентификацию клиентов?

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

1.7 Авторизация на сайте глазами пользователя

Вы можете управлять ключами в менеджере ключей: поменять постоянный ключ, экспортировать постоянный ключ в файл, импортировать из файла с другого устройства. Настроить «автовыход» после закрытия вкладки или браузера. Задать время действия фиксированного ключа.

1.8 Как происходит смена ключа сайта?

Сайт должен корректно обработать такой запрос. И, если данный токен пользователя сохранен в его базе, должен сделать соответствующую замену. При этом сайт должен ответить браузеру об успешном изменении токена на своей стороне. Делает он это в заголовке ответа (Response Headers) параметром: CSI-Token-Action: success, с указанием примененного токена.
Сайт имеет право отвергнуть попытку изменения токена (например, если такого токена в его базе не было или он их вообще их не сохраняет) параметром CSI-Token-Action: aborted.
До тех пор, пока браузер не получит заголовок CSI-Token-Action, он в каждый запрос к сайту в заголовок CSI-Token будет добавлять ключ Changed-To.
Это аналог «смены пароля» пользователя.

1.9 Как реализуется кросс-доменная авторизация?

Пусть вы заходите на сайт S, поддерживающем SSO от Google. Пусть у вас есть учётная запись на Google. Чтобы авторизоваться, вы нажимаете ссылку «Войти через Google», которая откроет вкладку авторизации Google. Браузер сообщит вам, что вы имеете ключ для Google. А Google сообщит, какие права запрашивает S.
Если вы согласны, нажмете «Войти» в менеджере ключей. Страница перезагрузится. Уже Google получит свой валидный токен, узнает и авторизует вас. И меж-серверным запросом сообщит сайту S информацию о вашей учетной записи в соответствии с запрошенными полями.
Перезагруженная страница будет содержать кнопку «Далее», возвращающая вас на целевой сайт.

Уязвимость: После такой авторизации, сайты S1, S2, S3, … (где вы авторизовались через Google) смогут узнавать вас (по назначенному вам идентификатору от Google), и, как следствие, отслеживать вашу деятельность.

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

1.10 Как реализовать меж-доменную идентификацию?

Всё это, конечно, хорошо. Пока работа осуществляется на одном браузере – всё отлично. А как быть с современными реалиями, когда у человека два мобильных телефона, один рабочий компьютер и несколько браузеров на нем, домашний компьютер, и ещё ноутбук? Плюс общий планшет жены/детей.
Придется как-то решать вопрос с переносом ключей доменов между браузерами, устройствами. А ещё решить вопрос их правильной синхронизации.
Одним из механизмов решения данной задачи является вычисление различных ключей доменов на базе общего мастер-ключа без возможности обратного восстановления мастер-ключа по известному ключу домена.
Создав при помощи мастер-ключа M персональный ключ K для домена D на одном устройстве, пользователь сможет создать тот же самый ключ K для домена D и на любом другом при помощи всё того же мастер-ключа M и единого алгоритма. Точнее это сделает не пользователь, а его браузер. При таком подходе пользователю достаточно распространить свой мастер ключ между всеми используемыми им браузерами и он разом «переносит все свои ключи» доменов. Заодно делает таким образом резервные копии.
Максимальное удобство для пользователя. Но и максимальный риск в случае компрометации мастер-ключа. Поэтому последний должен защищаться соответствующим образом. О рисках утраты или компрометации мастер-ключа, о способах минимизации таких рисков написано в главе «3 Рекомендации по безопасности».
Использование только одного мастер-ключа для генерации всех ключей для всех доменов не всегда удобный вариант. Во-первых, как быть, если вдруг ключ домена скомпрометирован и его необходимо поменять? Во-вторых, что если нужно поделиться ключом домена с другим человеком? Например, между членами семьи. Или это корпоративная учётная запись на доступ к общей почте. Как затем «забрать» свой ключ (ведь по факту он скомпрометирован)?
Поэтому генерация индивидуальных ключей доменов при помощи биологического датчика случайных чисел должна поддерживаться браузерами. Но тогда мы вновь возвращаемся к вопросу нашей мобильности и вопросам синхронизации, функций экспорта и импорта ключей в браузере, создания резервных копий.

Перенос через физическое отчуждаемое устройство

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

Синхронизация через онлайн-сервис

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

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

2 Техническое описание протокола

2.0 Алгоритм формирования ключа домена

Настоящий протокол определяет только 2 способа формирования ключей домена

где – 256-битный мастер-ключ, Domain – доменное имя, для которого делается ключ.
Здесь и далее HMAC – алгоритм криптографического вычисления хеша на основе 256-битной реализации хеш-функции SHA-2.

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

Здесь и далее символ будет использоваться для операции конкатенации строк (массивов байт).

2.1 Алгоритм вычисления исходного токена

Идентификационный токен пользователя вычисляется при каждом запросе любого ресурса домена. Для вычисления токена запроса берутся следующие данные:

Валидный токен получается, когда Context не пуст. Для правильной идентификации на целевом сайте необходимо, чтобы выполнялось условие Sender = Recipient = Context.

2.2 Алгоритм защиты токена при передаче

где – старшие 128 бит, – младшие 128 бит исходного токена, – конкатенация строк. При этом исходный токен должен быть уже известен серверу.

В идеале CSI-Salt должен меняться при каждом запросе браузера к серверу. Однако это может быть затратным требованием с точки зрения вычислительных ресурсов. Кроме того, это может «убить» возможность отправки параллельных запросов на сервер.
Поэтому допускается, в целях оптимизации расчетов, сохранение неизменным значения CSI-Salt в разных запросах, но не дольше одного сеанса. Это может быть ограничение по времени (смена CSI-Salt каждые 5 минут), либо реакция на интенсивность запросов (смена CSI-Salt через каждые 100 запросов), либо после каждой серии запросов (в момент паузы клиент-сервер), либо смешанный вариант. Здесь решение оставляется за разработчиками браузеров.
Слишком долгое удержание неизменным CSI-Salt ослабляет защиту передаваемого токена, позволяя злоумышленнику, при перехвате токена, воспользоваться им, пока легальный пользователь не выполнил Logout, и выполнить неавторизованный запрос от имени жертвы.

2.3 Процедура обмена солью между браузером и сервером

Воспринимает его как есть (считает его незащищенным). Использует этот токен как идентификатор сессии.
Генерирует свою соль S_salt.
Возвращает её в ответе в заголовке CSI-Salt.Второй запросГенерирует соль С_salt.
Браузер соединяет [3] свою соль и соль сервера.
Браузер отправляет запрос, передавая защищенный совместной солью токен.
Посылает CSI-Salt.Сервер получает запрос и извлекает CSI-Salt клиента.
Сервер соединяет соль браузера со своей и использует для проверки токена.

Если валидация токена успешна, предоставляет пользователю контент в соответствии с его правами.

При ошибках проверки возвращает клиенту заголовок CSI-Token-Action: invalid. Выдавать контент или возвращать пустой ответ: зависит от сервера.Последующие запросыБраузер отправляет запрос, передавая защищенный совместной солью токен.
В запросе отсутствует CSI-Salt.Сервер получает запрос и проверяет его токен.

Если валидация токена успешна, предоставляет пользователю контент в соответствии с его правами.

При ошибках проверки возвращает клиенту заголовок CSI-Token-Action: invalid. Выдавать контент или возвращать пустой ответ: зависит от сервера.Через некоторое [2] время работыГенерирует новую соль С_salt.
Соединяет новую соль с солью сервера.
Отправляет запрос, передавая защищенный новой совместной солью токен.
Посылает CSI-Salt.Сервер получает запрос и извлекает новую CSI-Salt клиента.
Сервер соединяет соль браузера со своей и использует для проверки токена.

Если валидация токена успешна, предоставляет пользователю контент в соответствии с его правами.

При ошибках проверки возвращает клиенту заголовок CSI-Token-Action: invalid. Выдавать контент или возвращать пустой ответ: зависит от сервера.

При ошибках проверки возвращает клиенту заголовок CSI-Token-Action: invalid. Выдавать контент или возвращать пустой ответ: зависит от сервера.

Если валидация токена успешна, предоставляет пользователю контент в соответствии с его правами.

Генерирует свою соль S_salt.
Возвращает её в ответе в заголовке CSI-Salt.Последующие запросыБраузер соединяет свою соль и соль сервера.
Браузер отправляет запрос, передавая защищенный совместной солью токен.
В запросе отсутствует CSI-Salt.Сервер получает запрос и проверяет его токен.

Если валидация токена успешна, предоставляет пользователю контент в соответствии с его правами.

При ошибках проверки возвращает клиенту заголовок CSI-Token-Action: invalid. Выдавать контент или возвращать пустой ответ: зависит от сервера.Через некоторое [2] время работыГенерирует новую соль С_salt.
Браузер соединяет новую соль с солью сервера.
Браузер отправляет запрос, передавая защищенный новой совместной солью токен.
Посылает CSI-Salt.Сервер получает запрос и извлекает новую CSI-Salt клиента.
Сервер соединяет соль браузера со своей и использует для проверки токена.

Если валидация токена успешна, предоставляет пользователю контента в соответствии с его правами.

При ошибках проверки возвращает клиенту заголовок CSI-Token-Action: invalid. Выдавать контент или возвращать пустой ответ: зависит от сервера.

[1] Токен считается незарегистрированным, если он: создан на базе случайного ключа; не был принят сервером после отправки ключа Change-To или Permanent ответом CSI-Token-Action: success.
[2] Время, через которое делается изменение CSI-Salt определяется браузерами самостоятельно. Это может происходить после серии запросов, после таймаута, после определенного числа запроса. Единственное ограничение – использование одного и того же CSI-Salt в разных сессиях запрещено.
[3] Имеется в виду конкатенация 16-ричного представления 128-битных чисел. Первым всегда берется соль клиента, вторым соль сервера: С_salt || S_salt. Если у браузера нет соли сервера – он хэширует токен своей солью, передавая её в заголовке. Если у сервера нет соли клиента, то он должен полагать, что токен передается незащищенным.

2.4 Правила формирования поля Context

Будем называть нашим тот домен, страницу которого мы загружаем (отображается в адресной строке браузера). Остальные домены будем называть внешними. Даже если это дочерние домены данного.

Назовем ресурс внешним, если он был загружен с внешнего домена. Назовем ресурс внутренним, если он был загружен с нашего домена. Ресурсом может быть скрипт, изображение, ajax-запрос и любой другой файл.

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

Источник