Для сайтов, которые работают в группе, а также для сайта, который доступен на нескольких доменах, можно применить технику меж-доменной и кросс-доменной идентификации пользователя согласно протоколу. Допускаю, что в некоторых случаях, это может быть накладным для разработчиков. Надо прорабатывать конкретные случаи и вырабатывать рекомендации с готовыми примерами «под ключ».
В любом случае, Ваше замечание я принял в работу.
привязка именно к домену не очень здорово звучит
когда начинал проектировать протокол, тоже думал в таком ключе. Но, у клиента большая свобода в генерации токенов, а значит мы можем этим играть.
Смена домена сайтом. Проблема: слетает авторизация пользователей.
Пусть был habrahabr.ru. Стал habr.com.
Создаем новый ключ для нового домена habr.com-key. Способы любые: копия, экспорт, random, от мастера — на выбор пользователя. Сообщаем браузеру, что сайт поменял домен.
Браузер делает следующее:
A1. заходит на habr.com, но формирует токен по правилу от имени habrahabr.ru:
A3. делает легальную перерегистрацию токенов (предусмотренную протоколом):
CSI-Token: T_1; Changed-To: T_2
A4. если сайт принял новый токен (а оснований для отказа у него нет), то он шлет CSI-Token-Action: success, как и предусматривает протокол.
А5. В дальнейшем, используем токен T_2, как и предписывает протокол
Под словом «заходит» можно понимать отправку запросов методом GET/HEAD на идексную страницу домена. Как пример. Вводить «специальные» страницы для таких процедур крайне не хочется.
Дополню недостатки:
1. проблемы при смене сайтом доменного имени
2. большая запутанность, смешение зон ответственности
3. не описаны понятные правила участников взаимодействия
Буду делать рефакторинг с учетом высказанных замечаний. Декомпозиция — однозначно.
А то, что куки лежат в файле и доступны вирусам, ну право, вас не смущает? И место это известно и нет возможности его поменять.
Меня тут выше «размотали», за то что мастер-ключ я предложил хранить на диске. При том, что я предлагал мастер-ключ использовать только на сайтах с «пониженной социальной ответственностью». А вы тут такое предлагаете!
Когда я начинал проектировать протокол я задался вопросом: «А почему назначать идентификатор клиенту всегда была прерогативой сервера?».
Для себя я вывел следующие ответы:
1.Так исторически сложилось (если не сервер — то кто? Во времена зарождения Интернета большую часть работы выполнял сервер. Клиент даже javascript не имел. О безопасности никто ещё не думал).
2. Клиенты могут «пересечься» идентификаторами.
3. Если клиент назначит себе сам идентификатор и будет использовать его на всех сайтах — это идеальная схема, чтобы за ним следить.
Что будет, если эту схему поменять? И можно ли её поменять?
1. Почему бы и нет. Тогда мы получаем большую свободу и право менять свой идентификатор как нам вздумается.
2. Попробуем использовать сильную криптографию, и большие идентификаторы. 256 бит мало? Ок. будем 512. Здесь необходимо экспертам по криптографии оценить вероятность коллизий SHA.
3. Сделаем математическую зависимость идентификатора клиента от домена сайта.
О, у меня раньше в черновике было такое: намеренная генерация браузером ослабленных 16-битных идентификаторов, хитрым нелинейным преобразованием от ключа браузера, представленных как 256-битные. Для гарантированной анонимизации посетителя. Идентификаторы, которые намеренно могут вызвать коллизии на стороне сервера. Чтобы у баннерных сетей даже желание не возникало использовать ваши токены для слежки. Но, просчитав, варианты, отказался от этого.
Ещё один момент, про который я забыл. К вопросу: «Зачем клиенту самому себя идентифицировать?»
Если сервер назначает нам идентификатор, чтобы отслеживать наши запросы среди потока других пользователей — это слежка. Налипает на европейский GDPR.
Ведь по-сути, сервер не спрашивая, помечает вас. О чем уже уведомляет пост-фактум. Или не уведомляет — но тогда это нарушение.
Если клиент сам себя идентифицирует, то автоматом выполняется требование GDPR. Вы сами позволяете серверу отслеживать себя. Мало того, ни кто не мешает вам (браузеру) вообще менять ключ/токен при каждом запросе на сервер, чтобы блокировать слежку. (Но на практике пользователь так делать не будет. Ибо зачем? Трекинг нужен и для технических целей.)
Т.е. сейчас вас просто уведомляют: «Чувак, мы за тобой следим. Расслабься». Единственное, что вы можете сделать — согласиться с этим или покинуть сайт. А если очень надо?
Хотя в статье этого не написано, но ни кто не мешает браузеру менять ключ/токен при каждом запросе или после серии запросов (типа автосброс сессии после таймаута; режим для параноиков).
Т.е. протокол помогает серверу выполнить требования закона и решить свою задачу «трекинга». Это к вопросу: какая выгода у владельцев сайта?
Но тут лучше подключиться к обсуждению юристам. Может быть, я неверно трактую закон.
О, Вы уже второй человек, поднимающий эту тему! Не могли бы Вы привести подробный пример? Я, правда, не подобным знаком. Больше одной сессии с одним сайтом?
Но стандарт и не упаковывает вопрос хранения и синхронизации файлов. И хотя подобное описано в главе 3 «Рекомендации по безопасности», там же под спойлер я вынес оговорку, что эта глава не является частью протокола и носит рекомендательный характер. Про синхронизацию ключей я пишу в разделе «Мобильность учетных записей». Там же под спойлер я вынес альтернативы. Описал плюсы и минусы. Оценил риски. Эту тему хранения ключей ещё развивать и развивать. Но это не должно быть частью стандарта. Максимум — рекомендациями или отдельным под-стандартом. Тут я согласен с Вами.
Более того, учитывая ценное замечание user_man, протокол можно и нужно разбивать на слои, каждый со своим четким уровнем ответственности. Один отвечает за хранение ключевой информации, второй за выполнение криптографических функций (расчеты токенов, ключей, генерация соли), третий — за формирование параметров исполнения запроса (Recipient/Sender/Context), четвертый — за интерпретацию токенов (серверный уровень). Но это предварительные идеи по улучшению предложенной схемы. Пока не цепляйтесь к этому абзацу.
Или я пропустил какие-то ключевые требования к новому протоколу, которые не удовлетворяются куками?
1. Сессионные куки имеют короткий сроки жизни.
2. Постоянные куки могут иметь большой срок хранения. Но также могут быть случайно удалены при чистке кэша браузера. Ситуация типична, когда необходимо решить проблему с одним из сайтов, саппорт которого рекомендует «почистить куки и кэш», пользователь решает — да нафик всё почищу! И лишается всех кэшированных доступов.
3. Куки необходимо передавать с флагом HttpOnly, чтобы не были доступны скриптам. Есть вероятность, что разработчик забудет включить этот флаг (хотя сейчас это решают фреймворки).
Синхронизируем директорию с куками через дропбокс. Или копируем вручную. В любом случае, способ синхронизации файлов — это что-то внешнее для протокола идентификации пользователей.
4. Куки лежат только в файле. И доступны для НСД. Но опять же, стараюсь не лукавить, место хранения ключей доменов не специфицируется протоколом. Только рекомендации. Ключи доменов могут находиться на отчуждаемых носителях. Ключи домена от вашего пароля — только у вас в голове (по объективным причинам). Мастер-ключ, да — на диске.
«Ключи домена от вашего пароля» — этого не было в статье. Но, как вариант, возможен возврат к этой схеме.
Вообще, очень подробно все недостатки куки кратко рассмотрены в хорошей статье ru.wikipedia.org/wiki/Cookie. Но, я почему-то уверен, что Вы хорошо знакомы с её содержанием.
А какую из проблем, перечисленных в начале статьи, это решает?
Защита от трекинга, XSS, CSRF. Клиент получает возможность манипулировать своим ID в зависимости от контекста и формируемых запросов. Менять на лету. Если сервер вам назначил ID, вы уже не можете это изменять. И не важно как именно он передается: в куках или иных заголовках.
Может быть вы имеете в виду, что сервер вам может и так (помимо протокола) присвоить сессионный ID и записать его в куки (да хоть в код на странице)? Конечно, может. Но протокол обяжет для идентификации использовать исключительно Token-ID.
Может веб-мастер забить на болт на Token-ID и использовать куки (типа мне пофигу, мне так удобнее)? Технически может. Но тогда он ставит под угрозу безопасность своих посетителей.
Сама реализация кук и огромные исторические пробелы в их безопасности…
Вам точно удобно хранить данные пользователя (ну кроме как ID сеанса) в куках? Интерфейс работы с печеньками очень древний и ущербный. Разработчики предпочитают использовать для этих целей localStorage/sessionStorage и локальную базу.
Какая разница с точки зрения вебмастера — хранить в базе пароль или токен? Точно так же его могут небезопасно хранить и допустить утечку.
Компрометация токена при взломе сайта не приводит к компрометации исходной информации (ключа или парольной фразы), на базе которой он был вычислен. Т.е. ровно эта же информация может использоваться для генерации токенов для других сайтов. Это может быть мастер-ключ или ваша парольная фраза.
Про парольную фразу — я уже всерьез раздумываю вернуть обратно в протокол вариант генерации ключа домена от пароля.
Я думаю, Вам бы подошел ещё один вариант: генерация ключа домена на базе вашего секретного пароля. Необходимо решить вопрос с коллизиями паролей и стойкостью к брутфорсу.
Ключ на базе вашего пароля (который у вас голове). Высочайшая мобильность. Решает проблему, когда нужно срочно зайти с чужого компьютера. Риски к клавиатурным шпионам. Но при этом взлом сайта не приводит к компрометации вашего пароля — самая главная фишка. Т.е. вы можете не бояться повторно использовать пароль на других сайтах.
Удобно. Но необходимо помнить пароль. Вы можете завести себе пару-тройку таких очень «мощных» паролей для разной категории сайтов. Вполне приемлемое число.
То, что вы — активный пользователь сервисов яндекса, это ваше право. И не ваша вина, что яндекс смешивает «под одной крышей» сервисы с разным уровнем ответственности. Вот это плохо.
И ваши опасения здесь понятны. С яндексом у вас нет выбора: только ССО. Вы не можете индивидуально сделать пароль к каждому сервису яндекса.
В идеале, для каждого сервиса яндекса должна быть отдельная аутентификация.
Яндекс тут решил свои проблемы, забив на ваши. Да простят меня сотрудники этой компании)
Одно дело, когда вы компрометирует доступ в Яндекс.Маркет или Яндекс.Музыка. И другое дело, когда в Яндекс.Кошелек.
Вы можете точно также войти в Яндекс.Почту с постороннего компьютера (арендованный ноутбук в интернет-кафе какого-нибудь отеля в теплых странах; и не зарекайтесь, что с вами это никогда не случится), и «спалить» свой пароль. Но этот пароль даст доступ ко всем сервисам яндекса от вашего имени. И эта проблема не только Яндекса. Это проблема всех крупных ССО: майл, гугл, да кто там ещё?
Как вы, может быть, помните, технология кросс-доменной авторизации появилась как раз-таки как основной способ решения «парольной проблемы». ССО вас избавляет от необходимости иметь кучу учёток на разных сайтах и иметь кучу паролей к ним. ССО авторизует вас на сайтах, избавляя от необходимости в предварительной регистрации и аутентификации. Удобство — да. Но и риски велики. В информационной безопасности, к сожалению, в большинстве случаев чем удобнее, тем менее безопасно.
Предлагаемый протокол решает «парольную проблему» иным способом. Он делает крайне легким генерацию аутентификационной информации и процедуру логина (вопрос пары кликов). А это значит, что основная и самая сложная проблема: «придумать уникальный пароль, запомнить его и хранить» — решается просто. При таком функционале ценность ССО значительно снижается. Оно уже не так необходимо. Я не призываю отказываться вообще от этой технологии. Но вы должны понимать, какие риски она влечет и почему.
Теперь далее. В статье это говорится, но я повторюсь. Протокол определяет два способа формирования ключей: на базе мастер-ключа (который суть 256-битное случайно сгенерированное число); на базе индивидуального 256-битного ключа. Возможно, я не исключаю вариант, что стоит вернуться ещё и к третьему способу: формирование ключа домена на базе пароля пользователя. Необходимо решить вопрос с коллизиями паролей и стойкостью к брутфорсу. Но давайте для упрощения представим, что мы уже сделали это — ввели этот третий способ формирования ключа домена.
Каждый из этих способов имет свои плюсы и минусы, а потому может применяться в следующих сценариях:
1. Мастер-ключ. Средняя мобильность (необходимо предварительно распространить его среди ваших устройств). Наибольшая удобность при аутентификации и регистрации. Наименьшие риски при потере (вы ведь распространив по устройствам де-факто сделали его резервную копию). Наибольшие риски при компрометации. Риски к краже руткитами или при административном НСД к вашему компьютеру (их можно уменьшить). Поэтому используется только на сайтах с низким уровнем ответственности. Всякие форумы (где вам необходимо задать вопрос или скачать файл «только для зарегистрированных», а потом навсегда забыть этот сайт), блоги (где вы решили оставить комментарий) и т.п. чепуха. Ну скомпрометируете ключ — да и фиг с ним. Одноразовые доступы. Туда им и дорога.
2. Индивидуальный ключ. Низкая мобильность. Меньшая удобность в использовании. Но наилучший уровень безопасности. Можно вынести на хранение в смарт-карты. Существуют риски утраты (сломалась смарт-карта). Предполагается к использованию на серьезных сайтах (личные кабинеты провайдеров, финансовых учреждений и т.п.) и только на доверенных устройствах. Предполагается, что такими ключами идентифицируется уже ваша личность (ибо серьезно). Если вы используете такой ключ «где попало» — вы сами себе враг. Мобильность можно обеспечить отчуждаемыми носителями (смарт-карты).
3. Ключ на базе вашего пароля (который у вас голове). Высочайшая мобильность. Решает проблему, когда нужно срочно зайти с чужого компьютера. Риски к клавиатурным шпионам. Но при этом взлом сайта не приводит к компрометации вашего пароля. Удобно. Но необходимо помнить пароль. Вы можете завести себе пару-тройку таких очень «мощных» паролей для разной категории сайтов. Вполне приемлемое число.
Да, я знаю. Это выглядит сложно и запутано. Безопасность она всегда сложная. Но частично эта проблема решается хорошим UI-интерфейсом и обучением общей грамотности пользователей. Посмотрите сколько в интернете статей и заметок на тему того, какие пароли необходимо придумывать и как их правильно хранить.
Вот ещё, например, такой UI-кейс. Браузер не позволит вам сделать ключ на базе мастер-ключа, если сайт имеет SSL-сертификат определенной категории (а такой сертификат может получить только крупная уважаемая компания; а Let's Encrypt, скажем такие не выдаст). Т.е. сделать ключ для Сбербанк.Онлайн от мастер-ключа у пользователя не получится. Но с этим необходимо осторожнее. Здесь должны подключиться спрециалисты по UI-интерфейсам.
Вы не думайте, что придумав какой-то протокол, мы сразу сделаем мир лучше. Проблема должна решаться комплексно. Разработчики браузеров — решают свою часть. Веб-разработчики — свою часть. Разработчики библиотек протокола — свою часть. Попутный софт (nginx) — свою. Обучение пользователей соответствующими статьями — то же мера.
А что касается Яндекса. Это плохо, что у них все завязано на passport.yandex.ru и без альтернативно. Само ССО удобно. Но отсутствие альтернативы — удручает. К сожалению, мой протокол не решает эту проблему. И эту проблему не решит никакой протокол.
ID (он же токен) выполняет для сайта роль и логина, и пароля. И при этом нивелирует риски клиента при своей компрометации. Защищен при передаче.
Но это особенности реализации.
Эта особенность кардинально всё меняет.
1. Клиент получает большую независимость от сервера. Клиент сам решает какой ID в какой ситуации слать. По какому алгоритму вычислять. Это дает эффектные способы защиты от известных сетевых атак.
Стандартизация алгоритмов формирования токенов защищает пользователя от кривых реализаций. Браузер не сможет пойти мимо стандарта. Иначе это вызовет несовместимость с другими браузерами.
Браузер не сможет использовать искусственно ослабленные ключи, иначе это вызовет коллизии у разных пользователей на стороне сервера. Ну и не совместимость, опять же. Спалится тут же.
Что значит, ослабленные ключи?
Например, браузер генерирует ключи, у которых только 40 бит случайны, а остальные 216 — линейная комбинация из этих 40-ка, вычисленная хитрым недокументированным образом.
2. Мы часто слышим, о массовых утечках паролей пользователей в результате очередного взлома сайта. Представьте, что ваш ценный очень сложный пароль, который вы хранили как зеницу ока вдруг стал бесполезным. Обидно? Да. Очень многие сайта забивают даже на простейшее хэширование паролей. По не знанию или халатности.
Основой посыл потокола такой. Если вы, уважаемые веб-мастера, не умеете или не хотите хранить надежно аутентификационные данные ваших пользователей. То мы-пользователи, лишаем вас этого права. Вы теперь должны «матчить» ID, который мы вам предоставим сами. И что с ним делать — ваша забота.
Для сайтов, которые работают в группе, а также для сайта, который доступен на нескольких доменах, можно применить технику меж-доменной и кросс-доменной идентификации пользователя согласно протоколу. Допускаю, что в некоторых случаях, это может быть накладным для разработчиков. Надо прорабатывать конкретные случаи и вырабатывать рекомендации с готовыми примерами «под ключ».
В любом случае, Ваше замечание я принял в работу.
когда начинал проектировать протокол, тоже думал в таком ключе. Но, у клиента большая свобода в генерации токенов, а значит мы можем этим играть.
Пусть был habrahabr.ru. Стал habr.com.
Создаем новый ключ для нового домена habr.com-key. Способы любые: копия, экспорт, random, от мастера — на выбор пользователя. Сообщаем браузеру, что сайт поменял домен.
Браузер делает следующее:
A1. заходит на habr.com, но формирует токен по правилу от имени habrahabr.ru:
сайт узнает и авторизует пользователя, т.к. такой токен есть в его базе
A2. генерирует новый «правильный» токен
A3. делает легальную перерегистрацию токенов (предусмотренную протоколом):
A4. если сайт принял новый токен (а оснований для отказа у него нет), то он шлет CSI-Token-Action: success, как и предусматривает протокол.
А5. В дальнейшем, используем токен T_2, как и предписывает протокол
Под словом «заходит» можно понимать отправку запросов методом GET/HEAD на идексную страницу домена. Как пример. Вводить «специальные» страницы для таких процедур крайне не хочется.
1. проблемы при смене сайтом доменного имени
2. большая запутанность, смешение зон ответственности
3. не описаны понятные правила участников взаимодействия
Буду делать рефакторинг с учетом высказанных замечаний. Декомпозиция — однозначно.
Благодарю за это.
Если вы заметили какой-то существенный недостаток токенов, который я не заметил, — поделитесь. Буду благодарен.
Про многосеансовость мне уже писали. Про смену домена сайтом — тоже. Я принял к сведению. Уже обдумываю варианты.
А то, что куки лежат в файле и доступны вирусам, ну право, вас не смущает? И место это известно и нет возможности его поменять.
Меня тут выше «размотали», за то что мастер-ключ я предложил хранить на диске. При том, что я предлагал мастер-ключ использовать только на сайтах с «пониженной социальной ответственностью». А вы тут такое предлагаете!
Для себя я вывел следующие ответы:
1.Так исторически сложилось (если не сервер — то кто? Во времена зарождения Интернета большую часть работы выполнял сервер. Клиент даже javascript не имел. О безопасности никто ещё не думал).
2. Клиенты могут «пересечься» идентификаторами.
3. Если клиент назначит себе сам идентификатор и будет использовать его на всех сайтах — это идеальная схема, чтобы за ним следить.
Что будет, если эту схему поменять? И можно ли её поменять?
1. Почему бы и нет. Тогда мы получаем большую свободу и право менять свой идентификатор как нам вздумается.
2. Попробуем использовать сильную криптографию, и большие идентификаторы. 256 бит мало? Ок. будем 512. Здесь необходимо экспертам по криптографии оценить вероятность коллизий SHA.
3. Сделаем математическую зависимость идентификатора клиента от домена сайта.
О, у меня раньше в черновике было такое: намеренная генерация браузером ослабленных 16-битных идентификаторов, хитрым нелинейным преобразованием от ключа браузера, представленных как 256-битные. Для гарантированной анонимизации посетителя. Идентификаторы, которые намеренно могут вызвать коллизии на стороне сервера. Чтобы у баннерных сетей даже желание не возникало использовать ваши токены для слежки. Но, просчитав, варианты, отказался от этого.
Если сервер назначает нам идентификатор, чтобы отслеживать наши запросы среди потока других пользователей — это слежка. Налипает на европейский GDPR.
Ведь по-сути, сервер не спрашивая, помечает вас. О чем уже уведомляет пост-фактум. Или не уведомляет — но тогда это нарушение.
Если клиент сам себя идентифицирует, то автоматом выполняется требование GDPR. Вы сами позволяете серверу отслеживать себя. Мало того, ни кто не мешает вам (браузеру) вообще менять ключ/токен при каждом запросе на сервер, чтобы блокировать слежку. (Но на практике пользователь так делать не будет. Ибо зачем? Трекинг нужен и для технических целей.)
Т.е. сейчас вас просто уведомляют: «Чувак, мы за тобой следим. Расслабься». Единственное, что вы можете сделать — согласиться с этим или покинуть сайт. А если очень надо?
Хотя в статье этого не написано, но ни кто не мешает браузеру менять ключ/токен при каждом запросе или после серии запросов (типа автосброс сессии после таймаута; режим для параноиков).
Т.е. протокол помогает серверу выполнить требования закона и решить свою задачу «трекинга». Это к вопросу: какая выгода у владельцев сайта?
Но тут лучше подключиться к обсуждению юристам. Может быть, я неверно трактую закон.
(Соль не спешите отбрасывать, но вы правы — это детали реализации).
Еще можно добавить: самоидентификация клиента; полный отказ от трехзвенной структуры.
Но стандарт и не упаковывает вопрос хранения и синхронизации файлов. И хотя подобное описано в главе 3 «Рекомендации по безопасности», там же под спойлер я вынес оговорку, что эта глава не является частью протокола и носит рекомендательный характер. Про синхронизацию ключей я пишу в разделе «Мобильность учетных записей». Там же под спойлер я вынес альтернативы. Описал плюсы и минусы. Оценил риски. Эту тему хранения ключей ещё развивать и развивать. Но это не должно быть частью стандарта. Максимум — рекомендациями или отдельным под-стандартом. Тут я согласен с Вами.
Более того, учитывая ценное замечание user_man, протокол можно и нужно разбивать на слои, каждый со своим четким уровнем ответственности. Один отвечает за хранение ключевой информации, второй за выполнение криптографических функций (расчеты токенов, ключей, генерация соли), третий — за формирование параметров исполнения запроса (Recipient/Sender/Context), четвертый — за интерпретацию токенов (серверный уровень). Но это предварительные идеи по улучшению предложенной схемы. Пока не цепляйтесь к этому абзацу.
1. Сессионные куки имеют короткий сроки жизни.
2. Постоянные куки могут иметь большой срок хранения. Но также могут быть случайно удалены при чистке кэша браузера. Ситуация типична, когда необходимо решить проблему с одним из сайтов, саппорт которого рекомендует «почистить куки и кэш», пользователь решает — да нафик всё почищу! И лишается всех кэшированных доступов.
3. Куки необходимо передавать с флагом HttpOnly, чтобы не были доступны скриптам. Есть вероятность, что разработчик забудет включить этот флаг (хотя сейчас это решают фреймворки).
4. Куки лежат только в файле. И доступны для НСД. Но опять же, стараюсь не лукавить, место хранения ключей доменов не специфицируется протоколом. Только рекомендации. Ключи доменов могут находиться на отчуждаемых носителях. Ключи домена от вашего пароля — только у вас в голове (по объективным причинам). Мастер-ключ, да — на диске.
«Ключи домена от вашего пароля» — этого не было в статье. Но, как вариант, возможен возврат к этой схеме.
Вообще, очень подробно все недостатки куки кратко рассмотрены в хорошей статье ru.wikipedia.org/wiki/Cookie. Но, я почему-то уверен, что Вы хорошо знакомы с её содержанием.
Защита от трекинга, XSS, CSRF. Клиент получает возможность манипулировать своим ID в зависимости от контекста и формируемых запросов. Менять на лету. Если сервер вам назначил ID, вы уже не можете это изменять. И не важно как именно он передается: в куках или иных заголовках.
Может быть вы имеете в виду, что сервер вам может и так (помимо протокола) присвоить сессионный ID и записать его в куки (да хоть в код на странице)? Конечно, может. Но протокол обяжет для идентификации использовать исключительно Token-ID.
Может веб-мастер забить на болт на Token-ID и использовать куки (типа мне пофигу, мне так удобнее)? Технически может. Но тогда он ставит под угрозу безопасность своих посетителей.
Сама реализация кук и огромные исторические пробелы в их безопасности…
Вам точно удобно хранить данные пользователя (ну кроме как ID сеанса) в куках? Интерфейс работы с печеньками очень древний и ущербный. Разработчики предпочитают использовать для этих целей localStorage/sessionStorage и локальную базу.
Компрометация токена при взломе сайта не приводит к компрометации исходной информации (ключа или парольной фразы), на базе которой он был вычислен. Т.е. ровно эта же информация может использоваться для генерации токенов для других сайтов. Это может быть мастер-ключ или ваша парольная фраза.
Про парольную фразу — я уже всерьез раздумываю вернуть обратно в протокол вариант генерации ключа домена от пароля.
Ключ на базе вашего пароля (который у вас голове). Высочайшая мобильность. Решает проблему, когда нужно срочно зайти с чужого компьютера. Риски к клавиатурным шпионам. Но при этом взлом сайта не приводит к компрометации вашего пароля — самая главная фишка. Т.е. вы можете не бояться повторно использовать пароль на других сайтах.
Удобно. Но необходимо помнить пароль. Вы можете завести себе пару-тройку таких очень «мощных» паролей для разной категории сайтов. Вполне приемлемое число.
И ваши опасения здесь понятны. С яндексом у вас нет выбора: только ССО. Вы не можете индивидуально сделать пароль к каждому сервису яндекса.
В идеале, для каждого сервиса яндекса должна быть отдельная аутентификация.
Яндекс тут решил свои проблемы, забив на ваши. Да простят меня сотрудники этой компании)
Одно дело, когда вы компрометирует доступ в Яндекс.Маркет или Яндекс.Музыка. И другое дело, когда в Яндекс.Кошелек.
Вы можете точно также войти в Яндекс.Почту с постороннего компьютера (арендованный ноутбук в интернет-кафе какого-нибудь отеля в теплых странах; и не зарекайтесь, что с вами это никогда не случится), и «спалить» свой пароль. Но этот пароль даст доступ ко всем сервисам яндекса от вашего имени. И эта проблема не только Яндекса. Это проблема всех крупных ССО: майл, гугл, да кто там ещё?
Как вы, может быть, помните, технология кросс-доменной авторизации появилась как раз-таки как основной способ решения «парольной проблемы». ССО вас избавляет от необходимости иметь кучу учёток на разных сайтах и иметь кучу паролей к ним. ССО авторизует вас на сайтах, избавляя от необходимости в предварительной регистрации и аутентификации. Удобство — да. Но и риски велики. В информационной безопасности, к сожалению, в большинстве случаев чем удобнее, тем менее безопасно.
Предлагаемый протокол решает «парольную проблему» иным способом. Он делает крайне легким генерацию аутентификационной информации и процедуру логина (вопрос пары кликов). А это значит, что основная и самая сложная проблема: «придумать уникальный пароль, запомнить его и хранить» — решается просто. При таком функционале ценность ССО значительно снижается. Оно уже не так необходимо. Я не призываю отказываться вообще от этой технологии. Но вы должны понимать, какие риски она влечет и почему.
Теперь далее. В статье это говорится, но я повторюсь. Протокол определяет два способа формирования ключей: на базе мастер-ключа (который суть 256-битное случайно сгенерированное число); на базе индивидуального 256-битного ключа. Возможно, я не исключаю вариант, что стоит вернуться ещё и к третьему способу: формирование ключа домена на базе пароля пользователя. Необходимо решить вопрос с коллизиями паролей и стойкостью к брутфорсу. Но давайте для упрощения представим, что мы уже сделали это — ввели этот третий способ формирования ключа домена.
Каждый из этих способов имет свои плюсы и минусы, а потому может применяться в следующих сценариях:
1. Мастер-ключ. Средняя мобильность (необходимо предварительно распространить его среди ваших устройств). Наибольшая удобность при аутентификации и регистрации. Наименьшие риски при потере (вы ведь распространив по устройствам де-факто сделали его резервную копию). Наибольшие риски при компрометации. Риски к краже руткитами или при административном НСД к вашему компьютеру (их можно уменьшить). Поэтому используется только на сайтах с низким уровнем ответственности. Всякие форумы (где вам необходимо задать вопрос или скачать файл «только для зарегистрированных», а потом навсегда забыть этот сайт), блоги (где вы решили оставить комментарий) и т.п. чепуха. Ну скомпрометируете ключ — да и фиг с ним. Одноразовые доступы. Туда им и дорога.
2. Индивидуальный ключ. Низкая мобильность. Меньшая удобность в использовании. Но наилучший уровень безопасности. Можно вынести на хранение в смарт-карты. Существуют риски утраты (сломалась смарт-карта). Предполагается к использованию на серьезных сайтах (личные кабинеты провайдеров, финансовых учреждений и т.п.) и только на доверенных устройствах. Предполагается, что такими ключами идентифицируется уже ваша личность (ибо серьезно). Если вы используете такой ключ «где попало» — вы сами себе враг. Мобильность можно обеспечить отчуждаемыми носителями (смарт-карты).
3. Ключ на базе вашего пароля (который у вас голове). Высочайшая мобильность. Решает проблему, когда нужно срочно зайти с чужого компьютера. Риски к клавиатурным шпионам. Но при этом взлом сайта не приводит к компрометации вашего пароля. Удобно. Но необходимо помнить пароль. Вы можете завести себе пару-тройку таких очень «мощных» паролей для разной категории сайтов. Вполне приемлемое число.
Да, я знаю. Это выглядит сложно и запутано. Безопасность она всегда сложная. Но частично эта проблема решается хорошим UI-интерфейсом и обучением общей грамотности пользователей. Посмотрите сколько в интернете статей и заметок на тему того, какие пароли необходимо придумывать и как их правильно хранить.
Вот ещё, например, такой UI-кейс. Браузер не позволит вам сделать ключ на базе мастер-ключа, если сайт имеет SSL-сертификат определенной категории (а такой сертификат может получить только крупная уважаемая компания; а Let's Encrypt, скажем такие не выдаст). Т.е. сделать ключ для Сбербанк.Онлайн от мастер-ключа у пользователя не получится. Но с этим необходимо осторожнее. Здесь должны подключиться спрециалисты по UI-интерфейсам.
Вы не думайте, что придумав какой-то протокол, мы сразу сделаем мир лучше. Проблема должна решаться комплексно. Разработчики браузеров — решают свою часть. Веб-разработчики — свою часть. Разработчики библиотек протокола — свою часть. Попутный софт (nginx) — свою. Обучение пользователей соответствующими статьями — то же мера.
А что касается Яндекса. Это плохо, что у них все завязано на passport.yandex.ru и без альтернативно. Само ССО удобно. Но отсутствие альтернативы — удручает. К сожалению, мой протокол не решает эту проблему. И эту проблему не решит никакой протокол.
Эта особенность кардинально всё меняет.
1. Клиент получает большую независимость от сервера. Клиент сам решает какой ID в какой ситуации слать. По какому алгоритму вычислять. Это дает эффектные способы защиты от известных сетевых атак.
Стандартизация алгоритмов формирования токенов защищает пользователя от кривых реализаций. Браузер не сможет пойти мимо стандарта. Иначе это вызовет несовместимость с другими браузерами.
Браузер не сможет использовать искусственно ослабленные ключи, иначе это вызовет коллизии у разных пользователей на стороне сервера. Ну и не совместимость, опять же. Спалится тут же.
2. Мы часто слышим, о массовых утечках паролей пользователей в результате очередного взлома сайта. Представьте, что ваш ценный очень сложный пароль, который вы хранили как зеницу ока вдруг стал бесполезным. Обидно? Да. Очень многие сайта забивают даже на простейшее хэширование паролей. По не знанию или халатности.
Основой посыл потокола такой. Если вы, уважаемые веб-мастера, не умеете или не хотите хранить надежно аутентификационные данные ваших пользователей. То мы-пользователи, лишаем вас этого права. Вы теперь должны «матчить» ID, который мы вам предоставим сами. И что с ним делать — ваша забота.