Comments 136
А если например полетел винт или винда — со всеми учетками тоже можно попрощаться.
Идея в целом интересная, но надежность имхо низковатая
Если сравнивать с текущим кейсом обычного пользователя: сохранение паролей в браузере + перекидывание их между этим же браузером на разных платформах. По сути пароль вам нужно ввести только один раз, а дальше браузер его сам подставит. Безопасно? Не очень. Удобно? Максимально. Плюс всегда есть возможность ввести пароль вручную
Сохранение паролей в браузере + перекидывание их между этим же браузером на разных платформах.… Безопасно? Не очень.
Как вариант: можно синхронизировать не пароли, а контейнер с паролями, зашифрованный мастер-ключом, который только в голове у человека. Два года назад такой вариант детально описывал на Хабре. Понятно, что это добавляет необходимость помнить мастер-пароль (или создавать дубликат ключа), поэтому такая защита должна быть опциональной.
Но они сознательно сломали этот механизм — теперь на новом телефоне мастер пароль не спрашивается хотя данные «зашифрованы». Откуда новый телефон его узнает? Правильно из профиля пользователя. Ну и какой смысл в таком шифровании если пароль лежит рядом с зашифрованным этим паролем контейнером?
Уроды, блин.
можно синхронизировать не пароли, а контейнер с паролями, зашифрованный мастер-ключом, который только в голове у человекаданный подход оставляет уязвимость к брутфорсу слабых паролей и клавиатурным шпионам. Первое ещё решаемо. Второе — сложнее.
Плюс, с точки зрения удобства это самый обычный менеджер паролей. Но вот идея с временной авторизацией это прям мне понравилось.
developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
Отличная работа.
Если вы не списали идею у Moziilla, то зачем снимать статью? Это же ваш труд.
Смысл в чём? В том, что мозилла продаёт свои услуги всем, кто предложит достаточно денег. Поэтому все их протоколы, поддерживаемые их браузером, в одно мгновение переориентируются на нужды нового заказчика, который предложил больше денег, а значит ни о какой анонимности и прочем речи быть не может.
Поэтому нужны альтернативы. Ваш вариант — возможная альтернатива. Но, как написали ниже, она несколько «тяжеловата».
Во первых — выделите главное. И сделайте из него верхний уровень протокола. В главном должна быть лишь основная идея — шлём сессионный ключ для сессии или шлём постоянный ключ для постоянного подключения. Всё остальное — следующие уровни протокола.
Так же из протокола необходимо вырезать браузер, ибо это порождение инопланетного разума, и оно будет сливать все ваши токены ни чуть не хуже бесконечного множества сайтов. Как жить без браузера? Элементарно — натравливаем браузер на порт прокси-сервера, а сам прокси — это софт с открытым кодом, который выполняет очень узкую задачу чтения заголовков из входного потока, результатом чего будет понимание, нужно ли в данной ситуации отдавать сессионный или постоянный ключ. На пути назад (от браузера на сервер) прокси дописывает свои параметры к HTTP ответу, ну а браузер вообще ни о чём не знает (ибо нефиг всяким гуглам хоть что-то знать о пользователях).
В целом альтернатива состоит в том, что, во первых, браузер идёт лесом, а во вторых, протокол делится на уровни. При этом прокси будет прост в реализации, что позволит получить множество вариантов на разных языках, и все — с открытым исходным текстом. Топ подобных прокси будет очень заметен и потому их открытый код будет безопасен.
Всё остальное — детали реализации. Они важны, но если вы заморочитесь ими — вы похороните свой протокол. Важное — верхний уровень. Плюс обязательно выкинуть браузер. Всё остальное — только когда готов (согласован с общественностью) верхний уровень.
ЗЫ. У меня аж зуд появился на написание прокси. Но только после согласования верхнего уровня.
Так же из протокола необходимо вырезать браузер… будет сливать все ваши токены ни чуть не хуже бесконечного множества сайтов
Золотые слова. Я думал об этом.
Только у меня правила вычисления токена сильно завязаны на DOM-модель и её состояние, к которому у прокси не будет доступа. Но кто сказал, что нельзя решить и эту проблему. Или сделать комбинированный вариант. Нужно думать.
Во первых — выделите главное. И сделайте из него верхний уровень протокола.
Вы правы, стоит использовать опыт OSI. Чётко разделить зоны ответственности.
У меня аж зуд появился на написание прокси.
У меня самого зачесались руки и я набросал концепт-код серверной части (пока на PHP; хочу ещё в виде фильтра запросов на Java под tomcat). А ещё нужен тестовый плагин для браузера.
Я уверен, что тестовая имплементация протокола (в виде рабочего концепта), — правильный (хотя и затратный) способ для оценки его сложности/легкости, удобства/неудобства. И единственный способ, чтобы прогнать все возможные сценарии.
Зачем? Начать можно с домена, доступного в HTTP, а далее — сервер, поддерживающий протокол, сам скажет, что такой-то поддомен или путь — это отдельный сервис.
>> А ещё нужен тестовый плагин для браузера.
Снова подумайте о сложности. Привлекать в дело ещё и потроха браузера — сильно повышать сложность. Никаких DOM и браузерных штучек, останется только чистая обработка простейших заголовков и хранение ключей. А с браузером — ну разве что если интересно освоить написание плагинов.
>> Я уверен, что тестовая имплементация протокола (в виде рабочего концепта), — правильный (хотя и затратный) способ для оценки его сложности/легкости
Не потрогаешь, не поймёшь, да. Но есть опасность ухода в частности, что далее повлечёт опасные последствия. Хотя, разумеется, вам виднее.
Я изучал этот протокол. Возможно, несколько поверхностно. Если Вы считаете, что я «переизобрел Керберос», буду раз, если покажите в чём именно совпадение.
Центральная идея — клиент сам себя идентифицирует, присваивая себе уникальный номер. Никто, кроме клиента не знает, как он сформирован.
Сейчас идентификацией своих пользователей занимается сам сервер, назначая вам некий ID. Схема переворачивает эту идею наоборот.
Мне интересен другой аспект. Юридический так сказать. Сейчас все боятся с куками. В том самом европейском стандарте о защите данных пользователей в тексте указаны запреты именно на куки или же на идентификацию любыми другими способами?
И заодно второй вопрос. Где-то я слышал что там запрещают сбор информаци если она не нужна для выполнения сайтом стих полезных для посетителя функций. А так вообще о можно собирать.
Кто-нибудь может внести ясность?
в европейском законе написано "и аналогичные технологии", никак трекать нельзя, они не привязывались к конкретной технологии
А в отношении технически необходимых first-party куков есть понимание, что отменить их нельзя, и даже согласие пользователя на их использование не требуется:
wikis.ec.europa.eu/display/WEBGUIDE/04.+Cookies
Как мне видится, технические вещи типа CORS — сами по себе, и заголовки какие нужны, чтобы браузер согласился со всей конструкцией работать, такие и нужны.
А юридические вопросы — сами по себе. Как на той же самой странице чуть ниже пишут, всё что надо — это:
- показать сообщение про куки;
- обеспечить отсутствие third-party куков, пока не будет получено согласие посетителя;
- разумно после этого создать куки на весь портал, чтобы не переспрашивать одно и то же на разных поддоменах.
Мне больше нравится идея аутентификации через OAuth2 на госуслугах, у них даже есть опция анонимной аутентификации, когда стороннему сервису передается только email.
Сервера надежно защищены, гарантии существования сервиса дает государство, при потере пароля можно прийти с паспортом в ближайший МФЦ.
Вот только подключиться к ним нельзя, отвечают отпиской, что подключение только для категорий организаций, явно указанных в каких-то ФЗ...
Сервера надежно защищены
Хотелось бы в это верить. Боюсь, что защита больше «на бумаге». Я видел, как «грамотные» сотрудники пересылали по Skype и TeamViewer секретные дистрибутивы ключей от VipNet с дефолтными паролям, дающие возможность работы с защищенными ресурсами.
Но самое главное, любое SSO делает вас зависимыми от третьей стороны. И если по каким-то причинам она недоступна вам или веб-серверу, то…
Вот такое изображение я частенько вижу:
Периодически ЕСИА проводит «профилактические работы». Из-за которых не доступны многие гос.сервисы (запись к врачу, налоговая, гос.закупки).
Вот только подключиться к ним нельзя...
Всё правильно, подключение преимущественно только для органов власти, предоставляющих государственные услуги.
Как физическое лицо подключиться никак нельзя. Необходимо юридическое лицо. Да и то, наверно, не любое. Я просто писал реализацию для аутентификации через ЕСИА (сайт до сих пор работает) и задался сделать это у себя на сайте. Но увы.
У вас очень сложные и запутанные правила передачи токенов при переходе с сайта на сайт (Sender/Receiver/Context). Их трудно запомнить и при работе с ними легко допустить ошибку. Проблема CSRF понятна, но ваше решение слишком сложное. Вообще, в вашем протоколе все сложное. Это его ахиллесова пята.
На мой взгляд, один из вариантов решения для борьбы с CSRF мог бы быть — не отправлять авторизационные куки с POST/PUT/DELETE-запросами, а требовать сайт явно включать их в форму (атрибутом вроде send-cookie="auth: 12345") или добавлять в AJAX-запрос. Это, правда, оставляет уязвимыми сайты, где какие-то действия делаются по GET-запросу. Но решает проблему на правильно сделанных сайтах и не требует заучивания сложных правил. Как вам? Другой вариант — не включать куки в запрос при кроссдоменных POST-запросах, но включать при запросах в пределах одного домена, чтобы облегчить жизнь разработчикам. Тогда вообще никакие атрибуты не нужны.
Под ваше ТЗ (сайт должен запоминать пользователя, пользователь должен иметь возможность стереть информацию о себе) хорошо подходят токены в куках, которые уже есть и работают (правда, уязвимы для CSRF).
Также, у вас неудачная идея вида "браузер может отправить заголовок с запросом на любую страницу". Это тоже плохо, так как например может быть несколько приложений внутри одного домена, которые имеют разный код, работают на разных серверах (например, у Гугла все на одном домене для лучшей передачи кук). Или запрос может попасть к nginx, обслуживающему статику и игнорирующему такие заголовки. Запросы не должны отправляться "на любой" URL.
Зачем при передаче по HTTPS как-то шифровать или хешировать токен, мне непонятно. Пароль хешируют для защиты от подглядывания и попытки ввода на других сайтах, а для чего шифровать токен, который к другим сайтам не подойдет?
Зачем нужны Sender/Receiver и правила работы с ними, если гораздо проще просто не передавать токен при кроссдоменных запросах (когда сайт A шлет POST-запрос на сайт B)?
У вас сложный протокол из-за того, что он садится поверх существующих запросов и браузеру надо отслеживать состояние, например, что он послал заголовок с меткой Changed, но пока не получил подтверждения. Допустим, браузеру надо отправить параллельно 50 запросов на загрузку статики. Он к каждому будет прикреплять поле changed или только к первому? Что делать, если он не получил подтверждения? Ждать следующей возможности отправить эту пометку? Также, браузер должен сначала узнать, что сайт поддерживает токены, прежде чем слать их на сайт, опять усложнение. Я бы не хотел быть разработчиком, которому поручили это реализовать.
В описании протокола в пункте 2.3 вы считаете, что запросы отправляются по одному по очереди, однако браузеры шлют запросы параллельно. Запросы могут выполняться очень долго или отваливаться по таймауту. У вас это учтено?
Кроссдоменную авторизацию проще было бы делать без участия встроенных в браузер протоколов, используя протоколы вроде OAuth2. Сайты ведь всегда могут передавать друг другу какие-то токены через адресную строку.
Далее, предположим, что сайт хочет иметь телефон, email и имя пользователя и традиционную регистрацию. Упрощает ли ваша система жизнь пользователю или увеличивает нужное число кликов?
Вы сделали сложное решение, которое при этом работает для ограниченного числа сценариев (вы просто хотите встроенный в браузер менеджер паролей для себя ценой значительного усложнения браузера для всех). Как, например, насчет залогинивания под двумя аккаунтами сразу? Ваше решение этого не позволяет.
Какая выгода сайтам от интеграции вашего решения?
Ваше решение не поможет анонимности, так как сайты будут игнорировать его и принуждать пользователя к традиционной авторизации через куки, чтобы отслеживать их.
Ваша система мне кажется очень непонятной для обычного пользователя. Надо нажать на какой-то ключ, выбрать опции с непонятными словами… Это явно фича для продвинутых, а не обычных пользователей. А уж те случаи, когда срабатывает защита и авторизация отключается, вообще будут выносить людям мозг. Представьте — секунду назад у пользователя была полная корзина товаров, а после клика по ссылке они все исчезли. Пользователь не поймет, что произошло, не сможет это объяснить техподдержке, а магазин потеряет заказ. Магазин не захочет использовать такую систему.
Сайты, очевидно, хотят контролировать вид формы входа/регистрации и их процесс, чтобы иметь возможность сделать его лучше, чем у конкурентов, а не "как у всех". Чтобы иметь возможность сделать его простым.
Что если вместо вашей системы предложить просто протокол сохранения авторизационных данных с сайта в браузере (это как сохранение паролей сейчас, только без необходимости для браузера заполнять формы) с двумя действиями: сохранить токен с сайта в браузер и достать токен из браузера? Действия могут вызываться яваскриптом или мета-тегами. Не будет ли такая система решать те же задачи, но более эффективно и при этом ее работу будет полностью контролировать сайт? Плюс, ее можно реализовать уже сегодня, сохраняя данные в localStorage или сделать в виде браузерного расширения, не трогая код браузера. Плюс, насколько она проще в сравнении с вашим решением.
Лично мне нравится идея использования вместо логина/пароля физического ключа (где хранится неизвлекаемый токен), плюсы: не надо придумывать и запоминать пароль, неуязвимость для фишинга, нельзя украсть с помощью вируса, а только физически отобрав ключ. Минус: так как ключ неизвлекаемый, неудобно делать бекапы. Может быть, тут стоит пожертвовать безопасностью в пользу удобства и сделать ключ извлекаемым. Как я понимаю, для его реализации не требуется придумывать новые стандарты, а можно использовать существующие наработки по использованию смарт-карт, которой ключ по сути и является.
запутанные правила передачи токенов… Их трудно запомнить и при работе с ними легко допустить ошибку
Эти правила для разработчиков браузера. Сложными они кажутся лишь потому, что мне не удалось их лаконично описать. Моя вина. Я попытался не только описать эти правила, но объяснить зачем они такие, да на конкретных примерах, да с картинками. Это перегрузило и так не простую статью. Что касается сложности, если почитать стандарт CSS… Бедные разработчики браузеров!
Разработчикам веб-сайтов не нужно их запоминать. Всю низко-уровневую работу с протоколом, по задумке, должны на себя брать библиотеки, оформленные, например, как фильтр запросов.
Что касается фронтенд разработчиков. Всё что им нужно помнить — несколько простых правил: не использовать в закрытых разделах сайта скрипты, загружаемые с CDN или сторонних ресурсов (точне можно, если осторожно); осторожнее делать редиректы на сайты-партнеров. Эти рекомендации стоит включить в соответствующую главу. Но сейчас её нет. Мой косяк.
ваше решение слишком сложное. Вообще, в вашем протоколе все сложное. Это его ахиллесова пята.
Боюсь, что не без этого. Но с другой стороны, откройте любой стандарт. Тот же HTTP, SAML, OAuth, Kerberos. И там тоже всё не так просто. Я за простоту.
На мой взгляд, один из вариантов решения для борьбы с CSRF мог бы быть...Так сейчас так и делается. И не только так. Но нередко даже самые лучшие профессионалы допускают досадные ошибки. Ибо такие «правила» тоже необходимо четко помнить и держать в голове при разработке сайта. Предлагаемый протокол может существенно затруднить эксплуатацию уязвимостей на веб-страницах «из коробки». Но 100% гарантий вам никто не даст. Это надо понимать.
Также, у вас неудачная идея вида «браузер может отправить заголовок с запросом на любую страницу».
Я даже неправильно поставил акцент: не может, а обязан. Ибо не только веб-страницы будут требовать авторизации, но и загружаемые с них ресурсы (файлы из закрытой секции, как пример). Отсюда напрашивается и вариант реализации на стороне сервера — фильтр запросов, обрабатывающий протокол.
Как, например, насчет залогинивания под двумя аккаунтами сразу?С этим кейсом не знаком. Интересуют подробности. И как это технически реализуется сейчас. Напишите.
Или вы имеете в виду ситуации, когда вы одновременно, скажем, в яндекс.почте работаете с несколькими ящиками? Подобное реализуется. Я не стал писать, боясь и так переусложнить статью (признаюсь стоило бы выкинуть из неё несколько глав).
например может быть несколько приложений внутри одного домена
Думаю, что это плохая практика. Даже для существующей схемы на основе cookie. Но и это решаемо. Спасибо за этот юзер кейс. Буду исследовать.
Это явно фича для продвинутых, а не обычных пользователей.Согласен. Но большинство современных фич тоже когда-то были «только для продвинутых».
Сайты, очевидно, хотят контролировать вид формы входа/регистрации и их процесс, чтобы иметь возможность сделать его лучше, чем у конкурентов, а не «как у всех». Чтобы иметь возможность сделать его простым.Знаете, мне когда-то зацепил подход сайта drom.ru. Хочешь подать объявление о продаже авто? Да не вопрос. Подавай. На телефон приходит код твоего объявления. Ты можешь через неделю отправить платную СМС-ку, чтобы поднять свое объявление в топ. Или ничего не делать. Никаких предварительных регистраций, логинов и паролей. Это, я считаю, и просто и удобно. Не знаю как сейчас там. Но на авито или ам.ру продавать авто точно не буду.
сохранить токен с сайта в браузер и достать токен из браузера?Центральная идея протокола — токен назначается не сайтом, а пользователем самим себе. Собственно, протокол и назван Client Self Identification.
Кроссдоменную авторизацию проще было бы делать без участия встроенных в браузер протоколов, используя протоколы вроде OAuth2. Сайты ведь всегда могут передавать друг другу какие-то токены через адресную строку.Сейчас так и делается. Поверьте, не проще. Для пользователя — да. Но для веб-разработчиков нет. И хотя есть библиотеки, реализующие за вас не простой OAuth2, существует ещё и дополнительная работа, ложащаяся на плечи разработчиков/администраторов сайта. Например, ситуации, когда внезапно «упало». Нет доступа до сервера SSO. Закончил срок действия сертификат ключа. Да и регистрация веб-сайта на SSO-сервере тоже задача не излегких. Особенно на этапе разработки.
Ваше решение не поможет анонимности, так как сайты будут игнорировать его и принуждать пользователя к традиционной авторизации через куки, чтобы отслеживать их.Я надеюсь настанут такие времена, когда такие сайты вымрут, как класс. Пользователи своими «визитами» (точнее их отсутствием) будут голосовать против них.
В описании протокола в пункте 2.3 вы считаете, что запросы отправляются по одному по очереди, однако браузеры шлют запросы параллельно. Запросы могут выполняться очень долго или отваливаться по таймауту. У вас это учтено?
Учтено. Первый запрос на сайт браузер посылает на сервер и ждет от него ответа. Как правило, это код HTTP-страницы. Только после получения её кода, когда DOM попадает на парсер, браузер начинает группировать запросы и слать их пачками параллельно. В этот момент браузер уже получил соль от сервера. Он пришел с кодом HTTP-страницы.
Если загружается не страница, а конкретный файл (по прямой ссылке), то тут вообще всё проще.
Чуть выше я как раз-таки и пишу: «В идеале CSI-Salt должен меняться при каждом запросе браузера к серверу. Однако это может быть затратным требованием с точки зрения вычислительных ресурсов. Кроме того, это может «убить» возможность отправки параллельных запросов на сервер.»
Также в сноске я пишу: «Время, через которое делается изменение CSI-Salt определяется браузерами самостоятельно. Это может происходить после серии запросов, после таймаута, после определенного числа запросов.»
Допустим, браузеру надо отправить параллельно 50 запросов на загрузку статики. Он к каждому будет прикреплять поле changed или только к первому?
Тоже самое касается запроса с ключем Changed-To. Браузер шлет запрос и ждет на ответа сервера. Только получив положительный (или отрицательный) ответ с заголовком CSI-Token-Action, начинает слать запросы «пачками». Запрос с ключем Change-To относительно редкая операция. Возникает в момент, когда пользователь активирует постоянный ключ (браузер должен перезагрузить страницу). Соответственно, вначале браузер дожидается ответа на этот запрос. А после, получив DOM страницы и заголовок CSI-Token-Action, начинает уже слать запросы пачками. К сожалению, я этот момент (перезагрузки браузером страницы после активации ключа) не отразил ни в тексте, ни в анимациях.
Зачем при передаче по HTTPS как-то шифровать или хешировать токен, мне непонятно.Затем, что HTTPS-трафик тоже может быть перехвачен. У меня есть глава по этому поводу, но я не стал включать её в статью, боясь вызвать ненужный спор. Если хотите, я могу вам скинуть в её личку. Кроме того, протокол проектировался без учета среды передачи (HTTP/HTTPS). Поэтому правила защиты токена едины.
для чего шифровать токен, который к другим сайтам не подойдет?другим не подойдет, но имея такой токен можно выполнить легитимный запрос на целевой сайт от имени жертвы пока «сессия жива». Такая модель угроз рассматривается в разделе «4.6 Компрометация токена при передаче».
Зачем нужны Sender/Receiver и правила работы с ними, если гораздо проще просто не передавать токен при кроссдоменных запросахЗатем, чтобы иметь возможность реализовывать меж-доменную идентификацию на группе взаимосвязанных доменов А, В, С. Это стандартная ситуация. Почему меж-доменная идентификация A,B,C возможна, но при этом трекинг сторонними сайтами (например, группой сайтов В, С,D) уже не возможен, рассматривается в модели угроз «4.1 Трекинг пользователя».
Ещё раз повторюсь эти правила — для разработчиков браузеров. Рядовой пользователь или веб-мастер даже не будет знать о них.
Какая выгода сайтам от интеграции вашего решения?О я ждал этого вопроса! Этому можно посвятить отдельную статью.
Ну, например, какая выгода сайту от использования HTTPS супротив HTTTP? Безопасность пользователя? Но ведь какое дело до безопасности разработчику сайта?
Дизайнеру сайта, например, проще — нет лишних виджетов. Сейчас всё движется в сторону простоты. На мобильном экране с маленьким экраном лишний виджет — головная боль для UX-специалиста.
Веб-мастеру: минус несколько стандартных служебных страниц (регистрация, восстановления пароля, авторизации).
Ну и, наконец, простота для пользователя. Как следствие, увеличение конверсии.
Действия могут вызываться яваскриптом или мета-тегами.Ни в коем случае в это не должен вмешиваться javascript! Красными буквами это выписать! Это потенциальная дыра!
можно использовать существующие наработки по использованию смарт-карт, которой ключ по сути и являетсяЯ писал про плюсы и минусы смарт-карт. Протокол не налагает ограничений на источник ключевой информации. Это могут быть и аппаратные устройства с двух-факторной авторизацией.
Эти правила для разработчиков браузера. Сложными они кажутся лишь потому, что мне не удалось их лаконично описать
И для веб-разработчиков, которым их придется изучать. Так как задача веб-разработчика — чтобы все на сайте работало правильно при всех вариантах переходов с сайта/на сайт.
Всю низко-уровневую работу с протоколом, по задумке, должны на себя брать библиотеки, оформленные, например, как фильтр запросов.
Это так не работает. Для отладки какой-то проблемы приходится лезть и вручную разбирать заголовки. И ваши запутанные правила.
С этим кейсом не знаком. Интересуют подробности. И как это технически реализуется сейчас. Напишите.
Или вы имеете в виду ситуации, когда вы одновременно, скажем, в яндекс.почте работаете с несколькими ящиками?
Это я привел только для того, чтобы показать, что ваше решение заточено на один сценарий. Завтра появятся новые потребности, а ваше решение не будет к ним готово.
Учтено. Первый запрос на сайт браузер посылает на сервер и ждет от него ответа. Как правило, это код HTTP-страницы. Только после получения её кода, когда DOM попадает на парсер, браузер начинает группировать запросы и слать их пачками параллельно.
HTML-файлы парсятся поточно, по мере загрузки. И новые запросы могут отправляться до окончания получения HTML-файла, хотя заголовки к этому моменту уже получены.
Затем, что HTTPS-трафик тоже может быть перехвачен. У меня есть глава по этому поводу, но я не стал включать её в статью, боясь вызвать ненужный спор.
Сейчас идет тенденция к переводу всего на HTTPS. Например, Firefox показывает предупреждение при вводе пароля в форму на HTTP-странице. Следовательно, ваше самодельное шифрование избыточно, сильно усложняет протокол, тем более, как я понял, в первый раз токен все равно передается без шифрования.
Веб-мастеру: минус несколько стандартных служебных страниц (регистрация, восстановления пароля, авторизации).
И риск потери ключа при переустановке браузера. А от регистрации они не откажутся, так как им нужен email для рассылки спама.
Создав при помощи мастер-ключа M персональный ключ K для домена D на одном устройстве, пользователь сможет создать тот же самый ключ K для домена D и на любом другом при помощи всё того же мастер-ключа M и единого алгоритма. Точнее это сделает не пользователь, а его браузер. При таком подходе пользователю достаточно распространить свой мастер ключ между всеми используемыми им браузерами и он разом «переносит все свои ключи» доменов. Заодно делает таким образом резервные копии.
то есть вот захочу на работе или в недовернном окружении зайти на сайт habr.com, риски угона учетной записи к-рого для меня низки, — и «привет» — учетные данные на всех остальных сайтах приезжают скопом.
Захотел воспользоваться другим браузером или приложением или скриптом — облом.
А альтернативы — собственно, все то, что уже используется: Dash, OnePassword, LastPass или токен.
А уж какая красота для вирусов. Зеродей в браузере или винде и здравствуйте все аккаунты пользователя.
Мастер-ключ (который по факту просто случайное 256-битное число; не пароль пользователя!) может использоваться на сайтах, для которых вам не жалко потерять авторизацию (всякие одноразовые форумы, магазинчики). Мастер ключ дает вам 100% мобильности, но и повышенный риск. Я об этом в статье писал.
Для сайтов, к которым доступ чувствительный, нужно использовать только индивидуальные 256-битные ключи, хранимые на смарт-карте (на отчуждаемых носителях с двух-факторной авторизацией).
Как же вы далеки от реальности...
Берём почту Гугла или Яндекса. И их же ССО завязанный на эту почту. Чувствительнее некуда. Вся жизнь там. А логиниться туда надо со всех своих устройств и иногда даже с чужих. Значит они будут под мастер ключем раскиданным по куче устройств. Кейс логина с чужого устройства я вообще не понимаю как реализовать.
Смарткарта каждому? А зачем тогда все это? Есть же стандартные протоколы авторизации для них. Они хорошо работают в теории. На практике всем лень.
Менеджер паролей дает возможность не ставить его на каждое устройство которым ты пользуешься. Да и сценарий логина с чужого устройства вполне решается.
И ваши опасения здесь понятны. С яндексом у вас нет выбора: только ССО. Вы не можете индивидуально сделать пароль к каждому сервису яндекса.
В идеале, для каждого сервиса яндекса должна быть отдельная аутентификация.
Яндекс тут решил свои проблемы, забив на ваши. Да простят меня сотрудники этой компании)
Одно дело, когда вы компрометирует доступ в Яндекс.Маркет или Яндекс.Музыка. И другое дело, когда в Яндекс.Кошелек.
Вы можете точно также войти в Яндекс.Почту с постороннего компьютера (арендованный ноутбук в интернет-кафе какого-нибудь отеля в теплых странах; и не зарекайтесь, что с вами это никогда не случится), и «спалить» свой пароль. Но этот пароль даст доступ ко всем сервисам яндекса от вашего имени. И эта проблема не только Яндекса. Это проблема всех крупных ССО: майл, гугл, да кто там ещё?
Как вы, может быть, помните, технология кросс-доменной авторизации появилась как раз-таки как основной способ решения «парольной проблемы». ССО вас избавляет от необходимости иметь кучу учёток на разных сайтах и иметь кучу паролей к ним. ССО авторизует вас на сайтах, избавляя от необходимости в предварительной регистрации и аутентификации. Удобство — да. Но и риски велики. В информационной безопасности, к сожалению, в большинстве случаев чем удобнее, тем менее безопасно.
Предлагаемый протокол решает «парольную проблему» иным способом. Он делает крайне легким генерацию аутентификационной информации и процедуру логина (вопрос пары кликов). А это значит, что основная и самая сложная проблема: «придумать уникальный пароль, запомнить его и хранить» — решается просто. При таком функционале ценность ССО значительно снижается. Оно уже не так необходимо. Я не призываю отказываться вообще от этой технологии. Но вы должны понимать, какие риски она влечет и почему.
Теперь далее. В статье это говорится, но я повторюсь. Протокол определяет два способа формирования ключей: на базе мастер-ключа (который суть 256-битное случайно сгенерированное число); на базе индивидуального 256-битного ключа. Возможно, я не исключаю вариант, что стоит вернуться ещё и к третьему способу: формирование ключа домена на базе пароля пользователя. Необходимо решить вопрос с коллизиями паролей и стойкостью к брутфорсу. Но давайте для упрощения представим, что мы уже сделали это — ввели этот третий способ формирования ключа домена.
Каждый из этих способов имет свои плюсы и минусы, а потому может применяться в следующих сценариях:
1. Мастер-ключ. Средняя мобильность (необходимо предварительно распространить его среди ваших устройств). Наибольшая удобность при аутентификации и регистрации. Наименьшие риски при потере (вы ведь распространив по устройствам де-факто сделали его резервную копию). Наибольшие риски при компрометации. Риски к краже руткитами или при административном НСД к вашему компьютеру (их можно уменьшить). Поэтому используется только на сайтах с низким уровнем ответственности. Всякие форумы (где вам необходимо задать вопрос или скачать файл «только для зарегистрированных», а потом навсегда забыть этот сайт), блоги (где вы решили оставить комментарий) и т.п. чепуха. Ну скомпрометируете ключ — да и фиг с ним. Одноразовые доступы. Туда им и дорога.
2. Индивидуальный ключ. Низкая мобильность. Меньшая удобность в использовании. Но наилучший уровень безопасности. Можно вынести на хранение в смарт-карты. Существуют риски утраты (сломалась смарт-карта). Предполагается к использованию на серьезных сайтах (личные кабинеты провайдеров, финансовых учреждений и т.п.) и только на доверенных устройствах. Предполагается, что такими ключами идентифицируется уже ваша личность (ибо серьезно). Если вы используете такой ключ «где попало» — вы сами себе враг. Мобильность можно обеспечить отчуждаемыми носителями (смарт-карты).
3. Ключ на базе вашего пароля (который у вас голове). Высочайшая мобильность. Решает проблему, когда нужно срочно зайти с чужого компьютера. Риски к клавиатурным шпионам. Но при этом взлом сайта не приводит к компрометации вашего пароля. Удобно. Но необходимо помнить пароль. Вы можете завести себе пару-тройку таких очень «мощных» паролей для разной категории сайтов. Вполне приемлемое число.
Да, я знаю. Это выглядит сложно и запутано. Безопасность она всегда сложная. Но частично эта проблема решается хорошим UI-интерфейсом и обучением общей грамотности пользователей. Посмотрите сколько в интернете статей и заметок на тему того, какие пароли необходимо придумывать и как их правильно хранить.
Вот ещё, например, такой UI-кейс. Браузер не позволит вам сделать ключ на базе мастер-ключа, если сайт имеет SSL-сертификат определенной категории (а такой сертификат может получить только крупная уважаемая компания; а Let's Encrypt, скажем такие не выдаст). Т.е. сделать ключ для Сбербанк.Онлайн от мастер-ключа у пользователя не получится. Но с этим необходимо осторожнее. Здесь должны подключиться спрециалисты по UI-интерфейсам.
Вы не думайте, что придумав какой-то протокол, мы сразу сделаем мир лучше. Проблема должна решаться комплексно. Разработчики браузеров — решают свою часть. Веб-разработчики — свою часть. Разработчики библиотек протокола — свою часть. Попутный софт (nginx) — свою. Обучение пользователей соответствующими статьями — то же мера.
А что касается Яндекса. Это плохо, что у них все завязано на passport.yandex.ru и без альтернативно. Само ССО удобно. Но отсутствие альтернативы — удручает. К сожалению, мой протокол не решает эту проблему. И эту проблему не решит никакой протокол.
Касательно SSO — я так понимаю, что компрометация яндекс.почты как сервиса не приводит к компрометации других сервисов Яндекса. Другой вопрос, что здесь появляется третья сторона — сам SSO-сервис, который и выступает гарантом идентичности пользователя. С тем же успехом это мог бы быть государственный УЦ или что-то подобное.
Сейчас это просто, удобно и безопасно. Уговорить пользователей делать хорошие пароли от почты удалось. Не всех, но многих.
Вы вместо простого и безопасного решения предлагаете нечто нереально ложное. Даже на Хабре требуются дополнительные объяснения. А как вы будете бабушке объяснять все это? Сейчас она жмет одну кнопку и все ок. ССО авторизация работает почти на любом сайте. А в вашем случае что ей надо сделать?
ССО через гугл — ну да, это удобно, но в этом случае ваша цифровая identity принадлежит гуглу, а не вам, со всеми вытекающими проблемами (от банального сбора информации о том, какими сервисами вы пользуетесь до проблем типа "кажется ваш аккаунт взломали, пока не подтвердите, что вы это вы — никуда не залогинетесь"). Существует мнение, что это неправильно, и что можно сделать лучше — даже термин придумали, для этого "лучше" — Self-Sovereign Identity. То, что предлагает автор статьи очень близко к идеям SSI.
то есть вот захочу на работе или в недовернном окруженииВаше право. Но не храните все яйца в одной корзине.
Dash, OnePassword, LastPass могут использоваться совместно с описанным протоколом. Он (протокол) не отменяет других средств защиты, а органично может их дополнить.
Обратите внимание, сейчас зависимость моих паролей на различных сайтах и мастер-ключа отсуствует:
— я могу сменить мастер-ключ
— я могу потерять мастер-ключ — и он обо мне ничего не скажет (без дополнительной информации — на каком ресурсе и с какой УЗ он использовался).
В случае вашего мастер-ключа тот, кто завладел им, завладел *всеми* доступами.
Ключ на базе вашего пароля (который у вас голове). Высочайшая мобильность. Решает проблему, когда нужно срочно зайти с чужого компьютера. Риски к клавиатурным шпионам. Но при этом взлом сайта не приводит к компрометации вашего пароля — самая главная фишка. Т.е. вы можете не бояться повторно использовать пароль на других сайтах.
Удобно. Но необходимо помнить пароль. Вы можете завести себе пару-тройку таких очень «мощных» паролей для разной категории сайтов. Вполне приемлемое число.
А вы случайно не Decentralized Identifiers DID пытаетесь изобрести? Ну и вообще можно погуглить тему Self-Sovereign Identity...
Для меня же идея вообще не применима, разбираться с тем как перенести мастер-ключ на разные девайсы не хочу, иногда хочу авторизоваться дома у друга, что сильно проще через гугл, иногда хочу переставить винду.
Протокол не накладывает ограничения на источник ключевой информации. Это может быть браузер, или некий security-proxy, или хардварный девайс.
На данный момент не все устройства достаточно защищены, чтобы это стало массовым, но это лишь дело времени.
- Возможность разблокирования без желания пользователя — приложить к пальцу спящего человека, либо по настойчивой просьбе соответствующих органов (они и пароль так же попросить могут, но его всегда можно «забыть»).
- Невозможность создания мультиаккаунта, в случае если вы не доверяете сервису и хотите каждый раз выглядеть новым пользователем. Пароль можно сколько раз угодно новый придумывать, а радужка\отпечаток\лицо у вас одни.
- Тотальное распространение биометрии делает нас на шаг ближе к китайскому сценарию, переводя такой способ авторизации во что-то повседневное и привычное.
- Необходимость наличия собственно устройства. Пароль можно держать хоть в голове, хоть на бумажке в тайнике, и вводить его на любом девайсе. Биометрия же требует как минимум, телефона с соответствующими датчиками.
Самое главное забыли — невозможность смены пароля (отпечатка) в случае его компроментации.
Снять отпечаток иногда можно даже по качественному фото, на котором вы машете ручкой. После печать на пленке и к пальцу.
Но это для физического получения самого "мастер ключа". Перехват авторизации по отпечатку отличается от перехвата пароля только сложностью (длиной) самого пароля. Или как вы себе представляете инфраструктуру авторизации?
Идея с биометрией плохо применима в интернете. Нужно передавать биометрические характеристики в сеть. Любой, кто завладеет характеристиками может их запомнить и логиниться на всех сайтах, куда мы ходим. Тоесть биометрия может выступать разве что дополнением к какому-то другому средству аунтефикации.
Идея с биометрией плохо применима в интернете. Нужно передавать биометрические характеристики в сеть.
зачем? при накате пальчика — он никуда не передается. и нужен только для локального контроля доступа.
и передавать для аутентификации его тоже никуда не нужно.
А что передаётся? От "локального контроля доступа" к сайту? Опишите ваше видение аутентификации по биометрии...
Отличный труд! Рекомендую не бросать, а довести до конца.
Как-то привязка именно к домену не очень здорово звучит
Для сайтов, которые работают в группе, а также для сайта, который доступен на нескольких доменах, можно применить технику меж-доменной и кросс-доменной идентификации пользователя согласно протоколу. Допускаю, что в некоторых случаях, это может быть накладным для разработчиков. Надо прорабатывать конкретные случаи и вырабатывать рекомендации с готовыми примерами «под ключ».
В любом случае, Ваше замечание я принял в работу.
привязка именно к домену не очень здорово звучиткогда начинал проектировать протокол, тоже думал в таком ключе. Но, у клиента большая свобода в генерации токенов, а значит мы можем этим играть.
В разделе про кросс-сайтовые переходы поймал себя на такой мысли. Допустим, site1.ru загрузил скрипт с site2.ru. Этот скрипт создал ссылку, ведущую на site2.ru. С точки зрения протокола, она будет считаться ссылкой на внешний сайт, созданной внешним сайтом. Но есть ли какие-то препятствия к тому, чтобы считать её "доверенной" (в некотором смысле, конечно)? Ведь site2.ru её сам для себя сделал, никакой evil.ru, в том числе и site1.ru, в этом не участвовал.
С точки зрения протокола, она будет считаться ссылкой на внешний сайт, созданной внешним сайтом.все верно.
Но есть ли какие-то препятствия к тому, чтобы считать её «доверенной»Есть. site1.ru не может ручаться за действия скрипта с сайта site2.ru, который по факту может принадлежать сторонней организации. Это небезопасная операция. Если у вас есть пример ситуации, где это реально нужно, давайте конкретный пример, обсудим.
Я приведу свой. Сейчас на страницах Сбербанк-Онлайн внедрена Яндекс.Метрика. Сторонний скрипт от компании, с которой у Сбербенка нет никаких юридических договоренностей, вроде NDA. Кто видел в действии ВебВизор метрики, тот знает, что она записывает реально «все» ваши действия на сайте: движения мышкой, какой текст выделяли, что и куда вводили. Естественно туда утекает и ваш логин/пароль.
Каждый счетчик метрики имеет уникальный номер. Сотрудникам Яндекса не составляет проблем подгружать именно на страницу Сбербанк-Онлайна модифицированную версию метрики, которая делает «дополнительную» работу.
Я когда проектировал прокол, особо учитывал это случай.
Я говорил про случай, когда пользователь явно переходит по сгенерированной ссылке — к примеру, представим, что на Хабре (он здесь в роли site2.ru) выложили скрипт, который можно вставить на личную страницу (site1.ru), передать ему номер статьи, и он сгенерирует preview статьи и ссылку на неё (не реальный кейс, естественно, но достаточно наглядный). Но да, я упустил тот факт, что в самой сгенерированной ссылке может потенциально храниться произвольная информация, в том числе и та, которая с site1.ru утекать не должна.
Вот если рассматривать ситуацию ровно в том контексте, что Вы описали, то проблем вообще не возникнет никаких. Но если вы «тянете» контент, доступный только авторизованным пользователям, то да — может быть проблема. И она может выскочить в самом неожиданном месте. Следите за руками.
Пусть есть у вас сайт, на котором авторизованный пользователь может смотреть некие графики. Например, статистику по серверному оборудованию. Стата эта отдается в виде JSON отдельными подзапросами. Но не отдается анонимусу. И это важно. А для отрисовки красивых графиков вы решили не изобретать велосипед, а использовать готовую стороннюю библиотеку. А чтобы иметь её самую свежую версию, – загружаете прямо с github.
1. Чтобы отрисовать график, ваш скрипт запрашивает данные с вашего сервера и отдает на отрисовку либе. Проблем пока нет. Скрипт делает запрос, правила выполняются, авторизация пользователя «не слетает».
2. Представим, теперь, что библиотека сама умеет запрашивать JSON-ки с вашего сервера. Вы говорите ей, где их и как брать. Она это делает. И вот тут возникает проблема!
Чужой скрипт делает запрос к вашему серверу. Понятно, что в нашей ситуации ничего криминального тут нет. Но одному богу известно, что хочет от вашего сервера сторонний скрипт! Такая попытка автоматом блокируется правилами вычисления токена.
3. Аналогичный облом возникнет, если библиотека не сама качает данные с вашего сайта, а просит ваш скрипт сделать это для неё.
По такой схеме может работать, например, api яндекс.карт. Вы там заводите Observer. Он вызывает ваш скрипт. Вы делаете ajax-запрос. Апи наносит точки на карту. (Это апи позволяет по разному грузить данные. В том числе и самостоятельно). Кажется я ничего с ним не напутал?
Но это и не принципиально. Принципиально объяснить, почему тут выходит облом.
Потому что, в цепочке вызовов скриптов, приводящих к запросу, был чужой скрипт. И если мы не учтём данный факт, то открываем целый класс возможных атак чужих скриптов на ваши. Javascript ещё та штучка.
4. А если очень нужно? Тогда качаем библиотеку с github и грузим её уже с вашего сайта. Теперь вы, как разработчик сайта, несете ответственность за содержание кода библиотеки и ручаетесь, что она «не порождение зла».
Но такой подход может быть применен не всегда. Например, тот же случай с яндекс.картами. Попробуй выкачай все компоненты библиотеки! Тот ещё квест. Да и не правильный подход это. Оригинальный код api поменяется, и через некоторое время вы рискуете получить полностью неработоспособного клиента.
5. Но что если совсем никак, а очень нужно? Сторонее api через нас просит скачать некий контент с нашего сайта. Он закрыт для анонимусов. API перенести к себе мы не можем. Авторизация слетает. Как быть?
Используем тот факт, что авторизация нам нужна на нашем сайте (а не на чужом). Генерируем для нашего скрипта некий сеансовый ключ, авторизующий его запросы. Теперь наш скрипт, делая ajax-запросы посылает этот ключ среди параметров. А сервер валидирует именно эти запросы не только по токену, но и по ключу.
Через cookie передавать это, я бы не стал. Что-то мне подсказывает, что с cookie могут и тут возникнуть проблемы. Вообще решений здесь много. Нужно каждое исследовать с точки зрения безопасности и удобства.
Т.е. в п. 5 помимо токенов придется ещё и такой ключ учитывать. Сложно. Не очень системно. Согласен. Я уже поставил себе таск на исследование этого.
Но обратите внимание, этот подход очень похож на тот, что используется для защиты от CSRF (одна из мер). Т.е. протокол вынуждает разработчика реализовывать защиту даже в этом случае! По крайней мере, то, что мы обратили внимание на это разработчика, – уже хорошо. Ведь, какой бы ни был хороший разработчик, человеческий фактор ошибки никто не отменял.
Прав Sabubu, когда говорил, что протокол имеет запутанные правила и разработчикам необходимо их учитывать. А я думаю, что многие такие кейсы всплывут на тестовых стендах. И будут найдены хорошие решения. По их результатам можно сделать что-то вроде cook-book с best practice. И ещё нужно будет подумать на диагностикой и отладкой таких непредвиденных ситуаций.
Всё-таки тестовая реализация нужна; но только после тюнинга этого протокола с учётом высказанных замечаний.
Мне кажется, что достаточно будет просто пояснять, почему закрыта или усложнена та или иная возможность. То есть, например, ограничение на работу сторонних скриптов небезопасно потому, что… и далее следует ссылка на список угроз от сторонних скриптов. Затем по списку приводятся решения, обеспечиваемые протоколом. В итоге разработчик, даже если ранее не сталкивался с безопасностью, просто читает список угроз и предлагаемые протоколом решения, а далее он просто делает выбор, исходя из своей ситуации и полного (я надеюсь) понимания, какие проблемы с безопасностью он получит. Таким образом сложность протокола становится объяснимой. То есть сложность не нужно уменьшать во что бы то ни стало, если можно просто объяснить — сюда пойдёшь — снег башка попадёт, совсем мёртвый будешь. Но вот это «снег башка попадёт» должно присутствовать где-то рядом с протоколом. А иначе — будет необъяснимая (кажущаяся ненужной) сложность. Ну и сам автор протокола, пока пытается объяснить сложность, глубже поймёт варианты реализации, и даже возможно найдёт более простой.
Владельцы сайтов, браузеров, соц сетей кровно заинтересованы в сборе информации о посетителях
А браузеров-то каким образом? Ну, кроме Гугла, которому вообще нужно знать всё, независимо от браузера.
Ну, любая компания хочет улучшать свой продукт. Для этого сбор информации от клиента практически необходим — начиная от конфигурации, кончая кейсами применения.
Почему браузеров? Потому что большинство приложений сейчас уже в вебе — раз, два — интернет очень прочно проник в нашу жизнь и без него никуда. А браузер — это по сути окошко в Интернет.
Так кто мешает эту информацию собирать с сохранением упомянутой вами анонимности в сети? Кроме жадности создателей, разумеется, но опять-таки, браузеры делает не только Гугл.
Извините, не понимаю Вашей позиции.
Так создателям (владельцам) браузеров нужно собирать информацию или нет? Мое мнение — да.
Касательно анонимности — как только объем данных переваливает за какой-то предел, то очень легко становится даже анонимные данные собрать в систему. Ну, представьте себе такой пример. Вы знаете из источника А, что в стране есть 10 богатых людей. А из источника Б получаете список транзакций, только очищенный от имен (они там обфусцированы). Но при сопоставлении списка А и Б легко можно найти транзакции именно людей из списка А. А далее уже можно попробовать установить личность каждого.
Я уж не говорю о том, что любой мало-мальски крупный сайт будет пытаться поставить свою куку или супер-куку или вообще идентифицировать пользователя пикселом.
Защиты от XSS не будет. Будет защита от некоторого вида xss при определенном векторе эксплуатации, при прямом векторе эксплуатации активных xss или же хранимых xss никакой разницы не будет. Если идея в том, что нельзя украсть куки — никто не мешает атакующему не красть ваши "токены" а сделать все на месте вашими же руками, даже готвоые решения есть, например BEEF
Что предлагает новый протокол?
С точки зрения конечного пользователя:
Сайт должен запоминать и узнавать посетителя без какого-либо ввода данных со стороны пользователя; сайт должен узнавать вас как в пределах сессии, так и между разными сессиями. Никакихcookie, паролей и регистраций.
Элементарно. При первом заходе сервер генерит PHPSESSIONID (или что там у них), устанавливает куки. Пользователь идентифицирован.
При этом разные сайты не должны получать возможность взаимно однозначно идентифицировать одного и того же посетителя, получая возможность отслеживать его активность на этих и других сайтах.
Запрещаем 3rd party cookies в браузере. Или имелось в виду что-то другое?
Пользователь должен получить возможность «забыть любой сайт» в любое время; и сайт забудет пользователя. Должна быть возможность предоставления прав сайту запомнить клиента по инициативе клиента (без навязчивых popup).
Куки-менеджер.
Пользователь должен получить возможность безопасной миграции своей виртуальной личности между разными устройствами и браузерами (если ему это нужно), чтобы иметь единую авторизацию на любимых сайтах.
Синхронизируем директорию с куками через дропбокс. Или копируем вручную. В любом случае, способ синхронизации файлов — это что-то внешнее для протокола идентификации пользователей. Какой резон упаковывать все это в один стандарт?
Или я пропустил какие-то ключевые требования к новому протоколу, которые не удовлетворяются куками?
Элементарно. Автор перевернул с ног на голову, как я понял. Не сервер ставит куку клиенту, а клиент рапортует серверу, что он это он. Т.е. это обязанность сервера матчить токен со своей внутренней базой. С другой стороны… Это очень похоже на PKI с раздачей сертификатов всем клиентам. Но любой PKI — это централизация. А посыл автора, если я не ошибаюсь, был именно в создании двухзвенной структуры без третьего доверенного лица...
Не сервер ставит куку клиенту, а клиент рапортует серверу, что он это он
Это я понял, да. Но это особенности реализации. А вот какую задачу/проблему должен решить этот подход с клиентской генерацией айди, мне и неясно.
Но это особенности реализации.Эта особенность кардинально всё меняет.
1. Клиент получает большую независимость от сервера. Клиент сам решает какой ID в какой ситуации слать. По какому алгоритму вычислять. Это дает эффектные способы защиты от известных сетевых атак.
Стандартизация алгоритмов формирования токенов защищает пользователя от кривых реализаций. Браузер не сможет пойти мимо стандарта. Иначе это вызовет несовместимость с другими браузерами.
Браузер не сможет использовать искусственно ослабленные ключи, иначе это вызовет коллизии у разных пользователей на стороне сервера. Ну и не совместимость, опять же. Спалится тут же.
2. Мы часто слышим, о массовых утечках паролей пользователей в результате очередного взлома сайта. Представьте, что ваш ценный очень сложный пароль, который вы хранили как зеницу ока вдруг стал бесполезным. Обидно? Да. Очень многие сайта забивают даже на простейшее хэширование паролей. По не знанию или халатности.
Основой посыл потокола такой. Если вы, уважаемые веб-мастера, не умеете или не хотите хранить надежно аутентификационные данные ваших пользователей. То мы-пользователи, лишаем вас этого права. Вы теперь должны «матчить» ID, который мы вам предоставим сами. И что с ним делать — ваша забота.
Клиент получает большую независимость от сервера
А какую из проблем, перечисленных в начале статьи, это решает?
Я вот в комменте выше процитировал проблемы, которые вы привели в статье. "Генерация сессии на стороне сервера" там не фигурировала. И не может фигурировать — потому что пользователю это неважно.
А насчет второго пункта — вообще мимо кассы. Какая разница с точки зрения вебмастера — хранить в базе пароль или токен? Точно так же его могут небезопасно хранить и допустить утечку.
Какая разница с точки зрения вебмастера — хранить в базе пароль или токен? Точно так же его могут небезопасно хранить и допустить утечку.
Компрометация токена при взломе сайта не приводит к компрометации исходной информации (ключа или парольной фразы), на базе которой он был вычислен. Т.е. ровно эта же информация может использоваться для генерации токенов для других сайтов. Это может быть мастер-ключ или ваша парольная фраза.
Про парольную фразу — я уже всерьез раздумываю вернуть обратно в протокол вариант генерации ключа домена от пароля.
Компрометация идентификатора сессии (в случае автоматической беспарольной сессии, как в моем примере выше) тоже не компрометирует никакие другие сайты. Несмотря на то, что айди сессии генерируется на сервере.
Можно так.
Опишите сценарий работы пользователя, в котором вы видите проблему. И мы посмотрим, как эта проблема решается новым протоколом, и почему она не решается существующими технологиями.
Писал-писал ответ, перечитывал-перечитывал текст.
Если отбросить детали про соль (кмк, ненужные при наличии https), то получился аналог Authorization: Bearer .
Суть инновации, как я ее вижу
1) Создание стандартного протокола регистрации (ну и замена токена бонусом). Упрощая: если сервер не узнает токен из заголовка, он создает новую учетную запись с этим токеном.
Постоянный/временный ключ, даже само наличие мастер-ключа в принципе — это уже вопрос удобства пользователей. Браузеры могут решать его как угодно. Хоть сторонними плагинами (при наличии минимального api в браузере для управления токенами). На взаимодействие между сервером и клиентом это никак не влияет.
Я правильно понял?
А какую из проблем, перечисленных в начале статьи, это решает?
Защита от трекинга, XSS, CSRF. Клиент получает возможность манипулировать своим ID в зависимости от контекста и формируемых запросов. Менять на лету. Если сервер вам назначил ID, вы уже не можете это изменять. И не важно как именно он передается: в куках или иных заголовках.
Может быть вы имеете в виду, что сервер вам может и так (помимо протокола) присвоить сессионный ID и записать его в куки (да хоть в код на странице)? Конечно, может. Но протокол обяжет для идентификации использовать исключительно Token-ID.
Может веб-мастер забить на болт на Token-ID и использовать куки (типа мне пофигу, мне так удобнее)? Технически может. Но тогда он ставит под угрозу безопасность своих посетителей.
Защита от трекинга
Браузеры уже сейчас умеют блокировать сторонние куки
XSS
Да ну. Вы же и пишете в статье, что реальный XSS, через инъекцию в страницу, так не блокируется. XSS предотвращается только экранированием / фильтрацией данных, вставляемых в страницу. Никакие токены тут не помогут.
CSRF
Допустим. Хотя, если бы браузеры блокировали куки в запросах со сторонних доменов, новый протокол бы и не понадобился. Но обратная совместимость важнее. Опять же, можно было изобрести и спец. флаг к кукиз для этого — гораздо проще в реализации и полностью обратно совместимо.
В остатке имеем: новый протокол решает проблему CSRF. В целом, неплохо — но впечатляет уже меньше.
если бы браузеры блокировали куки в запросах со сторонних доменов
Посыпаю голову пеплом. Все уже придумали до нас, в 14м веке.
https://www.owasp.org/index.php/SameSite
Если сервер назначает нам идентификатор, чтобы отслеживать наши запросы среди потока других пользователей — это слежка. Налипает на европейский GDPR.
Ведь по-сути, сервер не спрашивая, помечает вас. О чем уже уведомляет пост-фактум. Или не уведомляет — но тогда это нарушение.
Если клиент сам себя идентифицирует, то автоматом выполняется требование GDPR. Вы сами позволяете серверу отслеживать себя. Мало того, ни кто не мешает вам (браузеру) вообще менять ключ/токен при каждом запросе на сервер, чтобы блокировать слежку. (Но на практике пользователь так делать не будет. Ибо зачем? Трекинг нужен и для технических целей.)
Т.е. сейчас вас просто уведомляют: «Чувак, мы за тобой следим. Расслабься». Единственное, что вы можете сделать — согласиться с этим или покинуть сайт. А если очень надо?
Хотя в статье этого не написано, но ни кто не мешает браузеру менять ключ/токен при каждом запросе или после серии запросов (типа автосброс сессии после таймаута; режим для параноиков).
Т.е. протокол помогает серверу выполнить требования закона и решить свою задачу «трекинга». Это к вопросу: какая выгода у владельцев сайта?
Но тут лучше подключиться к обсуждению юристам. Может быть, я неверно трактую закон.
Вы неверно трактуете проблему :)
Никто не мешает браузерам отключить куки вообще. Или отключить для конкретных сайтов. Генерация идентификатора на стороне клиента для этого не нужна.
А с точки зрения закона (GDPR) — почти все делают неправильно. Сайт не имеет права просто сказать "чувак, за тобой следят — смирись или вали". Сайт обязан предоставить ссылку на детальное описание всех кук (или любых других идентификаторов — неверно тут цепляться только за термин "куки)", используемых для трекинга. И предоставить возможность согласиться или отказаться от них (и возможность поменять свое решение позже).
Ну и да, уведомлять о "технических" куках (напр, айди сессии), требуемых для предоставления услуги — не обязательно.
Для себя я вывел следующие ответы:
1.Так исторически сложилось (если не сервер — то кто? Во времена зарождения Интернета большую часть работы выполнял сервер. Клиент даже javascript не имел. О безопасности никто ещё не думал).
2. Клиенты могут «пересечься» идентификаторами.
3. Если клиент назначит себе сам идентификатор и будет использовать его на всех сайтах — это идеальная схема, чтобы за ним следить.
Что будет, если эту схему поменять? И можно ли её поменять?
1. Почему бы и нет. Тогда мы получаем большую свободу и право менять свой идентификатор как нам вздумается.
2. Попробуем использовать сильную криптографию, и большие идентификаторы. 256 бит мало? Ок. будем 512. Здесь необходимо экспертам по криптографии оценить вероятность коллизий SHA.
3. Сделаем математическую зависимость идентификатора клиента от домена сайта.
О, у меня раньше в черновике было такое: намеренная генерация браузером ослабленных 16-битных идентификаторов, хитрым нелинейным преобразованием от ключа браузера, представленных как 256-битные. Для гарантированной анонимизации посетителя. Идентификаторы, которые намеренно могут вызвать коллизии на стороне сервера. Чтобы у баннерных сетей даже желание не возникало использовать ваши токены для слежки. Но, просчитав, варианты, отказался от этого.
Кстати, с точки зрения сервера неважно, что у вас там за криптография и есть ли она вообще. Вы ему передается свой идентификатор — и совершенно неважно, как он получен.
Криптография нужна для вашего менеджера токенов, чтобы обеспечить детерминированную генерацию на разных устройствах. На протокол сервер-клиент это не влияет.
(Это все в ту же копилку о смешении независимых решений в одной статье, извините, что повторяюсь)
И я по правде тоже не понял, для какой из декларированных задач куков не хватило…
Если исходить из тезиса, что главное зло — в логинах с паролями — ну, тогда просто аутентифицировать / идентифицировать посетителя теми средствами, которые нравятся.
Ну а чем куки плохи для сохранения информации о сеансе — непонятно...
Зачем нужен SESSIONID, когда ту же задачу решает CSI-Token?
Затем, что у одного и того же пользователя может одновременно быть больше одной сессии.
Как, кстати, предлагается решать такую задачу?
Пример номер 1: есть веб-приложения (ну, например, учетные системы), которые привязывают к сессии всякое присходящее — текущие выбранные объекты, измененное состояние. Соответственно, иногда пользователь хочет вести две активности одновременно, и тогда он может открыть два (разных) браузера (или браузер + private mode) и иметь две сессии.
Пример номер 2: если сайт хочет отслеживать деятельность пользователя для последующего анализа, ему может быть важна именно последовательность действий в рамках одного сценария. И если я вперемешку перехожу по ссылкам на двух устройствах, это могут быть именно что разные сценарии, и сайт может хотеть отслеживать их отдельно.
Два браузера, при условии наличия прокси-сервера у пользователя, отличаются по портам подключения, соответственно им легко сопоставить два ключа. Ну а если пользователь доверяет авторам браузера, то тогда авторы браузера и разруливают эту (очень редкую на самом деле) проблему. Хотя можно просто два браузера от разных производителей открыть. Но тогда оба должны поддерживать протокол (и обоим нужно доверять).
Два устройства — два ключа. Не понимаю, как здесь можно не видеть решение
… и как между ними при этом установить соответствие? Пользователь-то один.
Вообще, любая проблема протокола решается просто — пользователь делает выбор. Либо он раб, либо он свободен. И всё. Тогда вариант «не раб» легко обойдёт все проблемы. Хотя да, ради свободы нужно будет чуть-чуть (реально на копейки) напрячься. Ну так рабы же не мы. Или как вы на это смотрите?
чем куки плохи для сохранения информации
Сама реализация кук и огромные исторические пробелы в их безопасности…
Вам точно удобно хранить данные пользователя (ну кроме как ID сеанса) в куках? Интерфейс работы с печеньками очень древний и ущербный. Разработчики предпочитают использовать для этих целей localStorage/sessionStorage и локальную базу.
Сама реализация кук
А есть конкретный пример?
Проблема HTTP — это проблема HTTP. Незашифрованный канал раскрывает все данные, а не только сессионную куку. Не знаю, зачем про это говорить в 2019.
Вам точно удобно хранить данные пользователя (ну кроме как ID сеанса) в куках
А причем тут хранение данных пользователя вообще? В вашем автоматически сгенерированном токене тоже нет данных пользователя же. Данные пользователя храним в базе на сервере (а не в какой-то там локальной базе)
Сама реализация кук и огромные исторические пробелы в их безопасности…
И я не понял: а какие проблемы безопасности есть у куков? Куки — это просто очень низкоуровневый механизм сохранения состояния в цепочке взаимодействий браузера и сервера. Я по правде не вижу там никакой безопасности.
Это поверх куков можно уже строить разные более сложные технологии сохранения состояния и доступа к нему, и вот у них уже будут разные вопросы безопасности. И уязвимости тоже могут быть и могут не быть...
Вам точно удобно хранить данные пользователя (ну кроме как ID сеанса) в куках?
Так а вроде никто и не заставляет… Можно хранить, и можно не хранить :) Куки — очень низкоуровневые и согласны на всё :) Что, где и как хранить — это ж разработчик этажом выше решает...
использовать для этих целей localStorage/sessionStorage и локальную базу
На мой взгляд, localStorage и sessionStorage решают хоть и близкие, но другие задачи. Они все работают на стороне клиента. Они не реализуют никакого взаимодействия сами по себе. Хотя гибкости и добавляют конечно...
Если подойти конструктивно: букв в тексте, вынесенном на обсуждение, получилось действительно много :) И мне лично, наверно, всё стало бы понятнее, если бы у текста появилась более развитая преамбула с аргументированной критикой того, что сейчас есть. С чуть более подробной классификацией рассматриваемых сценариев и их недостатков...
Какой резон упаковывать все это в один стандарт?
Но стандарт и не упаковывает вопрос хранения и синхронизации файлов. И хотя подобное описано в главе 3 «Рекомендации по безопасности», там же под спойлер я вынес оговорку, что эта глава не является частью протокола и носит рекомендательный характер. Про синхронизацию ключей я пишу в разделе «Мобильность учетных записей». Там же под спойлер я вынес альтернативы. Описал плюсы и минусы. Оценил риски. Эту тему хранения ключей ещё развивать и развивать. Но это не должно быть частью стандарта. Максимум — рекомендациями или отдельным под-стандартом. Тут я согласен с Вами.
Более того, учитывая ценное замечание user_man, протокол можно и нужно разбивать на слои, каждый со своим четким уровнем ответственности. Один отвечает за хранение ключевой информации, второй за выполнение криптографических функций (расчеты токенов, ключей, генерация соли), третий — за формирование параметров исполнения запроса (Recipient/Sender/Context), четвертый — за интерпретацию токенов (серверный уровень). Но это предварительные идеи по улучшению предложенной схемы. Пока не цепляйтесь к этому абзацу.
Или я пропустил какие-то ключевые требования к новому протоколу, которые не удовлетворяются куками?
1. Сессионные куки имеют короткий сроки жизни.
2. Постоянные куки могут иметь большой срок хранения. Но также могут быть случайно удалены при чистке кэша браузера. Ситуация типична, когда необходимо решить проблему с одним из сайтов, саппорт которого рекомендует «почистить куки и кэш», пользователь решает — да нафик всё почищу! И лишается всех кэшированных доступов.
3. Куки необходимо передавать с флагом HttpOnly, чтобы не были доступны скриптам. Есть вероятность, что разработчик забудет включить этот флаг (хотя сейчас это решают фреймворки).
Синхронизируем директорию с куками через дропбокс. Или копируем вручную. В любом случае, способ синхронизации файлов — это что-то внешнее для протокола идентификации пользователей.
4. Куки лежат только в файле. И доступны для НСД. Но опять же, стараюсь не лукавить, место хранения ключей доменов не специфицируется протоколом. Только рекомендации. Ключи доменов могут находиться на отчуждаемых носителях. Ключи домена от вашего пароля — только у вас в голове (по объективным причинам). Мастер-ключ, да — на диске.
«Ключи домена от вашего пароля» — этого не было в статье. Но, как вариант, возможен возврат к этой схеме.
Вообще, очень подробно все недостатки куки кратко рассмотрены в хорошей статье ru.wikipedia.org/wiki/Cookie. Но, я почему-то уверен, что Вы хорошо знакомы с её содержанием.
Срок жизни куки
можно хоть вечными сделать
Случайно удалены
могут быть и все токены из вашего хранилища. Предотвращение этого — это вопрос пользовательского интерфейса браузера (или менеджера токенов), и вопрос способа их хранения. Протокол обмена идентификаторами между севером и клиентом этого вопроса не касается.
Куки необходимо передавать с флагом HttpOnly
Наконец по существу. Но честно говоря, последний раз вживую я видел сессионную куку без HttpOnly лет эдак 10 назад. Secure — из той же области.
все недостатки куки кратко рассмотрены в хорошей статье
Все недостатки куки там можно разделить на 2 категории: 1) не относящиеся к сессионным кукам (иначе говоря — используем куки как хранилище данных) и 2) равным образом применимым к вашим токенам (напр., "неточная идентификация").
Наконец по существу.
А то, что куки лежат в файле и доступны вирусам, ну право, вас не смущает? И место это известно и нет возможности его поменять.
Меня тут выше «размотали», за то что мастер-ключ я предложил хранить на диске. При том, что я предлагал мастер-ключ использовать только на сайтах с «пониженной социальной ответственностью». А вы тут такое предлагаете!
что куки лежат в файле… вас не смущает
Нет, не смущает. Способ хранения кук никак не связан с протоколом общения между клиентом и сервером. И, собственно, он не регламентируется никаким стандартом, насколько мне известно. Хоть в блокчейне храните.
Дело в том, что вы в одной статье объединили несколько независимых решений, направленных на решение разных проблем.
Все мои комменты тут и выше касаются только протокола сервер-клиент.
недостатки куки… равным образом применимым к вашим токенам
Если вы заметили какой-то существенный недостаток токенов, который я не заметил, — поделитесь. Буду благодарен.
Про многосеансовость мне уже писали. Про смену домена сайтом — тоже. Я принял к сведению. Уже обдумываю варианты.
Я попытался не только описать эти правила, но объяснить зачем они такие, да на конкретных примерах, да с картинками. Это перегрузило и так не простую статью.Можно было спрятать в спойлеры.
Container Storage Interface (CSI) is an initiative to unify the storage interface of Container Orchestrator Systems (COs) like Kubernetes, Mesos, Docker swarm, cloud foundry, etc.
… А что не так с паролями?...В настоящее время пароль уже не является средством, достаточным для надёжной защиты, каким бы сложным он ни был!
Такой вывод основывается на огромных объёмах данных корпорации Microsoft, при ежедневном использовании облачных сервисов которой фиксируется порядка 300 миллионов попыток несанкционированного входа в аккаунты.
И лишь многофакторная аутентификация делает почти все эти попытки бесполезными, потому что она защищает от 99,9% всех попыток взлома.
Поэтому пользователь, защищающий свои учётные записи с помощью одного лишь пароля, может с тем же успехом считать, что не защищает их вовсе!
Источник
Еще несколько вопросов.
Что делать сайтам, живущим на одном домене, но по разным путям? (
https://some.com/path1,https://some.com/path2). Помимо разработки, это еще бывает, скажем, в AWS Api Gateway при развертывании custom domains.
Что делать веб-сервисам и веб-сайтам, которые доступны на более чем одном адресе одновременно (или адрес которых может меняться)? (самый простой пример:
https://some.comиhttps://api.some.com)
Что делать при делегировании доступа, когда один сервис обращается к другому на основании credentials пользователя, полученных первым сервисом?
Ну и наконец, что делать разработчикам клиентских приложений (не браузеров), которым нужно работать с веб-сервисами или веб-сайтами, закрытыми такой аутентификацией? В частности, как получить доступ от имени конкретного (живого) пользователя, при этом не получая доступ ни к его мастер-ключу, ни, в идеале, даже к его ключу от сайта? Это не говоря о том, что им придется самим этот протокол реализовать.
Благодарю за это.
1. проблемы при смене сайтом доменного имени
2. большая запутанность, смешение зон ответственности
3. не описаны понятные правила участников взаимодействия
Буду делать рефакторинг с учетом высказанных замечаний. Декомпозиция — однозначно.
Первая проблема она и для куков в общем-то имеет место быть… Не вижу в этой проблеме ничего уникального. Касательно токена… Ну… э… Не знаю.
даже более того — насколько я помню (я не очень хороший вэб-разраб), что при определенных условиях, если у нас есть приложения на поддоменах a.b.TLD и c.d.TLD, то они могут видеть свои куки и общие куки для домена b.TLD.
И там еще целая эпопея была, чтобы отличать двухкомпонентные TLD вроде co.uk от субдоменов.
Первая проблема она и для куков в общем-то имеет место быть…
Вообще-то, у кук есть Path.
Пусть был habrahabr.ru. Стал habr.com.
Создаем новый ключ для нового домена habr.com-key. Способы любые: копия, экспорт, random, от мастера — на выбор пользователя. Сообщаем браузеру, что сайт поменял домен.
Браузер делает следующее:
A1. заходит на habr.com, но формирует токен по правилу от имени habrahabr.ru:
T_1 = HMAC_{habrahabr.ru-key}( habrahabr.ru | habrahabr.ru | habrahabr.ru )сайт узнает и авторизует пользователя, т.к. такой токен есть в его базе
A2. генерирует новый «правильный» токен
T_2 = HMAC_{habr.com-key} ( habr.com | habr.com | habr.com )
A3. делает легальную перерегистрацию токенов (предусмотренную протоколом):
CSI-Token: T_1; Changed-To: T_2
A4. если сайт принял новый токен (а оснований для отказа у него нет), то он шлет CSI-Token-Action: success, как и предусматривает протокол.
А5. В дальнейшем, используем токен T_2, как и предписывает протокол
Под словом «заходит» можно понимать отправку запросов методом GET/HEAD на идексную страницу домена. Как пример. Вводить «специальные» страницы для таких процедур крайне не хочется.
что делать разработчикам клиентских приложений (не браузеров), которым нужно работать с веб-сервисами или веб-сайтами, закрытыми такой аутентификацией
На сайте делается функционал: предоставить доступ приложению от имени пользователя. Предлагается выбрать набор предоставляемых приложению прав. Для приложения генерируется API-ключ. На мой взгляд, так будет более правильно.
При таком подходе:
1. получаем контроль над доступами приложения (это может быть чья-то сторонняя разработка; не разработчиков сайта)
2. не компрометируем ключи/токены пользователя
На сайте делается функционал: предоставить доступ приложению от имени пользователя.
… а сайт открывать во встроенном браузере?
Для приложения генерируется API-ключ.
Ну то есть решения нет, делайте все сами.
Нет, я понимаю, что я могу OAuth 2/OIDC и поверх этого прикрутить, ничто не запрещает, но тогда мне все равно придется поддерживать зоопарк.
Что делать при делегировании доступа, когда один сервис обращается к другому на основании credentials пользователя, полученных первым сервисом?
Если сервис будет сам обращаться на основании credentials пользователя (без участия последнего; т.е. пользователь покинул сайт сервиса, а тот работает) — поступаем как и с приложением: генерируем для него API-ключ доступа. За генерацию отвечает «другой» сервис. А за распространение API ключа — пользователь, например. Так и безопаснее. И ключ не палим. И права можно выставить. API-ключ передать можно разными способами.
Если сервис, принадлежащий домену S1, будет обращаться к сервису S2 в результате действий пользователя на S1 — применяем технику ССО.
Что делать сайтам, живущим на одном домене, но по разным путям?
Здесь получается, что даже если пользователь и работает с приложением A1 под учеткой U1, а в приложении A2 под U2, всё-равно, каждый из этих приложений может легко получать доступы от соседнего профиля. Ну, хотя бы, в силу того, что этим «соседним» приложениям доступны все куки пользователя со своего домена.
По-сути, приложения работают с одним и тем же пользователем, но с разными профилями. На мой взгляд, здесь неправильно поставлен акцент.
Пользователь работает в приложениях не под разными учетными записями, а с разными ролями. А такую задачу можно решить, предлагая пользователю выбрать роль, по которой он будет работать с приложением. Но после авторизации.
Подойдет такое решение? Или я не Вас правильно понял?
Что делать веб-сервисам и веб-сайтам, которые доступны на более чем одном адресе одновременноЕсли я правильно понял, то возможно здесь можно применить технику меж-доменной и кросс-доменной идентификации пользователя.
Идентификация клиентов на сайтах без паролей и cookie: заявка на стандарт