Доклад "Строим единую платформу аутентификации на основе Keycloak" с Saint HighLoad++ 2025 от Виктора Попова
Пост, который хотел написать еще летом, но ведь лучше поздно, чем никогда...
В одном из предыдущих постов про книгу “Cloud Native Data Security with OAuth" я написал, что глава 11 Managing a Cloud Native Authorization Server в ней получилась не самой полезной. Так вот, для улучшения эффекта можно посмотреть доклад с летнего Highload от @ivanovivanivanovich1.
В докладе это явно не проговаривается, но речь будет идти об аутентификации именно внутренних пользователей.
Говорит автор о том, что понимает под платформой и какие ключевые особенности ей характерны:
1️⃣ One size fits most - платформа подходит под большинство ваших задач
2️⃣ Golden path - платформа дает "дорогу из золотого кирпича", по которой должно быть легко и удобно идти
3️⃣ Compliance - пользуясь платформой, вы удовлетворяете требованиям: техническим, информационной безопасности и др.
Рассматриваются следующие варианты реализации платформы аутентификации:
🔵 Пишем свое решение
🔵 SaaS (Auth0, Okta, etc)
🔵 "Экзотический" on-prem: Ory Hydra, ZITADEL, Casdoor
🔵 Keycloak
К какому выбору дальше приходит автор, думаю, пояснять не надо :)
Кстати, Виктор отмечает, что уже полтора года ищет, кто может на митапе рассказать про свой опыт использования Ory Hydra, отмечая малую популярность решения. Я тут частично соглашусь: хоть и есть несколько компаний в РФ, кто использует у себя стек от Ory, ни выступить, ни написать про это почему-то никто не хочет. А жаль.
Далее автор делится своими принципами в использовании Keycloak:
1️⃣ Keycloak использовать только для аутентификации
Кстати, ругает здесь подходы, когда возможность "входа" в то или иное приложение задается на стороне IdP, говоря, что это плохой UX. Интересно, что я сам долгое время был сторонником схожей школы мысли. Однако не так давно переубедил себя: отдельные приложения могут не поддерживать или не хотеть поддерживать гибкие политики аутентификации, и настраивать возможность и правила для входа в приложения можно и в одном месте - на стороне IdP. Так что здесь все не так однозначно.
2️⃣ Пользователи хранятся в AD-каталоге, а не в Keycloak. AD - источник правды
3️⃣ Не используют регистрацию пользователей в Keycloak
4️⃣ Не используют SAML
Здесь также говорится о том, что SAML - "небезопасный протокол", с чем не могу согласиться, это не так.
5️⃣ Конфигурация управляется 100% as a code
Рассказывает о том, как для себя подошли к решению задачи high availability (HA): размещают поды с KK в 3 AZ, при этом для базы используют растянутый кластер Patroni + PostgreSQL, где мастер находится только в одной из AZ. Но отмечает применимость такого подхода только при близкорасположенных ДЦ, чтобы не было больших задержек при репликации. Ну и логично, что воспринимается такая инсталляция как локальная, а не гео-распределенная. То есть фокус, полагаю, на отказоустойчивости внутри одного региона.
Деплоят в K8s, для реализации IaC используют Pulumi, чего докладчик и всем советует.
Еще понравилась мысль про стандартизацию использования: описание стандартных архитектур для потребителей, включая ограничения платформы, чтобы было понятно, как надежно и безопасно вас использовать.
#video #iam_general
Пост, который хотел написать еще летом, но ведь лучше поздно, чем никогда...
В одном из предыдущих постов про книгу “Cloud Native Data Security with OAuth" я написал, что глава 11 Managing a Cloud Native Authorization Server в ней получилась не самой полезной. Так вот, для улучшения эффекта можно посмотреть доклад с летнего Highload от @ivanovivanivanovich1.
В докладе это явно не проговаривается, но речь будет идти об аутентификации именно внутренних пользователей.
Говорит автор о том, что понимает под платформой и какие ключевые особенности ей характерны:
Рассматриваются следующие варианты реализации платформы аутентификации:
К какому выбору дальше приходит автор, думаю, пояснять не надо :)
Кстати, Виктор отмечает, что уже полтора года ищет, кто может на митапе рассказать про свой опыт использования Ory Hydra, отмечая малую популярность решения. Я тут частично соглашусь: хоть и есть несколько компаний в РФ, кто использует у себя стек от Ory, ни выступить, ни написать про это почему-то никто не хочет. А жаль.
Далее автор делится своими принципами в использовании Keycloak:
Кстати, ругает здесь подходы, когда возможность "входа" в то или иное приложение задается на стороне IdP, говоря, что это плохой UX. Интересно, что я сам долгое время был сторонником схожей школы мысли. Однако не так давно переубедил себя: отдельные приложения могут не поддерживать или не хотеть поддерживать гибкие политики аутентификации, и настраивать возможность и правила для входа в приложения можно и в одном месте - на стороне IdP. Так что здесь все не так однозначно.
Здесь также говорится о том, что SAML - "небезопасный протокол", с чем не могу согласиться, это не так.
Рассказывает о том, как для себя подошли к решению задачи high availability (HA): размещают поды с KK в 3 AZ, при этом для базы используют растянутый кластер Patroni + PostgreSQL, где мастер находится только в одной из AZ. Но отмечает применимость такого подхода только при близкорасположенных ДЦ, чтобы не было больших задержек при репликации. Ну и логично, что воспринимается такая инсталляция как локальная, а не гео-распределенная. То есть фокус, полагаю, на отказоустойчивости внутри одного региона.
Деплоят в K8s, для реализации IaC используют Pulumi, чего докладчик и всем советует.
Еще понравилась мысль про стандартизацию использования: описание стандартных архитектур для потребителей, включая ограничения платформы, чтобы было понятно, как надежно и безопасно вас использовать.
#video #iam_general
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Строим единую платформу аутентификации на основе Keycloak / Виктор Попов
Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем Saint HighLoad++ 2026
Подробнее: https://clck.ru/3QZHTb
Июнь, 2026.
Санкт-Петербург, DESIGN DISTRICT DAA in SPB
--------
Профессиональная конференция разработчиков высоконагруженных…
Подробнее: https://clck.ru/3QZHTb
Июнь, 2026.
Санкт-Петербург, DESIGN DISTRICT DAA in SPB
--------
Профессиональная конференция разработчиков высоконагруженных…
👍6❤1🤔1
Про термины authorization request/response и token request/response
Вы, вероятно, уже встречали упоминание подобных терминов в контексте OAuth/OIDC, по крайней мере автор данного канала активно их использует. Здесь как раз разберемся, зачем они нужны и что подразумевают.
Начнем с того, что RFC 6749 вводит понятия Authorization Endpoint и Token Endpoint.
Обычно выглядит как что-то вроде
Соответственно, запросы к этим эндпоинтам и называют Authorization Request и Token Request.
Authorization Request - это HTTP-запрос к Authorization Endpoint, являющийся первым шагом в основных grant flows. То есть это запрос, с помощью которого resource owner предоставляет авторизацию (разрешение) OAuth client для доступа к ресурсам от его лица.
Token Request - это HTTP-запрос к Token Endpoint, который служит для получения токенов, таких как access token, refresh token, ID token.
А ответы на данные запросы в соответствие так и называются: Authorization Response и Token Response.
И все было хорошо, поканарод огня не развязал войну ребята из OpenID Foundation не написали спецификацию OIDC. Где ввели ещё и понятие Authentication Request... Вот формальное определение оттуда:
Стало понятнее, да ведь? То есть предлагается выделить Authorization Request обладающий рядом параметров, в отдельный термин. Увы, это только внесло большую путаницу. Вы можете сами поискать по тексту спецификации эти два понятия и попробовать понять, почему в каждом месте использовано именно такое.
Поэтому я лично вообще стараюсь отдельно этот термин не использовать и ограничиваюсь везде понятием Authorization request.
С понятийной частью, вроде, разобрались, осталось выяснить, зачем вообще уделять такое внимание этим определениям. Может, это буквоедство и лишнее усложнение?
На самом деле, смысл в их использовании есть. Когда мы описываем какое-либо поведение, нам часто так или иначе нужно упоминать эти запросы и ответы на них. Внутри команд, работающих с аутентификацией, часто можно встретить подход, где оперируют названиями конкретных эндпоинтов. Правда это не всегда может быть удобно в устной речи.
Куда более интересно становится, когда мы хотим описать некоторую общую логику, не привязываясь при этом к использованию конкретного IAM-решения. И желательно, чтобы нас поняли люди, работающие хоть с Keycloak, хоть с ZITADEL, хоть с самописными реализациями. И у всех этих конкретных решений названия данных эндпоинтов могут отличаться.
Таким образом, используя подобные универсальные термины, мы можем говорить без привязки к конкретной технологии, но при этом оставляя возможность быть понятыми верно и однозначно.
Так что пост написан с целью пропаганды использования таких терминов, что, надеюсь, поможет всем нам лучше понимать друг друга и проще вести дискуссии на профессиональные темы⛔️
#oauth
Вы, вероятно, уже встречали упоминание подобных терминов в контексте OAuth/OIDC, по крайней мере автор данного канала активно их использует. Здесь как раз разберемся, зачем они нужны и что подразумевают.
Начнем с того, что RFC 6749 вводит понятия Authorization Endpoint и Token Endpoint.
Authorization endpoint - used by the client to obtain authorization from the resource owner via user-agent redirection.
Обычно выглядит как что-то вроде
.../auth или .../authorize.Token endpoint - used by the client to exchange an authorization grant for an access token, typically with client authentication.На самом деле, возвращаться может не только access token, но об этом далее. Представляет собой нечто вроде
.../token.Соответственно, запросы к этим эндпоинтам и называют Authorization Request и Token Request.
Authorization Request - это HTTP-запрос к Authorization Endpoint, являющийся первым шагом в основных grant flows. То есть это запрос, с помощью которого resource owner предоставляет авторизацию (разрешение) OAuth client для доступа к ресурсам от его лица.
Token Request - это HTTP-запрос к Token Endpoint, который служит для получения токенов, таких как access token, refresh token, ID token.
А ответы на данные запросы в соответствие так и называются: Authorization Response и Token Response.
И все было хорошо, пока
Authentication Request - OAuth 2.0 Authorization Request using extension parameters and scopes defined by OpenID Connect to request that the End-User be authenticated by the Authorization Server, which is an OpenID Connect Provider, to the Client, which is an OpenID Connect Relying Party.
Стало понятнее, да ведь? То есть предлагается выделить Authorization Request обладающий рядом параметров, в отдельный термин. Увы, это только внесло большую путаницу. Вы можете сами поискать по тексту спецификации эти два понятия и попробовать понять, почему в каждом месте использовано именно такое.
Поэтому я лично вообще стараюсь отдельно этот термин не использовать и ограничиваюсь везде понятием Authorization request.
С понятийной частью, вроде, разобрались, осталось выяснить, зачем вообще уделять такое внимание этим определениям. Может, это буквоедство и лишнее усложнение?
На самом деле, смысл в их использовании есть. Когда мы описываем какое-либо поведение, нам часто так или иначе нужно упоминать эти запросы и ответы на них. Внутри команд, работающих с аутентификацией, часто можно встретить подход, где оперируют названиями конкретных эндпоинтов. Правда это не всегда может быть удобно в устной речи.
Куда более интересно становится, когда мы хотим описать некоторую общую логику, не привязываясь при этом к использованию конкретного IAM-решения. И желательно, чтобы нас поняли люди, работающие хоть с Keycloak, хоть с ZITADEL, хоть с самописными реализациями. И у всех этих конкретных решений названия данных эндпоинтов могут отличаться.
Таким образом, используя подобные универсальные термины, мы можем говорить без привязки к конкретной технологии, но при этом оставляя возможность быть понятыми верно и однозначно.
Так что пост написан с целью пропаганды использования таких терминов, что, надеюсь, поможет всем нам лучше понимать друг друга и проще вести дискуссии на профессиональные темы
#oauth
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔3🔥2❤1👏1😁1
Гора родила мышь, а я наконец родил статью на основе материала, про который рассказывал весной на PHDays 2025 и CodeFest 15.
https://habr.com/ru/articles/872918/
#api #oauth #my_publication
https://habr.com/ru/articles/872918/
#api #oauth #my_publication
Хабр
Токены доступа и API Gateway: как обеспечить безопасность запросов
Распределенные системы (aka микросервисы) набрали популярность и применяются все шире в современных реалиях. Сервисов становится больше, привычные задачи для них решаются сложнее, усложнились и...
👍20
SSO из мобильного приложения в web
Я однажды уже писал про подходы к реализации SSO в мобильных приложениях. Кстати, там была упомянута спецификация OpenID Connect Native SSO for Mobile Apps , и с тех пор Authlete опубликовали классное описание, как ее у себя реализовали, можно почитать.
В том посте я фокусировался на возможности аутентификации в самих мобильных приложения, в том числе с использованием сессии в браузере. Однако бывают и обратные примеры: когда пользователь уже аутентифицирован в мобильном приложении, и его нужно отправить на некоторый ресурс в браузере, причем "волшебным образом" обеспечив и там аутентифицированное состояние. И задача логично усложняется в ситуации, когда в этот момент у пользователя может не быть cookie с активной SSO-сессией. Касается это и случаев, когда в качестве экземпляров браузера используют WebView и его аналоги для iOS.
Вот про подходы к решению такой задачи сегодня и поговорим.
Недавно я заметил в документации Roox UIDM описание любопытной функциональности: бесшовный переход из мобильных приложений в Web, и стало интересно разобраться подробнее.
Подход основан на кастомном grant type
Однако подход пока смущает, мне не до конца понятно, почему он такой и как работает.
1. Почему выполняется обмен именно access token и именно на authorization code? Как можно превратить "делегированный доступ в рамках X для client A" в "авторизацию доступа в рамках Y для client B"?
2. Как быть с самим механизмом делегирования доступа? В рамках какой области действия (те же scopes) он делегируется при создании authorization code? Как быть, если пользователь не давал согласия (consent) веб-приложению? Здесь authorization server выдает authorization code как подтверждение того, что "пользователь разрешил веб-приложению доступ к своим данным в рамках Y", хотя пользователя вообще не спрашивали, ну и подозреваю, что совсем не обязательно scopes веб-приложения могут входить в scopes МП
3. Как и чем обеспечивается возможность конкретно для client A получить от authorization server authorization code конкретно для client B, что мешает ему получить authorization code для любого другого клиента? Здесь уверен, у ребят какая-то настройка предусмотрена, но вот не написали, какая(
Концепция для таких задач обычно одна: поменять A на B. Ключевой вопрос тогда стоит в том, чтобы понять, что есть A, что есть B и как правильно и безопасно должно работать "поменять". И хотя стандартизированный подход отсутствует, можно рассмотреть, какие еще имплементации существуют и как раз увидеть между ними схожести, вытекающие из общего принципа.
Так, например, в Curity некогда придумали подход Nonce Authenticator Pattern. Здесь предлагают получать специальное одноразовое значение - nonce - на основе ID token. Затем это значение передаётся веб-приложению, которое использует его как один из параметров authorization request.
Свой подход есть и у Auth0 (Okta), назвали его Native to Web SSO. Выглядит интереснее: используется обмен refresh token на специальный session transfer token. Он передаётся веб-приложению и служит для создания SSO-сессии в браузере, причем он является одноразовым, короткоживущим, и его можно привязать, например, к IP (в рекламе обещают device binding, но врут: только к IP и ASN). После создания SSO-сессии веб-приложение уже может выполнить стандартный authorization request и продолжить OAuth flow в обычном режиме.
У меня здесь пока нет готового ответа, как бы сделал я. Но считаю, что переносить нужно "identity для ограниченного SSO", поэтому создание SSO-сессии в браузере кажется логичным, и направление мысли скорее в сторону подхода Auth0/Okta.
#oauth #iam_general
Я однажды уже писал про подходы к реализации SSO в мобильных приложениях. Кстати, там была упомянута спецификация OpenID Connect Native SSO for Mobile Apps , и с тех пор Authlete опубликовали классное описание, как ее у себя реализовали, можно почитать.
В том посте я фокусировался на возможности аутентификации в самих мобильных приложения, в том числе с использованием сессии в браузере. Однако бывают и обратные примеры: когда пользователь уже аутентифицирован в мобильном приложении, и его нужно отправить на некоторый ресурс в браузере, причем "волшебным образом" обеспечив и там аутентифицированное состояние. И задача логично усложняется в ситуации, когда в этот момент у пользователя может не быть cookie с активной SSO-сессией. Касается это и случаев, когда в качестве экземпляров браузера используют WebView и его аналоги для iOS.
Вот про подходы к решению такой задачи сегодня и поговорим.
Недавно я заметил в документации Roox UIDM описание любопытной функциональности: бесшовный переход из мобильных приложений в Web, и стало интересно разобраться подробнее.
Подход основан на кастомном grant type
urn:roox:params:oauth:grant-type:m2m-authorization-code. В нем получаемый в мобильном приложении (МП) access token обменивается сразу на authorization code для веб-приложения. Далее МП передает полученный authorization code на адрес redirect URI веб-приложения, после чего веб-приложение штатным способом уже выполняет получение токенов.Однако подход пока смущает, мне не до конца понятно, почему он такой и как работает.
1. Почему выполняется обмен именно access token и именно на authorization code? Как можно превратить "делегированный доступ в рамках X для client A" в "авторизацию доступа в рамках Y для client B"?
2. Как быть с самим механизмом делегирования доступа? В рамках какой области действия (те же scopes) он делегируется при создании authorization code? Как быть, если пользователь не давал согласия (consent) веб-приложению? Здесь authorization server выдает authorization code как подтверждение того, что "пользователь разрешил веб-приложению доступ к своим данным в рамках Y", хотя пользователя вообще не спрашивали, ну и подозреваю, что совсем не обязательно scopes веб-приложения могут входить в scopes МП
3. Как и чем обеспечивается возможность конкретно для client A получить от authorization server authorization code конкретно для client B, что мешает ему получить authorization code для любого другого клиента? Здесь уверен, у ребят какая-то настройка предусмотрена, но вот не написали, какая(
Концепция для таких задач обычно одна: поменять A на B. Ключевой вопрос тогда стоит в том, чтобы понять, что есть A, что есть B и как правильно и безопасно должно работать "поменять". И хотя стандартизированный подход отсутствует, можно рассмотреть, какие еще имплементации существуют и как раз увидеть между ними схожести, вытекающие из общего принципа.
Так, например, в Curity некогда придумали подход Nonce Authenticator Pattern. Здесь предлагают получать специальное одноразовое значение - nonce - на основе ID token. Затем это значение передаётся веб-приложению, которое использует его как один из параметров authorization request.
Свой подход есть и у Auth0 (Okta), назвали его Native to Web SSO. Выглядит интереснее: используется обмен refresh token на специальный session transfer token. Он передаётся веб-приложению и служит для создания SSO-сессии в браузере, причем он является одноразовым, короткоживущим, и его можно привязать, например, к IP (в рекламе обещают device binding, но врут: только к IP и ASN). После создания SSO-сессии веб-приложение уже может выполнить стандартный authorization request и продолжить OAuth flow в обычном режиме.
У меня здесь пока нет готового ответа, как бы сделал я. Но считаю, что переносить нужно "identity для ограниченного SSO", поэтому создание SSO-сессии в браузере кажется логичным, и направление мысли скорее в сторону подхода Auth0/Okta.
#oauth #iam_general
👍8🤔3
Про form post response mode
В начале 2025 года я провел, а весной опубликовал результаты исследования в виде статьи “Атаки через новый OAuth flow, authorization code injection, и помогут ли HttpOnly, PKCE и BFF”, где также описывал и меры для защиты от рассматриваемых сценариев атак.
Самым интересным для меня оказался вывод, показывающий фундаментальную проблему: authorization code grant в OAuth закладывает разбиение процесса авторизации на отрезки, при этом позволяя выполнить отдельный участок процесса вообще вне сеанса пользователя, чем нивелируется наличие любых защитных механизмов браузера. Отсюда и идет сложность с выбором защитных мер.
В статье я пришел к выводу, что единственной полноценной мерой защиты является использование form post response mode, поскольку он не делает authorization response доступным с origin самого приложения, а передает его сразу серверной части в POST-запросе. Про него, а также другие response modes писал здесь.
Шло время, а я продолжал думать: почему form post response mode не является особо популярным. Не только он не получил широкого распространения, но и рекомендаций к его использованию вместо того же де-факто “стандартного ” query response mode мы нигде не находим. Стал размышлять в сторону сравнения query и form post response modes: а не стоит ли для большинства случаев по умолчанию считать form post более безопасным и подходящим и сразу использовать его, оставляя query для тех сценариев, где он действительно оправдан? Ну или хотя бы отмечать его применимость, чтобы он перестал быть “маргинальным”.
И вот в октябре решил посоветоваться по этому вопросу в переписке рабочей группы OAuth. Коли form post хорош, чего же нигде не пишем про такие возможности? Упустили или есть какие-то еще причины, которых не увидел? Собственно, в течение пары недель была дискуссия, в том числе затрагивающая и потенциальные недостатки.
При этом в начале ноября на очередном митинге рабочей группы товарищ Jonas Primbs поднял вопрос актуальности Browser Swapping attacks и мер защиты от них (в общем-то тех же самых). Как я отмечал в статье, это название такого же сценария атаки, просто зачем-то суженное именно до браузера атакующего (который вообще можно не использовать). Также завели PR в OAuth 2.1
После этого параллельно стартовала соседняя дискуссия - про Browser Swapping. По контексту они часто перекликались. Интересным там оказалось недавнее письмо от товарища из MS Entra, написанное уже под конец года, после основных обсуждений.
Он подсветил интересную свежую фишинговую атаку как раз на MS Entra: ConsentFix. Авторы отмечают, что данную атаку можно рассмотреть как продолжение известной ClickFix, про которую многие писали в этом году, однако здесь она происходит полностью в браузере.
В двух словах суть следующая: как и в ClickFix-атаке, пользователь видит фейковое окошко вида “подтвердите, что вы не робот”, которое может появиться и на легитимных сайтах ввиду наличия уязвимостей на них самих. Далее после нехитрых манипуляций выполняется переадресация браузера пользователя на URL authorization request в MS Entra, где в качестве значения client_id используется идентификатор Azure CLI. При наличии SSO-сессии пользователя успешно редиректит с authorization code в URL на localhost, однако на нем у него, естественно, ничего не поднято. И поэтому его просят “скопировать значение из адресной строки, чтобы подтвердить доступ”.
А суть его письма в том, что, кроме обсуждаемых сценариев для веб-приложений, есть еще и релевантные кейсы для нативных клиентов, в которых form post тоже мог бы повысить безопасность.
Еще одним итогом можно считать идею от Dick Hardt по добавлению в браузеры нового механизма для поддержки особых заголовков, которые можно использовать для передачи authorization response без раскрытия его клиентской части, которая родилась после дискуссий выше. Идея пока сырая, но все же.
Что имеем в остатке? Внимание к проблеме начало появляться, она начинает осознаваться, а это уже хорошо.
#oauth
В начале 2025 года я провел, а весной опубликовал результаты исследования в виде статьи “Атаки через новый OAuth flow, authorization code injection, и помогут ли HttpOnly, PKCE и BFF”, где также описывал и меры для защиты от рассматриваемых сценариев атак.
Самым интересным для меня оказался вывод, показывающий фундаментальную проблему: authorization code grant в OAuth закладывает разбиение процесса авторизации на отрезки, при этом позволяя выполнить отдельный участок процесса вообще вне сеанса пользователя, чем нивелируется наличие любых защитных механизмов браузера. Отсюда и идет сложность с выбором защитных мер.
В статье я пришел к выводу, что единственной полноценной мерой защиты является использование form post response mode, поскольку он не делает authorization response доступным с origin самого приложения, а передает его сразу серверной части в POST-запросе. Про него, а также другие response modes писал здесь.
Шло время, а я продолжал думать: почему form post response mode не является особо популярным. Не только он не получил широкого распространения, но и рекомендаций к его использованию вместо того же де-факто “стандартного ” query response mode мы нигде не находим. Стал размышлять в сторону сравнения query и form post response modes: а не стоит ли для большинства случаев по умолчанию считать form post более безопасным и подходящим и сразу использовать его, оставляя query для тех сценариев, где он действительно оправдан? Ну или хотя бы отмечать его применимость, чтобы он перестал быть “маргинальным”.
И вот в октябре решил посоветоваться по этому вопросу в переписке рабочей группы OAuth. Коли form post хорош, чего же нигде не пишем про такие возможности? Упустили или есть какие-то еще причины, которых не увидел? Собственно, в течение пары недель была дискуссия, в том числе затрагивающая и потенциальные недостатки.
При этом в начале ноября на очередном митинге рабочей группы товарищ Jonas Primbs поднял вопрос актуальности Browser Swapping attacks и мер защиты от них (в общем-то тех же самых). Как я отмечал в статье, это название такого же сценария атаки, просто зачем-то суженное именно до браузера атакующего (который вообще можно не использовать). Также завели PR в OAuth 2.1
После этого параллельно стартовала соседняя дискуссия - про Browser Swapping. По контексту они часто перекликались. Интересным там оказалось недавнее письмо от товарища из MS Entra, написанное уже под конец года, после основных обсуждений.
Он подсветил интересную свежую фишинговую атаку как раз на MS Entra: ConsentFix. Авторы отмечают, что данную атаку можно рассмотреть как продолжение известной ClickFix, про которую многие писали в этом году, однако здесь она происходит полностью в браузере.
В двух словах суть следующая: как и в ClickFix-атаке, пользователь видит фейковое окошко вида “подтвердите, что вы не робот”, которое может появиться и на легитимных сайтах ввиду наличия уязвимостей на них самих. Далее после нехитрых манипуляций выполняется переадресация браузера пользователя на URL authorization request в MS Entra, где в качестве значения client_id используется идентификатор Azure CLI. При наличии SSO-сессии пользователя успешно редиректит с authorization code в URL на localhost, однако на нем у него, естественно, ничего не поднято. И поэтому его просят “скопировать значение из адресной строки, чтобы подтвердить доступ”.
А суть его письма в том, что, кроме обсуждаемых сценариев для веб-приложений, есть еще и релевантные кейсы для нативных клиентов, в которых form post тоже мог бы повысить безопасность.
Еще одним итогом можно считать идею от Dick Hardt по добавлению в браузеры нового механизма для поддержки особых заголовков, которые можно использовать для передачи authorization response без раскрытия его клиентской части, которая родилась после дискуссий выше. Идея пока сырая, но все же.
Что имеем в остатке? Внимание к проблеме начало появляться, она начинает осознаваться, а это уже хорошо.
#oauth
🔥11🤔3
Статья JWTs in OAuth and OpenID Connect от Takahiko Kawasaki
Понравилась интересная статья от Takahiko Kawasaki, сооснователя Authlete.
Автор начинает с предисловия, где рассказывает, как поправил статью про JWT в Википедии, в которой ранее JWT определялся как стандарт для создания "JSON-based access tokens".
Собственно, от этого идёт мысль, что JWT часто ошибочно воспринимают как "технологию для токенов доступа" или технологию для аутентификации.
Я писал небольшой пост про виды JWT, кратко упоминая и их применение в OAuth/OIDC. Но автор приводит гораздо больше примеров, показывая разнообразие применения JWT.
Так упоминаются:
- ID token
- JAR
- CIBA request object
- JARM
- Client assertion
- Client attestation
- DPoP
- Userinfo response
- Introspection response
- JWT access token
- JWT-bearer authorization grant
- Token exchange
- Entity statement из OpenID Federation
- Software statement из DCR
- Selective disclosure for JWTs
- Key proof JWT из verifiable credentials
- Security event token (SET)
Прочитать интересно в том числе и чтобы освежить знания по разнообразию подходов и стандартов и вообще вспомнить, что они существуют :)
#jwt #article
Понравилась интересная статья от Takahiko Kawasaki, сооснователя Authlete.
Автор начинает с предисловия, где рассказывает, как поправил статью про JWT в Википедии, в которой ранее JWT определялся как стандарт для создания "JSON-based access tokens".
Собственно, от этого идёт мысль, что JWT часто ошибочно воспринимают как "технологию для токенов доступа" или технологию для аутентификации.
Я писал небольшой пост про виды JWT, кратко упоминая и их применение в OAuth/OIDC. Но автор приводит гораздо больше примеров, показывая разнообразие применения JWT.
Так упоминаются:
- ID token
- JAR
- CIBA request object
- JARM
- Client assertion
- Client attestation
- DPoP
- Userinfo response
- Introspection response
- JWT access token
- JWT-bearer authorization grant
- Token exchange
- Entity statement из OpenID Federation
- Software statement из DCR
- Selective disclosure for JWTs
- Key proof JWT из verifiable credentials
- Security event token (SET)
Прочитать интересно в том числе и чтобы освежить знания по разнообразию подходов и стандартов и вообще вспомнить, что они существуют :)
#jwt #article
Medium
JWTs in OAuth and OpenID Connect
~Various applications of JWT~
1👍6
Top 10 web hacking techniques of 2025 от PortSwigger (номинанты)
Ежегодный перечень статей от PortSwigger. Сначала составляют "lightly curated" список всех участников, а затем уже отбирают 10 лучших - обещают к 3 февраля. Год назад делал подборку заинтересовавших публикаций про околоаутентификационные темы, сделаю и сейчас. В этом году статей заявили меньше, кстати, список покороче.
🔵 Google Cloud Account Takeover via URL Parsing Confusion
Интересная работа, про нее уже писал в канале весной этого года.
🔵 Stopping Redirects
Исследование, фокусирующееся на различных случаях для прерывания редиректов, что в частности может быть полезно при атаках с кражей authorization code, чтобы предотвратить его использование легитимным приложением. Кроме уже известных из статьи Frans Rosén, на которые в том числе я опирался, есть еще любопытные:
- Увеличение длины URL (например, за счет query-параметров)
- Отправка больших значений заголовков, например, используя заголовок Referer или же т.н. "cookie bombing" - установку множественных больших cookies, причем комбинируя с атрибутом path. Кстати, такую технику мы уже наблюдали в статье из прошлой подборки
- Вызов срабатывания правил WAF путем передачи в параметрах (например, state) строки, на которую WAF будет ругаться и не пустит запрос далее
- Достижения лимита редиректов для site в браузере (да, и такой есть!)
🔵 Client Side Path Traversal (CSPT) Bug Bounty Reports and Techniques
Здесь у товарища много разных кейсов, нам интересен первый. Автор нашел XSS на поддомене
🔵 The Fragile Lock: Novel Bypasses For SAML Authentication
Все никак не перестанут мучить имплементации бедного SAML. Здесь автор эксплуатирует недостатки парсинга XML в библиотеках под Ruby и PHP, позволяющие скрафтить валидный (для SP) SAML Response без доступа к сертификату IdP. Вместо "переиспользования" с изменением украденного SAML Assertion (что может быть сложно), автор предлагает использовать "любой другой XML, подписанный IdP": SAML metadata или подписанный ответ с ошибкой.
🔵 Attacks via a New OAuth flow, Authorization Code Injection, and Whether HttpOnly, PKCE, and BFF Can Help
А это моя статья, хехе. Про нее тут неоднократно упоминал, здесь она же на английском. Так что минутка рекламы.
Еще отдельно отмечу понравившиеся мне статьи на другие темы:
- Hacking Gemini: A Multi-Layered Approach. Автор в конце отмечает:
- Make Self-XSS Great Again от Slonser. Как по мне, очень классный прием с credentialless iframe, позволяющий в том числе по-новому взглянуть на login CSRF. А использование fetchLater (про который отсюда и узнал) выглядит вообще магией. У него в канале, кстати, есть своя подборка, но уже по части client-side уязвимостей.
В прошлый раз для подборки все равно смотрел на полный список, а не только на топ-10, поэтому сейчас и решил написать пораньше, до подведения итогов.
Голосование за публикации, между прочим, еще идет (до 22 числа), так что в нем еще можно поучаствовать: https://portswigger.net/polls/top-10-web-hacking-techniques-2025
#security #article
Ежегодный перечень статей от PortSwigger. Сначала составляют "lightly curated" список всех участников, а затем уже отбирают 10 лучших - обещают к 3 февраля. Год назад делал подборку заинтересовавших публикаций про околоаутентификационные темы, сделаю и сейчас. В этом году статей заявили меньше, кстати, список покороче.
Интересная работа, про нее уже писал в канале весной этого года.
Исследование, фокусирующееся на различных случаях для прерывания редиректов, что в частности может быть полезно при атаках с кражей authorization code, чтобы предотвратить его использование легитимным приложением. Кроме уже известных из статьи Frans Rosén, на которые в том числе я опирался, есть еще любопытные:
- Увеличение длины URL (например, за счет query-параметров)
- Отправка больших значений заголовков, например, используя заголовок Referer или же т.н. "cookie bombing" - установку множественных больших cookies, причем комбинируя с атрибутом path. Кстати, такую технику мы уже наблюдали в статье из прошлой подборки
- Вызов срабатывания правил WAF путем передачи в параметрах (например, state) строки, на которую WAF будет ругаться и не пустит запрос далее
- Достижения лимита редиректов для site в браузере (да, и такой есть!)
Здесь у товарища много разных кейсов, нам интересен первый. Автор нашел XSS на поддомене
cashback.opera.com, а также выяснил очень любопытную деталь: в браузере Opera страницы на данном поддомене имели права использовать специальные API браузера (судя по перечню, предназначенные для расширений), недоступные в других местах. Это позволило ему выполнить кражу authorization code но не для same-origin случая, как писал я, а для cross-origin! Используя chrome.tabs API автор смог получить доступ к URL окна с другим origin.Все никак не перестанут мучить имплементации бедного SAML. Здесь автор эксплуатирует недостатки парсинга XML в библиотеках под Ruby и PHP, позволяющие скрафтить валидный (для SP) SAML Response без доступа к сертификату IdP. Вместо "переиспользования" с изменением украденного SAML Assertion (что может быть сложно), автор предлагает использовать "любой другой XML, подписанный IdP": SAML metadata или подписанный ответ с ошибкой.
А это моя статья, хехе. Про нее тут неоднократно упоминал, здесь она же на английском. Так что минутка рекламы.
Еще отдельно отмечу понравившиеся мне статьи на другие темы:
- Hacking Gemini: A Multi-Layered Approach. Автор в конце отмечает:
As AI architectures become more complex and integrated, new attack surfaces emerge. It’s reminiscent of the early XSS era -but now you don’t necessarily need JS-, because even something that might seem simple, like Markdown, can be an exfil vector.
- Make Self-XSS Great Again от Slonser. Как по мне, очень классный прием с credentialless iframe, позволяющий в том числе по-новому взглянуть на login CSRF. А использование fetchLater (про который отсюда и узнал) выглядит вообще магией. У него в канале, кстати, есть своя подборка, но уже по части client-side уязвимостей.
В прошлый раз для подборки все равно смотрел на полный список, а не только на топ-10, поэтому сейчас и решил написать пораньше, до подведения итогов.
Голосование за публикации, между прочим, еще идет (до 22 числа), так что в нем еще можно поучаствовать: https://portswigger.net/polls/top-10-web-hacking-techniques-2025
#security #article
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤4🔥1🤔1
API_sec public CLEAN.pdf
663.2 KB
Базовые правила правила работы с API в современном мире
Какой громкий заголовок, да ведь? Несколько лет назад я читал в одной компании внутренний доклад "Разрабатываем и тестируем безопасные API", в нем как раз сформулировал тезисно, в виде правил то, что сам интуитивно всегда применял. Мир наш, быть может, и стал более современным, однако свою актуальность правила не потеряли.
Пусть клиент - часть приложения, с которой непосредственно взаимодействуют пользователи и которая распространяется путем доставки определенного ее экземпляра конечным пользователям. Например:
- Браузер (фронтенд в нем)
- Мобильное приложение
- Десктоп-приложение
Тогда можно сказать следующее:
1️⃣ Нельзя доверять тому, что пришло с клиента. Все валидации или проверки должны выполняться на бэкэнде
2️⃣ Нельзя хранить секреты на клиенте. Если секреты хранятся на клиенте, то нельзя их считать секретами
3️⃣ Нельзя выполнять запросы с аутентификацией к внешним API с клиента (следует из п. 2)
4️⃣ Нельзя полагаться на криптографию на клиенте для сокрытия данных от самого пользователя. Шифрование на клиенте имеет смысл только для защиты данных пользователя от бэкенда (здесь изменил исходную формулировку)
5️⃣ Никогда не доверяйте клиентской части «фильтрацию» лишних данных
Как считаете, справедлив ли такой список? Можно ли его чем-то дополнить?
Кстати, откопал и презентацию с того доклада. Подчистил от корпоративной символики и публикую ее здесь.
В ней в том числе есть ссылка на потрясающий материал про CSRF, где рассказывают про Cross-Site Request Forgery в стилистике Гарри Поттера : Defense Against the Dark Arts: CSRF Attacks.
Если никогда не читали, настоятельно рекомендую, подача очень крутая. Даже если и несколько устарел, базовые проблемы не изменились. Есть и перевод на русский.
#api #security
Какой громкий заголовок, да ведь? Несколько лет назад я читал в одной компании внутренний доклад "Разрабатываем и тестируем безопасные API", в нем как раз сформулировал тезисно, в виде правил то, что сам интуитивно всегда применял. Мир наш, быть может, и стал более современным, однако свою актуальность правила не потеряли.
Пусть клиент - часть приложения, с которой непосредственно взаимодействуют пользователи и которая распространяется путем доставки определенного ее экземпляра конечным пользователям. Например:
- Браузер (фронтенд в нем)
- Мобильное приложение
- Десктоп-приложение
Тогда можно сказать следующее:
1️⃣ Нельзя доверять тому, что пришло с клиента. Все валидации или проверки должны выполняться на бэкэнде
2️⃣ Нельзя хранить секреты на клиенте. Если секреты хранятся на клиенте, то нельзя их считать секретами
3️⃣ Нельзя выполнять запросы с аутентификацией к внешним API с клиента (следует из п. 2)
4️⃣ Нельзя полагаться на криптографию на клиенте для сокрытия данных от самого пользователя. Шифрование на клиенте имеет смысл только для защиты данных пользователя от бэкенда (здесь изменил исходную формулировку)
5️⃣ Никогда не доверяйте клиентской части «фильтрацию» лишних данных
Как считаете, справедлив ли такой список? Можно ли его чем-то дополнить?
Кстати, откопал и презентацию с того доклада. Подчистил от корпоративной символики и публикую ее здесь.
В ней в том числе есть ссылка на потрясающий материал про CSRF, где рассказывают про Cross-Site Request Forgery в стилистике Гарри Поттера : Defense Against the Dark Arts: CSRF Attacks.
Если никогда не читали, настоятельно рекомендую, подача очень крутая. Даже если и несколько устарел, базовые проблемы не изменились. Есть и перевод на русский.
#api #security
👍13🤔1
Что нового в мире защиты от CSRF
В продолжение прошлого поста, где упомянул в том числе и CSRF. Мне кажется, мы привыкаем, что для "типовых" задач принципиально новые решения не так и часто появляются. Поэтому особенно интересно обратить внимание на случай, когда позволяемый изменениями в технологиях подход встает сразу на одну ступень с аксакалами мира защиты от CSRF, основанными на токенах.
Еще сначала нужно отметить, что современные CSRF - они не всегда и cross-site, часто по привычке так называют и same-site cross-origin случаи (картинка для тех, кто хочет вспомнить различия между site и origin).
В конце прошлого года наткнулся на статью CSRF Protection without Tokens or Hidden Form Fields. Автор описывает, как в процессе изучения современных подходов к защите от CSRF для имплементации в своем веб-фреймворке он узнал про метод, основанный на Sec-Fetch-Site заголовке. А прочитав статью, узнать об этом можем и мы :)
Идея здесь следующая: все современные (современные, это важно) браузеры умеют отправлять специальный заголовок
-
-
-
-
Так мы можем определить отношения между origin, с которого происходит вызов и origin, куда запрос направляется. Главная штука в том, что на клиентской части ничего делать не нужно, браузер заголовок отправит сам, остается только проверять его на сервере. При этом возможно реализовать фоллбэк на какой-либо из классических подходов, если браузер в такие заголовки не сумел.
В декабре был обновлен и CSRF Prevention Cheat Sheet от OWASP, теперь рекомендации есть и там, причем после дискуссий, как понимаю, подняли применимость использования fetch metadata-заголовков до одной из основных мер, а не только как defense in depth. Но при этом подчеркивают, что механизм свежий и раскатывать нужно аккуратно и поглядывая на приборы. Ну и опять же учитывать, если ли у вас пользователи с более старыми версиями браузеров или нет.
На самом деле, мы можем увидеть, что гугл говорил о подобной возможности еще с 2019 года, вот, например, довольна ранняя публикация про fetch metadata. Но товарищ Safari не очень торопился поддержать fetch metadata-заголовки и сделал это только в 2023.
Интересно, если кто-то уже имплементировал работу с таким заголовком, какие еще могут быть нюансы и подводные камни?
#api #security
В продолжение прошлого поста, где упомянул в том числе и CSRF. Мне кажется, мы привыкаем, что для "типовых" задач принципиально новые решения не так и часто появляются. Поэтому особенно интересно обратить внимание на случай, когда позволяемый изменениями в технологиях подход встает сразу на одну ступень с аксакалами мира защиты от CSRF, основанными на токенах.
Еще сначала нужно отметить, что современные CSRF - они не всегда и cross-site, часто по привычке так называют и same-site cross-origin случаи (картинка для тех, кто хочет вспомнить различия между site и origin).
В конце прошлого года наткнулся на статью CSRF Protection without Tokens or Hidden Form Fields. Автор описывает, как в процессе изучения современных подходов к защите от CSRF для имплементации в своем веб-фреймворке он узнал про метод, основанный на Sec-Fetch-Site заголовке. А прочитав статью, узнать об этом можем и мы :)
Идея здесь следующая: все современные (современные, это важно) браузеры умеют отправлять специальный заголовок
Sec-Fetch-Site в запросах, причем значение этого заголовка не может быть задано клиентским JavaScript. Заголовок этот может принимать разные значения, а именно:-
same-origin-
same-site-
cross-site-
noneТак мы можем определить отношения между origin, с которого происходит вызов и origin, куда запрос направляется. Главная штука в том, что на клиентской части ничего делать не нужно, браузер заголовок отправит сам, остается только проверять его на сервере. При этом возможно реализовать фоллбэк на какой-либо из классических подходов, если браузер в такие заголовки не сумел.
В декабре был обновлен и CSRF Prevention Cheat Sheet от OWASP, теперь рекомендации есть и там, причем после дискуссий, как понимаю, подняли применимость использования fetch metadata-заголовков до одной из основных мер, а не только как defense in depth. Но при этом подчеркивают, что механизм свежий и раскатывать нужно аккуратно и поглядывая на приборы. Ну и опять же учитывать, если ли у вас пользователи с более старыми версиями браузеров или нет.
На самом деле, мы можем увидеть, что гугл говорил о подобной возможности еще с 2019 года, вот, например, довольна ранняя публикация про fetch metadata. Но товарищ Safari не очень торопился поддержать fetch metadata-заголовки и сделал это только в 2023.
Интересно, если кто-то уже имплементировал работу с таким заголовком, какие еще могут быть нюансы и подводные камни?
#api #security
👍9❤4🤔1
Противодействуем онлайн-атакам с перебором с помощью device cookies
Существует известная и распространенная проблема: как только мы делаем аутентификацию по паролю и выставляем куда-нибудь форму для этого, у нас появляется задача защиты от онлайн-атак с перебором, в том числе и таргетированных: где пароли подбираются под логин. Меры существуют разные, сейчас затронем ограничение количества попыток использования неверного пароля для одной УЗ.
Наивный подход – который тем не менее часто могут предлагать безопасники и который работает из коробки в условном MS AD – заключается в том, что мы временно блокируем учетную запись (УЗ) после N-го количества попыток неуспешного использования пароля. Звучит, вроде бы, легко и надежно, как швейцарские часы, но есть нюанс. Теперь ничто не мешает атакующему намеренно заблокировать таким образом УЗ легитимных пользователей, устроив тем самым локальный DoS. Если вам не верят, приведите пример, где любой Вася может заблокировать УЗ вашего CEO 🤗
После этого, следующая итерации мысли обычно предполагает изменение гранулярности блокировок: учет IP, отпечатков устройств. Это может снизить риск DoS, но при этом эффективности в защите от реальных атак добавляет не сильно. Мотивированный атакующий будет использовать произвольные отпечатки, прокси. Использование одной только CAPTCHA (вы, кстати, знали, что это акроним?) тоже не всегда может быть эффективным. Детальнее можно посмотреть, например, страничку от OWASP.
Конечно, можно сказать: "Чего нам ваши пароли, проблемы из 2008, мы лучше сделаем модный passwordless". Про него, надеюсь, тоже попозже поговорим, но зачастую такие истории довольные прохладны, особенно в существующих системах. Будем честными, сейчас все еще не так просто одномоментно рубануть с плеча и отказаться от паролей, как бы этого ни хотелось. Хотя подумать в эту сторону и полезно.
Потому ещё в 2015 году и был предложен подход с использованием device cookies, способный решить обозначенные проблемы. А еще вдвойне приятно от того, что описал концепцию Антон Дедов, мой коллега.
Мысль здесь такая: если мы не можем явно выявлять "плохие" неаутентифицированные контексты и блокировать их выборочно, давайте мы упростим себе задачу. Мы не будем пытаться заблокировать конкретный контекст по IP/отпечатку, а вместо этого мы разделим такие контексты всего лишь на две "корзинки":
1. Неизвестные устройства (на которых device cookie нет)
2. Известные устройства, с которых данный пользователь хоть раз успешно логинился (device cookie есть)
При этом учет неуспешных попыток ведется отдельно:
- для неизвестных устройств (device cookie отсутствует/невалидна)
- для известных устройств (device cookie есть и валидна)
Тогда, если первый счетчик достигнет лимита, легитимный пользователь с нового устройства тоже не войдет, поскольку мы не отличаем его от атакующего. Но с устройства, где device cookie есть, войти сможет.
Еще один нюанс заключается как раз в том, что счетчики эти - независимые. Если положить что лимиты одинаковы и равны
Что дает такой подход? Таким образом атакующий может заблокировать или все неизвестные устройства или конкретное известное устройство, но не учетную запись вообще. В этом и заключается преимущество. Нюансы тоже есть, например, как "правильно" снимать такую блокировку. Сбрасывать все сразу для УЗ или как-то еще?
Кстати, в тексте Антон классически напоминает про проблему с JWT confusion, если использовать JWT в качестве значения таких кук. Здесь подходов к решению существует больше, можно прочитать мой пост про эту проблему.
Сохранилось и видео с оригинальной презентации материала, можете посмотреть, если заинтересовало.
Как говорится, лайк, если знали, репост, если узнали...
#iam_general #security
Существует известная и распространенная проблема: как только мы делаем аутентификацию по паролю и выставляем куда-нибудь форму для этого, у нас появляется задача защиты от онлайн-атак с перебором, в том числе и таргетированных: где пароли подбираются под логин. Меры существуют разные, сейчас затронем ограничение количества попыток использования неверного пароля для одной УЗ.
Наивный подход – который тем не менее часто могут предлагать безопасники и который работает из коробки в условном MS AD – заключается в том, что мы временно блокируем учетную запись (УЗ) после N-го количества попыток неуспешного использования пароля. Звучит, вроде бы, легко и надежно, как швейцарские часы, но есть нюанс. Теперь ничто не мешает атакующему намеренно заблокировать таким образом УЗ легитимных пользователей, устроив тем самым локальный DoS. Если вам не верят, приведите пример, где любой Вася может заблокировать УЗ вашего CEO 🤗
После этого, следующая итерации мысли обычно предполагает изменение гранулярности блокировок: учет IP, отпечатков устройств. Это может снизить риск DoS, но при этом эффективности в защите от реальных атак добавляет не сильно. Мотивированный атакующий будет использовать произвольные отпечатки, прокси. Использование одной только CAPTCHA (вы, кстати, знали, что это акроним?) тоже не всегда может быть эффективным. Детальнее можно посмотреть, например, страничку от OWASP.
Конечно, можно сказать: "Чего нам ваши пароли, проблемы из 2008, мы лучше сделаем модный passwordless". Про него, надеюсь, тоже попозже поговорим, но зачастую такие истории довольные прохладны, особенно в существующих системах. Будем честными, сейчас все еще не так просто одномоментно рубануть с плеча и отказаться от паролей, как бы этого ни хотелось. Хотя подумать в эту сторону и полезно.
Потому ещё в 2015 году и был предложен подход с использованием device cookies, способный решить обозначенные проблемы. А еще вдвойне приятно от того, что описал концепцию Антон Дедов, мой коллега.
Мысль здесь такая: если мы не можем явно выявлять "плохие" неаутентифицированные контексты и блокировать их выборочно, давайте мы упростим себе задачу. Мы не будем пытаться заблокировать конкретный контекст по IP/отпечатку, а вместо этого мы разделим такие контексты всего лишь на две "корзинки":
1. Неизвестные устройства (на которых device cookie нет)
2. Известные устройства, с которых данный пользователь хоть раз успешно логинился (device cookie есть)
При этом учет неуспешных попыток ведется отдельно:
- для неизвестных устройств (device cookie отсутствует/невалидна)
- для известных устройств (device cookie есть и валидна)
Тогда, если первый счетчик достигнет лимита, легитимный пользователь с нового устройства тоже не войдет, поскольку мы не отличаем его от атакующего. Но с устройства, где device cookie есть, войти сможет.
Еще один нюанс заключается как раз в том, что счетчики эти - независимые. Если положить что лимиты одинаковы и равны
N, тогда на самом деле у любого, кто изначально обладает валидной кукой, есть максимально 2N попыток. То есть сначала будет заблокирована возможность входа с конкретной device cookie, пользователь (атакующий) может ее сбросить (очевидно, это легко), и после у него будет еще N попыток в рамках "корзинки" с неизвестными устройствами.Что дает такой подход? Таким образом атакующий может заблокировать или все неизвестные устройства или конкретное известное устройство, но не учетную запись вообще. В этом и заключается преимущество. Нюансы тоже есть, например, как "правильно" снимать такую блокировку. Сбрасывать все сразу для УЗ или как-то еще?
Кстати, в тексте Антон классически напоминает про проблему с JWT confusion, если использовать JWT в качестве значения таких кук. Здесь подходов к решению существует больше, можно прочитать мой пост про эту проблему.
Сохранилось и видео с оригинальной презентации материала, можете посмотреть, если заинтересовало.
Как говорится, лайк, если знали, репост, если узнали...
#iam_general #security
owasp.org
Slow Down Online Guessing Attacks with Device Cookies | OWASP Foundation
Slow Down Online Guessing Attacks with Device Cookies on the main website for The OWASP Foundation. OWASP is a nonprofit foundation that works to improve the security of software.
👍17❤2🤔2
Чат сообщества
Когда в 2023 я создавал этот канал, я намерено создал сразу и чат - @unauthz401. Идея была в том, что площадки для обсуждения вопросов связанных с Identity & Access Management мне не хватало самому: порой хотелось обсудить какую-то мысль, получить сторонние мнения, задать вопрос.
Канал вырос, подписчиков здесь уже много. Однако чат так и остался "мертвым". Я очень хочу его оживить, односторонне писать, конечно, хорошо, но истина рождается в дискуссии. Из моих наблюдений, открытой русскоязычной площадки для обсуждения вопросов IAM, не привязанных к конкретному инструменту или вендору, по-прежнему нет. И я сам был бы очень рад ей, чтобы иметь возможность вести дискуссии на интересующие меня профессиональные темы.
Не буду скрывать, моя голубая мечта до сих пор - сформировать свободное сообщество грамотных IAM-специалистов и энтузистов, в котором можно обсуждать подходы, решения, делиться опытом, укреплять экспертизу и двигать отрасль вперед (как громко задвинул-то, да).
Поэтому прошу поучаствовать в опросе ниже, направленном на определение причин наличия людей в канале, но отсутствия в чате.
Когда в 2023 я создавал этот канал, я намерено создал сразу и чат - @unauthz401. Идея была в том, что площадки для обсуждения вопросов связанных с Identity & Access Management мне не хватало самому: порой хотелось обсудить какую-то мысль, получить сторонние мнения, задать вопрос.
Канал вырос, подписчиков здесь уже много. Однако чат так и остался "мертвым". Я очень хочу его оживить, односторонне писать, конечно, хорошо, но истина рождается в дискуссии. Из моих наблюдений, открытой русскоязычной площадки для обсуждения вопросов IAM, не привязанных к конкретному инструменту или вендору, по-прежнему нет. И я сам был бы очень рад ей, чтобы иметь возможность вести дискуссии на интересующие меня профессиональные темы.
Не буду скрывать, моя голубая мечта до сих пор - сформировать свободное сообщество грамотных IAM-специалистов и энтузистов, в котором можно обсуждать подходы, решения, делиться опытом, укреплять экспертизу и двигать отрасль вперед (как громко задвинул-то, да).
Поэтому прошу поучаствовать в опросе ниже, направленном на определение причин наличия людей в канале, но отсутствия в чате.
🔥3🤔1
Почему вы не пользуетесь чатом? (анонимный, мультивыбор доступен)
Anonymous Poll
70%
Не знал, что чат вообще есть
5%
Туда попадают посты с канала и комментарии, это неудобно
15%
Не понимаю, что там можно/уместно обсуждать
1%
Обсуждаю вопросы IAM в других чатах/площадках (можно написать, каких)
32%
Канал читаю, но писать не хочется
5%
Там никого нет, мало активности, не хочется начинать первым
1%
Я уже в чате, меня все устраивает
1%
Другое (буду рад, если напишете суть)
8%
Посмотреть результаты
NIST SP 800-63-4
В прошлом году была опубликована четвертая ревизия SP 800-63. Данная special publication посвящена Digital Identity Guidelines. Сам NIST обозначает SP серии 800 как “guidelines, recommendations, technical specifications, and annual reports of NIST’s cybersecurity activities”.
С точки зрения именно нормативной части применимость требований NIST ограниченна и не так актуальна для российских компаний. Однако как раз с точки зрения набора рекомендаций, хороших практик и примеров требований читать такие документы очень полезно.
Итак, SP 800-63 состоит из четырех документов:
1️⃣ SP 800-63-4: Digital Identity Guidelines. Вводный документ
2️⃣ SP 800-63A-4: Identity Proofing & Enrollment. Про требования к identity proofing
3️⃣ SP 800-63B-4: Authentication & Authenticator Management. Про требования к аутентификации
4️⃣ SP 800-63C-4: Federation & Assertions. Про требования к архитектуре систем доверительных отношений и утверждений (assertions) для передачи информации об identity
Их можно почитать как онлайн, так и скачав в PDF-формате.
Здесь сразу скажу, что придется простить за, даже для меня, чрезмерное наличие англицизмов в тексте постов: для многих терминов русские аналоги решил не подбирать.
Если давно хотели прочесть эту SP, но откладывали, это хорошая возможность начать и обсудить вопросы и мысли в чате.
Рассмотрение начнем с первого из них: SP 800-63-4: Digital Identity Guidelines.
#iam_general #security
В прошлом году была опубликована четвертая ревизия SP 800-63. Данная special publication посвящена Digital Identity Guidelines. Сам NIST обозначает SP серии 800 как “guidelines, recommendations, technical specifications, and annual reports of NIST’s cybersecurity activities”.
С точки зрения именно нормативной части применимость требований NIST ограниченна и не так актуальна для российских компаний. Однако как раз с точки зрения набора рекомендаций, хороших практик и примеров требований читать такие документы очень полезно.
Итак, SP 800-63 состоит из четырех документов:
1️⃣ SP 800-63-4: Digital Identity Guidelines. Вводный документ
2️⃣ SP 800-63A-4: Identity Proofing & Enrollment. Про требования к identity proofing
3️⃣ SP 800-63B-4: Authentication & Authenticator Management. Про требования к аутентификации
4️⃣ SP 800-63C-4: Federation & Assertions. Про требования к архитектуре систем доверительных отношений и утверждений (assertions) для передачи информации об identity
Их можно почитать как онлайн, так и скачав в PDF-формате.
Здесь сразу скажу, что придется простить за, даже для меня, чрезмерное наличие англицизмов в тексте постов: для многих терминов русские аналоги решил не подбирать.
Если давно хотели прочесть эту SP, но откладывали, это хорошая возможность начать и обсудить вопросы и мысли в чате.
Рассмотрение начнем с первого из них: SP 800-63-4: Digital Identity Guidelines.
#iam_general #security
pages.nist.gov
NIST SP 800-63 Digital Identity Guidelines
NIST Special Publication 800-63 Digital Identity Guidelines
🤔1
SP 800-63-4: Digital Identity Guidelines
Отмечается, что гайдлайны покрывают случаи, когда пользователи взаимодействуют с государственными информационными системами (разумеется, американскими). И не должны ограничивать разработку или применяться как явные правила для других целей. Что нисколько не расходится с мыслью, про которую писал ранее. Мы читаем не для того, чтобы соответствовать комплаенсу, а чтобы изучить материал и посмотреть на него как на один из примеров, что бывает полезно при формировании требований.
Еще в каждом документе есть как нормативные (normative), так и информативные (informative) секции, но для наших целей это не принципиально.
Говорят про risk-oriented approach, то есть про управление рисками через оценку конкретных угроз и контекста вместо “one-size-fits-all” подхода.
Отсюда выводят свои assurance levels. Причем для каждой функции:
🔵 Identity Assurance Level (IAL) - для identity proofing
🔵 Authentication Assurance Level (AAL) - для аутентификации
🔵 Federation Assurance Level (FAL) - для federation (системы доверительных отношений)
Каждый xAL имеет три assurance levels, все xAL кумулятивны.
Так нам и рассказывают, как читать эту SP:
🏷 Про IALs читаем SP 800-63A
🏷 Про AALs читаем SP 800-63B
🏷 Про FALs читаем SP 800-63C
Также интересно, что когда говорят про Digital Identity Risk Management (DIRM), отмечают рассмотрение рисков в двух измерениях:
1. Риски при использования “identity system”
2. Риски при реализации “identity system”
Логично, что это не одно и то же.
В документе вводятся ключевые роли и функции. При этом важно подчеркнуть, что в конкретных имплементациях компоненты могут их совмещать.
Так, говорят, что subject есть человек, причем на разных участках разных процессов он может выполнять роль
- applicant - тот, чью личность нужно установить и зарегистрировать
- subscriber - тот, кто был успешно идентифицирован и зарегистрирован или же был был успешно аутентифицирован
- claimant - тот, кто “заявляет о себе” для целей проверки аутентификации
Роль credential service provider (CSP) включает identity proofing для applicants, создание для них subscriber account и привязку аутентификаторов к нему (через создание credentials).
Verifier подтверждает личность (identity) claimant’а, убеждаясь, что claimant контролирует один или более аутентификаторов через некоторый протокол аутентификации.
Роль identity provider (IdP) актуальна для использования federations (здесь намеренно не использую слово “федерация”). IdP может работать с аутентификаторами subscriber и выпускать утверждения (assertions) о его личности.
Есть и роль relying party (RP). RP предоставляет возможность использования функциональности, основываясь на утверждении предоставленном verifier или IdP, если используется federation.
Есть вводный материал про концепцию факторов и аутентификаторов, а также federation, о чем поговорим в отдельных постах.
Приводится и описание того, что понимается под процессом аутентификации:
А еще там очень крутой словарь терминов. Полностью ознакомиться можно самостоятельно, а я сделал подборку из наиболее понравившихся мне лично.
Обсудить в чате✍️
#iam_general #security
Отмечается, что гайдлайны покрывают случаи, когда пользователи взаимодействуют с государственными информационными системами (разумеется, американскими). И не должны ограничивать разработку или применяться как явные правила для других целей. Что нисколько не расходится с мыслью, про которую писал ранее. Мы читаем не для того, чтобы соответствовать комплаенсу, а чтобы изучить материал и посмотреть на него как на один из примеров, что бывает полезно при формировании требований.
Еще в каждом документе есть как нормативные (normative), так и информативные (informative) секции, но для наших целей это не принципиально.
Говорят про risk-oriented approach, то есть про управление рисками через оценку конкретных угроз и контекста вместо “one-size-fits-all” подхода.
Отсюда выводят свои assurance levels. Причем для каждой функции:
Каждый xAL имеет три assurance levels, все xAL кумулятивны.
Так нам и рассказывают, как читать эту SP:
Также интересно, что когда говорят про Digital Identity Risk Management (DIRM), отмечают рассмотрение рисков в двух измерениях:
1. Риски при использования “identity system”
2. Риски при реализации “identity system”
Логично, что это не одно и то же.
В документе вводятся ключевые роли и функции. При этом важно подчеркнуть, что в конкретных имплементациях компоненты могут их совмещать.
Так, говорят, что subject есть человек, причем на разных участках разных процессов он может выполнять роль
- applicant - тот, чью личность нужно установить и зарегистрировать
- subscriber - тот, кто был успешно идентифицирован и зарегистрирован или же был был успешно аутентифицирован
- claimant - тот, кто “заявляет о себе” для целей проверки аутентификации
Роль credential service provider (CSP) включает identity proofing для applicants, создание для них subscriber account и привязку аутентификаторов к нему (через создание credentials).
Verifier подтверждает личность (identity) claimant’а, убеждаясь, что claimant контролирует один или более аутентификаторов через некоторый протокол аутентификации.
Роль identity provider (IdP) актуальна для использования federations (здесь намеренно не использую слово “федерация”). IdP может работать с аутентификаторами subscriber и выпускать утверждения (assertions) о его личности.
Есть и роль relying party (RP). RP предоставляет возможность использования функциональности, основываясь на утверждении предоставленном verifier или IdP, если используется federation.
Есть вводный материал про концепцию факторов и аутентификаторов, а также federation, о чем поговорим в отдельных постах.
Приводится и описание того, что понимается под процессом аутентификации:
The authentication process enables an RP to trust that a claimant is who they say they are to some level of assurance.
Well-designed protocols protect the integrity and confidentiality of communication between the claimant and the verifier both during and after the authentication and can help limit the damage done by an attacker masquerading as a legitimate verifier (i.e., phishing).
А еще там очень крутой словарь терминов. Полностью ознакомиться можно самостоятельно, а я сделал подборку из наиболее понравившихся мне лично.
Обсудить в чате
#iam_general #security
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🤔1
SP 800-63A-4: Identity Proofing and Enrollment
Данный документ приводит требования к identity proofing на каждом assurance level. Вся эта радость нужна, чтобы чтобы можно было трактовать идентификационную информацию о пользователе с некоторым уровнем уверенности.
Identity proofing - процесс сбора, валидации и верификации информации о человеке (subject) с целью обеспечения уверенности соответствия заявленной им личности (identity). То есть установление связи между некоторым лицом, использующим онлайн-сервисы, и реально существующим человеком с некоторой долей уверенности. Еще проще: убедиться, что назвавшийся Васей Пупкиным, Васей Пупкиным в реальной жизни и является.
Согласно документу, полный процесс состоит из четырех шагов:
1️⃣ Resolution: CSP получает необходимые доказательства и ключевые атрибуты, чтобы выделить конкретного человека в общей массе
2️⃣ Validation: CSP убеждается, что предоставленные доказательства и атрибуты аутентичны и действительны
3️⃣ Verification: CSP проверяет, что предъявляющий есть подлинный владелец предоставленных доказательств
4️⃣ Enrollment: после трех шагов identity proofing, applicant может стать subscriber’ом у CSP (помните, в предыдущем посте мы говорили про эти роли)
Identity assurance levels выделяют такие:
🔵 No identity proofing. Связь с реальной существующей личностью не требуется.
🔵 IAL1. Поддерживается существование реально существующей личности и предоставляется некоторая уверенность, что заявитель связан с этой личностью. Identity proofing может выполняться удаленно или очно.
🔵 IAL2. Требуется сбор дополнительных доказательств и более тщательный процесс их валидации и верификации. Identity proofing может выполняться удаленно или очно.
🔵 IAL3. Требуется участие специально обученного человека для очного взаимодействия и сбора как минимум одной биометрической характеристики.
Рассматривая методы для верификации личности, упоминают и про автоматизированную обработку биометрических характеристик. Логично, что самим работать с биометрией никто не хочет, поэтому существуют специальные провайдеры, с которыми можно интегрироваться для подобных целей. Пример от MS Entra.
Очень интересно прочитать и специальный пункт 3.14 про digital injection prevention and forged media detection. Тут пишут, что развитие и доступность генеративного ИИ делает атаки на удаленный identity proofing более эффективными. Согласно документу, все виды удаленного identity proofing так или иначе уязвимы к таким атакам.
Приводятся различные рекомендации для CSPs, я выделил следующие:
- Следует анализировать цифровые медиа-данные на наличие сигнатур генеративных ИИ и deepfake-утилит, известных для создания поддельных медиа-данных.
- Следует использовать случайные “human-in-the-loop” сигналы во время анализа входящих видео или изображений, чтобы увеличить вероятность обнаружения подделки. Например, просить пользователя повертеть чем-то, сделать специальные движения, поперемещать объект между камерой и лицом.
- Следует использовать комбинации активных и пассивных PAD (presentation attack detection).
То есть эти самые PAD предоставляют определенную защиту от инъекций и подделок, позволяя обнаружить их с некоторой вероятностью. Но даже использование таких механизмов недостаточно, чтобы покрыть все кейсы таких атак, поэтому гарантии нет.
Еще в приложении А интересная табличка с требованиями к использованию различных доказательств личности.
Обсудить в чате✍️
#iam_general #security
Данный документ приводит требования к identity proofing на каждом assurance level. Вся эта радость нужна, чтобы чтобы можно было трактовать идентификационную информацию о пользователе с некоторым уровнем уверенности.
Identity proofing - процесс сбора, валидации и верификации информации о человеке (subject) с целью обеспечения уверенности соответствия заявленной им личности (identity). То есть установление связи между некоторым лицом, использующим онлайн-сервисы, и реально существующим человеком с некоторой долей уверенности. Еще проще: убедиться, что назвавшийся Васей Пупкиным, Васей Пупкиным в реальной жизни и является.
Согласно документу, полный процесс состоит из четырех шагов:
1️⃣ Resolution: CSP получает необходимые доказательства и ключевые атрибуты, чтобы выделить конкретного человека в общей массе
2️⃣ Validation: CSP убеждается, что предоставленные доказательства и атрибуты аутентичны и действительны
3️⃣ Verification: CSP проверяет, что предъявляющий есть подлинный владелец предоставленных доказательств
4️⃣ Enrollment: после трех шагов identity proofing, applicant может стать subscriber’ом у CSP (помните, в предыдущем посте мы говорили про эти роли)
Identity assurance levels выделяют такие:
Рассматривая методы для верификации личности, упоминают и про автоматизированную обработку биометрических характеристик. Логично, что самим работать с биометрией никто не хочет, поэтому существуют специальные провайдеры, с которыми можно интегрироваться для подобных целей. Пример от MS Entra.
Очень интересно прочитать и специальный пункт 3.14 про digital injection prevention and forged media detection. Тут пишут, что развитие и доступность генеративного ИИ делает атаки на удаленный identity proofing более эффективными. Согласно документу, все виды удаленного identity proofing так или иначе уязвимы к таким атакам.
Приводятся различные рекомендации для CSPs, я выделил следующие:
- Следует анализировать цифровые медиа-данные на наличие сигнатур генеративных ИИ и deepfake-утилит, известных для создания поддельных медиа-данных.
- Следует использовать случайные “human-in-the-loop” сигналы во время анализа входящих видео или изображений, чтобы увеличить вероятность обнаружения подделки. Например, просить пользователя повертеть чем-то, сделать специальные движения, поперемещать объект между камерой и лицом.
- Следует использовать комбинации активных и пассивных PAD (presentation attack detection).
То есть эти самые PAD предоставляют определенную защиту от инъекций и подделок, позволяя обнаружить их с некоторой вероятностью. Но даже использование таких механизмов недостаточно, чтобы покрыть все кейсы таких атак, поэтому гарантии нет.
Еще в приложении А интересная табличка с требованиями к использованию различных доказательств личности.
Обсудить в чате
#iam_general #security
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🤔1
SP 800-63B-4: Authentication and Authenticator Management (часть 1)
Данный документ, кстати, мне больше нравится, чем предыдущий, ему посвятим два поста поэтому.
Здесь определение уточняется. Под аутентификацией понимается процесс валидации одного или более аутентификаторов, использованных для подтверждения личности, путем подтверждения контроля subject над некоторыми секретами, использованными для аутентификации.
Концепция секретов интересная, и я ее понял не с первого раза. Помогает определение в словаре и табличка 2 в пункте 3.
Аутентификационный секрет (authentication secret) есть некоторый объект (строка, набор байтов), которым пользователь владеет или который знает и доступность которого является фундаментом доказательства, что использует его именно “законный владелец” учетной записи.
Причем секреты бывают “long-term” и “short-term”. Первые позволяют аутентифицироваться как subscriber, покуда секрет не будет сброшен, вторые же действительны только в течение ограниченного периода времени.
Отсюда выводится любопытная часть, касающаяся биометрических характеристик. Так говорят, что биометрия не признается аутентификатором сама по себе и не может быть использована именно для однофакторной аутентификации, поскольку не представляет собой “секрет”. То есть биометрию
- невозможно скрыть;
- практически невозможно отозвать;
- ее проверка вероятностна, а не детерминирована.
Поэтому и говорят, что биометрия может использоваться исключительно для проверки локального активационного фактора для многофакторных аутентификаторов.
Кстати, уточняют, что меры защиты на всех AALs направлены на защиту от компрометации учетных данных и НЕ направлены на защиту от сознательного разглашения секретов пользователем (subscriber). И говорят, что в подавляющем большинстве случаев особо никакие меры не помогут такое обнаружить и предотвратить.
Про определения. Наверняка многие замечали, что в повседневной жизни понятие “фактор аутентификации” используется совершенно по-разному и в разных смыслах. NIST же использует понятийный аппарат, позволяющий снизить степень неоднозначности терминов.
✏️ Фактор аутентификации (authentication factor) - фундаментальная характеристика доказательства личности (identity), используемого в протоколе аутентификации. Фактор определяет природу доказательства, которое пользователь предъявляет системе для подтверждения личности. Обычно выделяют три типа факторов:
- знание (knowledge, something you know, SYK)
- владение (possession, something you have, SYH)
- принадлежность (inherence, something you are, SYA)
Нюанс: здесь пока я тоже не уверен до конца, стоит ли и как разделять фактор и тип фактора
✏️ Тип аутентификатора (authenticator type) - категория аутентификаторов, объединенных общими техническими характеристиками, такими как обеспечиваемые факторы аутентификации и используемые механизмы.
✏️ Аутентификатор (authenticator) - средство, которое контролирует пользователь и которое использует для подтверждения своей личности в процессе аутентификации. Аутентификатор предоставляет доказательство, подтверждающее контроль над одним или несколькими факторами аутентификации. Является конкретным экземпляром типа аутентификатора.
Аутентификаторы делятся на однофакторные (подтверждают только один фактор) и многофакторные (требуют проверки активационного фактора, тем самым подтверждая два фактора в рамках одного аутентификатора)
✏️ Активационный фактор (activation factor) - дополнительный фактор аутентификации, который используется для активации многофакторного аутентификатора. Это знание (секрет) или принадлежность (биометрическая характеристика). Проверяется самим аутентификатором локально и не отправляется по сети для проверки.
✏️ Учетные данные (credentials) - сущность (объект, структура данных), которая однозначно связывает личность (identity) пользователя с как минимум одним аутентификатором.
Скажу, что с терминами в индустрии как всегда все непросто. Не все разделяют тип аутентификатора и аутентификатор, часто эти понятия смешиваются в обиходе, см. [1], [2].
Продолжение ниже.
#iam_general #security
Данный документ, кстати, мне больше нравится, чем предыдущий, ему посвятим два поста поэтому.
Здесь определение уточняется. Под аутентификацией понимается процесс валидации одного или более аутентификаторов, использованных для подтверждения личности, путем подтверждения контроля subject над некоторыми секретами, использованными для аутентификации.
Концепция секретов интересная, и я ее понял не с первого раза. Помогает определение в словаре и табличка 2 в пункте 3.
Аутентификационный секрет (authentication secret) есть некоторый объект (строка, набор байтов), которым пользователь владеет или который знает и доступность которого является фундаментом доказательства, что использует его именно “законный владелец” учетной записи.
Причем секреты бывают “long-term” и “short-term”. Первые позволяют аутентифицироваться как subscriber, покуда секрет не будет сброшен, вторые же действительны только в течение ограниченного периода времени.
Отсюда выводится любопытная часть, касающаяся биометрических характеристик. Так говорят, что биометрия не признается аутентификатором сама по себе и не может быть использована именно для однофакторной аутентификации, поскольку не представляет собой “секрет”. То есть биометрию
- невозможно скрыть;
- практически невозможно отозвать;
- ее проверка вероятностна, а не детерминирована.
Поэтому и говорят, что биометрия может использоваться исключительно для проверки локального активационного фактора для многофакторных аутентификаторов.
Кстати, уточняют, что меры защиты на всех AALs направлены на защиту от компрометации учетных данных и НЕ направлены на защиту от сознательного разглашения секретов пользователем (subscriber). И говорят, что в подавляющем большинстве случаев особо никакие меры не помогут такое обнаружить и предотвратить.
Про определения. Наверняка многие замечали, что в повседневной жизни понятие “фактор аутентификации” используется совершенно по-разному и в разных смыслах. NIST же использует понятийный аппарат, позволяющий снизить степень неоднозначности терминов.
- знание (knowledge, something you know, SYK)
- владение (possession, something you have, SYH)
- принадлежность (inherence, something you are, SYA)
Нюанс: здесь пока я тоже не уверен до конца, стоит ли и как разделять фактор и тип фактора
Аутентификаторы делятся на однофакторные (подтверждают только один фактор) и многофакторные (требуют проверки активационного фактора, тем самым подтверждая два фактора в рамках одного аутентификатора)
Скажу, что с терминами в индустрии как всегда все непросто. Не все разделяют тип аутентификатора и аутентификатор, часто эти понятия смешиваются в обиходе, см. [1], [2].
Продолжение ниже.
#iam_general #security
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🤔1
SP 800-63B-4: Authentication and Authenticator Management (часть 2)
Продолжение.
Authentication assurance levels (AALs) категоризируют “силу” аутентификации.
🔵 AAL1. Предоставляет базовую уверенность, что claimant контролирует аутентификатор, связанный с аккаунтом subscriber. AAL1 требует однофакторную аутентификацию. MFA желательна, но опциональна.
🔵 AAL2. Предоставляет высокую уверенность, что claimant контролирует один или более аутентификаторов, связанных с аккаунтом subscriber. AAL2 требует проверку как минимум двух факторов аутентификации. Phishing-resistant аутентификаторы желательны, но опциональны.
🔵 AAL3. Предоставляет очень высокую уверенность, что claimant контролирует один или более аутентификаторов, связанных с аккаунтом subscriber. AAL3 требует проверку как минимум двух факторов аутентификации, при этом аутентификация должна выполняться на основе подтверждения владения ключом через использование криптографии с открытым ключом. Использование phishing-resistant аутентификаторов с неизвлекаемым приватным ключом обязательно.
Таким образом, WebAuthn credentials для AAL2 признают, но для AAL3 это должны быть именно device-bound (single-device) credentials, то есть без возможности переноса/использования на другом аутентификаторе, отличном от того, где были созданы. Кстати, это вообще ортогонально использованию passkeys, поскольку с формальной точки зрения, passkey есть именно client-side discoverable credential, а вот backup eligibility - это уже отдельный вопрос.
Интересно пишут про сессию. По такой логике, сессия создается для удовлетворенного AAL. Отсюда идет требование периодической повторной аутентификации, само ограничение для всех обязательно, но вот значение диктуют только для AAL3:
🔵 Для AAL1: Рекомендуется не реже, чем каждые 30 дней. Время неактивности для сессии опционально.
🔵 Для AAL2: Рекомендуется не реже, чем каждые 24 часа. Время неактивности для сессии опционально, рекомендуется не более 1 часа.
🔵 Для AAL3: Обязательно не реже, чем каждые 12 часов. Время неактивности для сессии опционально, рекомендуется не более 15 минут. Для переаутентификации использование session ID не считается за фактор, в отличие от AAL2.
Сводную табличку можно посмотреть в п. 2.5
Отмечают возможность использования дополнительных данных контекста для risk-based аутентификации, но согласно документу это не является заменой факторам и не должно влиять на смену AAL.
Пункт 3 говорит про существующие типы аутентификаторов. Тут нам, например, говорят, что для out-of-band типа аутентификаторов использование email OTP запрещается, а вот SMS OTP не рекомендуют, но и явно пока не запрещают. Хотя отмечают, что в будущем требования могут ужесточиться. Для него аж ввели специальный статус - restricted authenticator (п. 3.2.9).
Интересно про аутентификационное намерение (authentication intent). Идея в том, чтобы процесс аутентификации мог включать в себя явное намерение пользователя выполнить аутентификацию. Цель - затруднить использование аутентификаторов без ведома самого пользователя. Примером намерения является предложение потрогать аппаратный ключ безопасности. Кстати, отмечают, что предоставление биометрической характеристики не всегда может служить демонстрацией намерения: мол, телефон может отсканировать твое лицо и без твоего участия. Видимо, поэтому при использовании разблокировки по лицу для доступа в приложения требуется еще и нажать кнопочку.
Есть там и приложение А про пароли, о котором много упоминали в сети. На основании исследований пишут, что требования к длине паролей полезнее, чем т.н. composition rules, например, требования к содержанию символов разных классов.
Но при этом отмечают и пользу от проверок паролей по спискам распространенных, причем пишут, что такой список нет смысла делать слишком большим. Также полезно подчеркнуть, что для activation secrets, проверяемых локально, требования смягчены.
Это, естественно, далеко не все интересное, что есть в документе, поэтому очень советую прочитать полностью самим.
Обсудить в чате✍️
#iam_general #security
Продолжение.
Authentication assurance levels (AALs) категоризируют “силу” аутентификации.
Таким образом, WebAuthn credentials для AAL2 признают, но для AAL3 это должны быть именно device-bound (single-device) credentials, то есть без возможности переноса/использования на другом аутентификаторе, отличном от того, где были созданы. Кстати, это вообще ортогонально использованию passkeys, поскольку с формальной точки зрения, passkey есть именно client-side discoverable credential, а вот backup eligibility - это уже отдельный вопрос.
Интересно пишут про сессию. По такой логике, сессия создается для удовлетворенного AAL. Отсюда идет требование периодической повторной аутентификации, само ограничение для всех обязательно, но вот значение диктуют только для AAL3:
Сводную табличку можно посмотреть в п. 2.5
Отмечают возможность использования дополнительных данных контекста для risk-based аутентификации, но согласно документу это не является заменой факторам и не должно влиять на смену AAL.
Пункт 3 говорит про существующие типы аутентификаторов. Тут нам, например, говорят, что для out-of-band типа аутентификаторов использование email OTP запрещается, а вот SMS OTP не рекомендуют, но и явно пока не запрещают. Хотя отмечают, что в будущем требования могут ужесточиться. Для него аж ввели специальный статус - restricted authenticator (п. 3.2.9).
Интересно про аутентификационное намерение (authentication intent). Идея в том, чтобы процесс аутентификации мог включать в себя явное намерение пользователя выполнить аутентификацию. Цель - затруднить использование аутентификаторов без ведома самого пользователя. Примером намерения является предложение потрогать аппаратный ключ безопасности. Кстати, отмечают, что предоставление биометрической характеристики не всегда может служить демонстрацией намерения: мол, телефон может отсканировать твое лицо и без твоего участия. Видимо, поэтому при использовании разблокировки по лицу для доступа в приложения требуется еще и нажать кнопочку.
Есть там и приложение А про пароли, о котором много упоминали в сети. На основании исследований пишут, что требования к длине паролей полезнее, чем т.н. composition rules, например, требования к содержанию символов разных классов.
Но при этом отмечают и пользу от проверок паролей по спискам распространенных, причем пишут, что такой список нет смысла делать слишком большим. Также полезно подчеркнуть, что для activation secrets, проверяемых локально, требования смягчены.
Это, естественно, далеко не все интересное, что есть в документе, поэтому очень советую прочитать полностью самим.
Обсудить в чате
#iam_general #security
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤2🤔2
Про OAuth для AI-агентов и MCP
Безусловно, хайп вокруг AI не обошел и OAuth, так можно увидеть, что на самом деле появляется довольно много различных материалов вокруг использования OAuth для таких сценариев.
Сразу скажу, что я не эксперт в AI-вопросах и пока глубоко не разбирался в устройстве механизмов под капотом. Также не сталкивался в рабочих задачах, хотя у меня есть коллеги, для кого это уже актуально и кто про это думает.
Здесь можно посмотреть на вопрос под двумя углами.
С одной стороны, мне до сих пор кажется, что это все есть частные случаи решения общих проблем. Это те же самые задачи, которые были актуальны, еще когда все говорили про "микросервисы": гранулярная авторизация доступа, цепочки делегации, ограничение области действия токенов доступа, определение и доверие к workload identities.
Просто тогда все на это забивали болт, вот суровая правда. Кому были бы интересны микросервисы, если бы оказалось, что нужно еще и о таких гадостях думать. А сейчас у нас вместо, как считалось, детерминированного и понятного сервиса появляется недетерминированный и непонятный агент, которому уже не сильно хочется доверять.
Ошибка мышления здесь как раз в том, что сервисы почему-то многие решили считать надежными и понятными. При этом все же понимают, что какой там код напишут (или подключат) на деле и кто будет иметь доступ к хостам, часто не так хорошо регулируется или вообще одному богу известно.
Получается, те же самые вызовы, они уже были, но сейчас встали острее, поскольку больше риск того, что условный агент разнесет вам прод или сделает то, чего делать не должен.
Поэтому с другой стороны, степень решения таких задач действительно изменилась. Агент управляется промптами, подвержен галлюцинациям и инъекциям, здесь все же мы не можем до такой степени детерминировать результат. С развитием MCP упростилось подключение агентов к корпоративным системам. Агенты еще и друг с другом взаимодействуют. Отсюда как раз возникают вопросы вида "а как гранулярнее авторизовать доступ, чтобы агент смог прочитать мои письма от Booking, но не смог читать другую переписку на основе намерения, выраженного естественным языком". Scopes здесь слишком широкие, а как присобачить условный RAR, надо еще думать.
Также, как понимаю, самих т.н. agentic identities становится больше, и их рост может быть неконтролируемым, вот все снова и вспоминают, что perimeter security маловато, да и широкие долгоживущие креды имеют неприятное свойство в виде подверженности компрометации...
К чему я это пишу. На прошлой неделе в переписку OAuth WG George Fletcher написал письмо. В нем он говорит, что в последнее время OAuth WG завалили различными AI-related драфтами и что они заводятся несистемно, пытаясь решить какие-то частные случаи в каждой из спецификаций. И, мол, надо бы сделать шаг назад и поcмотреть на проблемы глобальнее. И такой подход звучит здраво.
Если интересно, полный текст:
#oauth #iam_general
Безусловно, хайп вокруг AI не обошел и OAuth, так можно увидеть, что на самом деле появляется довольно много различных материалов вокруг использования OAuth для таких сценариев.
Сразу скажу, что я не эксперт в AI-вопросах и пока глубоко не разбирался в устройстве механизмов под капотом. Также не сталкивался в рабочих задачах, хотя у меня есть коллеги, для кого это уже актуально и кто про это думает.
Здесь можно посмотреть на вопрос под двумя углами.
С одной стороны, мне до сих пор кажется, что это все есть частные случаи решения общих проблем. Это те же самые задачи, которые были актуальны, еще когда все говорили про "микросервисы": гранулярная авторизация доступа, цепочки делегации, ограничение области действия токенов доступа, определение и доверие к workload identities.
Просто тогда все на это забивали болт, вот суровая правда. Кому были бы интересны микросервисы, если бы оказалось, что нужно еще и о таких гадостях думать. А сейчас у нас вместо, как считалось, детерминированного и понятного сервиса появляется недетерминированный и непонятный агент, которому уже не сильно хочется доверять.
Ошибка мышления здесь как раз в том, что сервисы почему-то многие решили считать надежными и понятными. При этом все же понимают, что какой там код напишут (или подключат) на деле и кто будет иметь доступ к хостам, часто не так хорошо регулируется или вообще одному богу известно.
Получается, те же самые вызовы, они уже были, но сейчас встали острее, поскольку больше риск того, что условный агент разнесет вам прод или сделает то, чего делать не должен.
Поэтому с другой стороны, степень решения таких задач действительно изменилась. Агент управляется промптами, подвержен галлюцинациям и инъекциям, здесь все же мы не можем до такой степени детерминировать результат. С развитием MCP упростилось подключение агентов к корпоративным системам. Агенты еще и друг с другом взаимодействуют. Отсюда как раз возникают вопросы вида "а как гранулярнее авторизовать доступ, чтобы агент смог прочитать мои письма от Booking, но не смог читать другую переписку на основе намерения, выраженного естественным языком". Scopes здесь слишком широкие, а как присобачить условный RAR, надо еще думать.
Также, как понимаю, самих т.н. agentic identities становится больше, и их рост может быть неконтролируемым, вот все снова и вспоминают, что perimeter security маловато, да и широкие долгоживущие креды имеют неприятное свойство в виде подверженности компрометации...
К чему я это пишу. На прошлой неделе в переписку OAuth WG George Fletcher написал письмо. В нем он говорит, что в последнее время OAuth WG завалили различными AI-related драфтами и что они заводятся несистемно, пытаясь решить какие-то частные случаи в каждой из спецификаций. И, мол, надо бы сделать шаг назад и поcмотреть на проблемы глобальнее. И такой подход звучит здраво.
Если интересно, полный текст:
On Monday at the OAuth meeting for IETF 125 a number of AI related proposals were made to extend existing OAuth mechanisms in different ways. However, it seemed to me that there was overlap in the desired goals across these proposals and I’m wondering if for the AI space we need to take a step back and define the desired requirements before making spec level proposals. Just in what was presented, there is fragmentations and this doesn’t include a number of other proposals that have been made (either to IETF or otherwise) but were not presented.
General topics that seem to come up frequently:
* identifiers - instance, owner, version, …
* fine-grained authorization - RAR, scope extensions, transaction tokens, …
* delegated authorization - delegation chain, delegation capabilities, on-behalf-of, for-the-benefit-of, …
* context & intent - transformation of original intent for specific delegation task, ...
* consent - levels of delegation before consent is required, back channel consent, …
* privacy -
I’m sure there are more. I know it takes more time, but I believe we should address these issues holistically rather than on a spec by spec basis.
#oauth #iam_general
👍6🤔1
401 Unauthorized: аутентификация и не только
Про OAuth для AI-агентов и MCP Безусловно, хайп вокруг AI не обошел и OAuth, так можно увидеть, что на самом деле появляется довольно много различных материалов вокруг использования OAuth для таких сценариев. Сразу скажу, что я не эксперт в AI-вопросах и…
Кроме этого, недавно прошла встреча IETF-группы как раз про безопасность "agentic AI apllications". Я подключиться не добрался, зато на прошлой неделе выложили запись. Не сказал бы, что целиком она интересная, но послушал. В целом направление мысли звучит схожее.
Из любопытных выступлений выделил бы:
1. A New Model for Authentication and Authorization of AI agent Interactions, Presenter Brian Campbell (18:40-28:00)
2. Agent Operation Authorization, Framework and Practices, Presenter Dapeng Liu (53:18-1:02:32)
Какие тезисы подчеркнул для себя:
- Угрозы становятся более неявными (implicit)
- AI agent - в общем случае такой же workload (но не все так считают)
- По умолчанию безопасность низкая: например, чтобы не подтверждать каждый чих, проще дать какой-то "доступ по умолчанию" и забыть, иначе работать неудобно
- Многие решения и подходы уже существуют, давайте использовать, что уже придумано
- Крутые инструменты (как tools, те же подходы) уже есть и придуманы, но не используются широко
- При этом есть много стандартов и подходов, но единого фреймворка нет
- Развитие идет быстро, вероятно, есть некоторая срочность (urgency) для выработки решений
Также можно посмотреть саммари встречи: до чего там товарищи договорились.
#iam_general #oauth #security
Из любопытных выступлений выделил бы:
1. A New Model for Authentication and Authorization of AI agent Interactions, Presenter Brian Campbell (18:40-28:00)
2. Agent Operation Authorization, Framework and Practices, Presenter Dapeng Liu (53:18-1:02:32)
Какие тезисы подчеркнул для себя:
- Угрозы становятся более неявными (implicit)
- AI agent - в общем случае такой же workload (но не все так считают)
- По умолчанию безопасность низкая: например, чтобы не подтверждать каждый чих, проще дать какой-то "доступ по умолчанию" и забыть, иначе работать неудобно
- Многие решения и подходы уже существуют, давайте использовать, что уже придумано
- Крутые инструменты (как tools, те же подходы) уже есть и придуманы, но не используются широко
- При этом есть много стандартов и подходов, но единого фреймворка нет
- Развитие идет быстро, вероятно, есть некоторая срочность (urgency) для выработки решений
Также можно посмотреть саммари встречи: до чего там товарищи договорились.
#iam_general #oauth #security
👍5❤1🤔1
401 meetup – call for papers
Друзья, пишу поделиться отличной новостью!
Анонсирую оффлайн-митап про Identity & Access Management (IAM) в Москве 27 мая. Концепция: свободный вендор-независимый митап для сообщества.
Подробности и начало регистрации для участников будут объявлены позднее, а пока приглашаю спикеров заявиться с докладами.
Очень жду и приветствую доклады про аутентификацию, управление доступом и смежные области. Это будет классная возможность выступить на релевантную аудиторию.
Тайминг 35-40 минут. Запись постараюсь организовать, чтобы материалы были доступны.
Принимаем любые идеи, крутые технические или архитектурные доклады всегда в цене. А если вам нужно вдохновение, вот темы, о которых особенно хочется послушать:
⛔️ Для подачи заявки на доклад заполняйте форму.
Прием заявок открыт до 1 мая (но времени не так много, не затягивайте). Со всеми заполнившими форму свяжемся.
По вопросам можно писать Андрею Кузнецову.
Сомневаетесь, подходит ли ваша тема? Оставляйте заявку – обсудим и подумаем вместе. Мы открыты к специалистам с различным опытом и профилем.
Если у вас есть идея доклада, но вы никогда не выступали и переживаете, мы поддержим и поможем подготовиться <3
Напоследок TLDR:
📆 27 мая оффлайн в Москве, площадку согласился предоставить Яндекс
📩 Заявки на доклады присылайте в форму до 1 мая
Stay tuned!
#announce #iam_general
Друзья, пишу поделиться отличной новостью!
Анонсирую оффлайн-митап про Identity & Access Management (IAM) в Москве 27 мая. Концепция: свободный вендор-независимый митап для сообщества.
Подробности и начало регистрации для участников будут объявлены позднее, а пока приглашаю спикеров заявиться с докладами.
Очень жду и приветствую доклады про аутентификацию, управление доступом и смежные области. Это будет классная возможность выступить на релевантную аудиторию.
Тайминг 35-40 минут. Запись постараюсь организовать, чтобы материалы были доступны.
Принимаем любые идеи, крутые технические или архитектурные доклады всегда в цене. А если вам нужно вдохновение, вот темы, о которых особенно хочется послушать:
- Аутентификация и авторизация: MFA, passwordless, адаптивная risk-based аутентификация, Just-in-Time Access, политики и модели контроля доступа
- Протоколы и стандарты: интересные, новаторские практики использования OAuth 2.0, OIDC, SAML, применение новых RFC и спецификаций
- Безопасность identity: Identity Threat Detection and Response (ITDR), уязвимости, атаки на аутентификацию, контроль доступа и меры защиты от них
- Практика и highload: опыт использования “нестандартного” Open Source (Ory, Casdoor, ZITADEL, etc.), адаптация IAM под высокие нагрузки и специфичные НФТ, разработка собственных IAM-решений
- Новые вызовы: аутентификация и контроль доступа для AI-агентов и MCP
- Enterprise-задачи: B2B IAM, федерации, мультитенантность
- Customer IAM (CIAM): UX и безопасность, управление аккаунтами и согласиями, social login
- Архитектура: аутентификация и контроль доступа в распределенных системах, service-to-service взаимодействия, SPIFFE
- Интеграции: комплексные решения из нескольких компонентов: IdM, IAM, SIEM, API Gateway, etc.
Прием заявок открыт до 1 мая (но времени не так много, не затягивайте). Со всеми заполнившими форму свяжемся.
По вопросам можно писать Андрею Кузнецову.
Сомневаетесь, подходит ли ваша тема? Оставляйте заявку – обсудим и подумаем вместе. Мы открыты к специалистам с различным опытом и профилем.
Если у вас есть идея доклада, но вы никогда не выступали и переживаете, мы поддержим и поможем подготовиться <3
Напоследок TLDR:
📆 27 мая оффлайн в Москве, площадку согласился предоставить Яндекс
📩 Заявки на доклады присылайте в форму до 1 мая
Stay tuned!
#announce #iam_general
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥20❤6👍3🤔1