идентификация что это интернет

Что такое Идентификация в интернете?

В рамках данной заметки, я расскажу вам что такое идентификация в интернете, а так же некоторые особенности. И начну с определения.

Примечание: Данный материал является субъективным мнением, носит чисто информативный характер, не является претензией или иным порочащим действием и ни к чему не призывает.

Примечание: Кстати, стоит знать, что термин применяется во многих сферах. Например, в химии под идентификацией понимают определение неизвестного химического соединения.

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

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

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

Поэтому, например, если пишут «вам необходимо идентифицировать себя», то это сродни фразе «представьтесь, чтобы можно было понимать с кем происходит беседа».

Проблемы идентификации в интернете.

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!

Источник

Идентификация, аутентификация и авторизация — в чем разница?

Объясняем на енотах, в чем разница между идентификацией и авторизацией, а также зачем нужна аутентификация, тем более двухфакторная.

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

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

Идентификация, аутентификация и авторизация: серьезные определения

Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:

Объясняем идентификацию, аутентификацию и авторизацию на енотах

Выше было очень много умных слов, теперь давайте упростим до конкретных примеров. Скажем, пользователь хочет войти в свой аккаунт Google. Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов. Вот что при этом происходит:

Аутентификация без предварительной идентификации лишена смысла — пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.

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

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

А вот если бы вы открыли этот документ для чтения только определенным пользователям, то еноту в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа — авторизоваться.

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

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

Источник

Двухфакторная аутентификация: что это и зачем оно нужно?

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

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

Что такое двухфакторная аутентификация?

Двухфакторная аутентификация — это метод идентификации пользователя в каком-либо сервисе (как правило, в Интернете) при помощи запроса аутентификационных данных двух разных типов, что обеспечивает двухслойную, а значит, более эффективную защиту аккаунта от несанкционированного проникновения. На практике это обычно выглядит так: первый рубеж — это логин и пароль, второй — специальный код, приходящий по SMS или электронной почте. Реже второй «слой» защиты запрашивает специальный USB-ключ или биометрические данные пользователя. В общем, суть подхода очень проста: чтобы куда-то попасть, нужно дважды подтвердить тот факт, что вы — это вы, причем при помощи двух «ключей», одним из которых вы владеете, а другой держите в памяти.

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

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

Где можно включить двухфакторную аутентификацию?

Ответом на этот вопрос может служить простое правило: если используемый вами сервис содержит важные для вас данные и позволяет включить двухфакторную аутентификацию, активируйте ее не раздумывая! Вот, скажем, какой-нибудь Pinterest. Ну, не знаю… Если бы у меня был аккаунт в этом сервисе, я бы вряд ли захотел каждый раз проходить долгую процедуру двухслойной авторизации. А вот интернет-банкинг, аккаунты в соцсетях, учетка в iCloud, почтовые ящики и особенно ваши служебные учетные записи — все это однозначно стоит защитить двухфакторной аутентификацией. Сервисы Google, Apple и все основные социальные сети позволяют это сделать в настройках без особого труда.

Двухфакторная аутентификация — один из лучших методов защиты ваших аккаунтов #security

К слову, если у вас есть свой сайт, скажем, на базе WordPress или другой подобной платформе, включить в настройках двухфакторную защиту тоже не будет лишним. В общем, повторюсь: если аккаунт и его содержимое вам дороги, не игнорируйте возможность усилить защиту.

Какие еще существуют виды двухфакторной аутентификации?

Выше я уже упомянул рассылку специального кода в виде SMS и email-сообщений и USB-ключи и смарт-карты, используемые преимущественно для доступа к некоторым видам интернет-ресурсов и VPN-сетям. Кроме того, существуют еще генераторы кодов (в виде брелока с кнопкой и небольшим экранчиком), технология SecureID и некоторые другие специфические методы, характерные в основном для корпоративного сектора. Есть и менее современные интерпретации: например, так называемые TAN-пароли (TAN, Transaction Authentication Number — аутентификационный номер транзакции). Возможно, вы даже сталкивались с ними, если были клиентом какого-нибудь не самого прогрессивного банка: при подключении интернет-банкинга клиенту выдавалась бумажка с заранее сформированным списком одноразовых паролей, которые вводятся один за другим при каждом входе в систему и/или совершении транзакции. Кстати, ваша банковская карта и PIN тоже формируют систему двухфакторной аутентификации: карточка — «ключ», которым вы владеете, а PIN-код к ней — «ключ», который вы запоминаете.

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

Источник

Идентификация клиентов на сайтах без паролей и 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-запрос и любой другой файл.

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

Источник