🔐 AuthentiK vs Keycloak: экспресс сравнение решений по управлению доступом
🔍 Саммери:
- AuthentiK: Подходит для небольших и средних проектов. Простой в развертывании и управлении IAM. Идеален для быстрого старта при ограниченных ресурсах.
- Keycloak: Оптимален для крупных предприятий с большой инфраструктурой. Обеспечивает широкие возможности настройки и интеграции, но требует больше ресурсов на поддержку.
🛠️ Overview:
- AuthentiK:
- Преимущества: Легкость развертывания, низкое потребление ресурсов, гибкость интеграции с микросервисами.
- Keycloak:
- Преимущества: Расширенные функции, высокая масштабируемость и надежность, широкие возможности настройки и интеграции.
👤 Интерфейс пользователя:
- AuthentiK: Интуитивно понятный интерфейс, быстрый onboarding, низкие затраты на поддержку.
- Keycloak: Расширенные возможности настройки, инструменты интеграции с другими системами.
🔑 Основные функции:
- AuthentiK: Аутентификация, авторизация, управление пользователями.
- Keycloak: Аутентификация, авторизация, управление пользователями, повышенные возможности безопасности, поддержка SSO, федерация пользователей, MFA.
⚠️ Оба решения имеют свои сильные стороны. Выбор между AuthentiK и Keycloak зависит от ваших потребностей в функциональности и масштабируемости.
🔗 Ссылка на GitHub AuthentiK
🔗 Ссылка на GitHub Keycloak
Stay secure and read SecureTechTalks 📚
#opensource #IAM #keycloak #authentik #authentication #LDAP
🔍 Саммери:
- AuthentiK: Подходит для небольших и средних проектов. Простой в развертывании и управлении IAM. Идеален для быстрого старта при ограниченных ресурсах.
- Keycloak: Оптимален для крупных предприятий с большой инфраструктурой. Обеспечивает широкие возможности настройки и интеграции, но требует больше ресурсов на поддержку.
🛠️ Overview:
- AuthentiK:
- Преимущества: Легкость развертывания, низкое потребление ресурсов, гибкость интеграции с микросервисами.
- Keycloak:
- Преимущества: Расширенные функции, высокая масштабируемость и надежность, широкие возможности настройки и интеграции.
👤 Интерфейс пользователя:
- AuthentiK: Интуитивно понятный интерфейс, быстрый onboarding, низкие затраты на поддержку.
- Keycloak: Расширенные возможности настройки, инструменты интеграции с другими системами.
🔑 Основные функции:
- AuthentiK: Аутентификация, авторизация, управление пользователями.
- Keycloak: Аутентификация, авторизация, управление пользователями, повышенные возможности безопасности, поддержка SSO, федерация пользователей, MFA.
⚠️ Оба решения имеют свои сильные стороны. Выбор между AuthentiK и Keycloak зависит от ваших потребностей в функциональности и масштабируемости.
🔗 Ссылка на GitHub AuthentiK
🔗 Ссылка на GitHub Keycloak
Stay secure and read SecureTechTalks 📚
#opensource #IAM #keycloak #authentik #authentication #LDAP
🔐 Hanko: открытая альтернатива Auth0 и Clerk для эпохи Passkey
Пароли устарели. Время для новых решений.
🚀 Что такое Hanko?
Hanko — это полностью открытая платформа для аутентификации и управления пользователями, созданная для современной цифровой среды. Она предлагает:
➖ Поддержку Passkey: нативная реализация безпарольной аутентификации с использованием современных стандартов.
➖ Гибкие сценарии входа: настройка различных вариантов входа, включая безпарольные, с паролем, только через социальные сети или только с использованием Passkey.
➖ Интеграцию с социальными сетями: поддержка OAuth SSO для провайдеров, таких как Google, Apple, GitHub, а также возможность подключения собственных OIDC/OAuth2 соединений.
➖ Готовность к корпоративному использованию: встроенная поддержка SAML для корпоративных провайдеров идентификации.
➖ Многофакторную аутентификацию (MFA): включает TOTP и аппаратные ключи безопасности.
➖ Hanko Elements: настраиваемые веб-компоненты для бесшовной интеграции входа, регистрации и управления профилем пользователя.
➖ API-first архитектуру: легковесный, ориентированный на backend дизайн, созданный для гибкости и облачного развертывания.
➖ Интернационализацию (i18n): поддержка пользовательских переводов и локализованных интерфейсов.
➖ Вебхуки и управление сессиями: серверные сессии с возможностью удаленного завершения и обработки событий.
➖ Самостоятельное размещение или облако: выбор между Hanko Cloud или развертыванием на собственной инфраструктуре, без привязки к поставщику.
🧩 Совсем коротко
Hanko предоставляет разработчикам полный контроль над процессами аутентификации и управления пользователями. С помощью Hanko Elements можно легко внедрить компоненты входа и регистрации в любое веб-приложение. Эти компоненты легко настраиваются и интегрируются с различными фреймворками, такими как React, SvelteKit, Remix и другими.
🛠️ Преимущества Hanko
➖ Открытый исходный код: полный доступ к коду позволяет адаптировать решение под конкретные потребности.
➖ Гибкость: возможность настройки различных сценариев аутентификации в зависимости от требований приложения.
➖ Современные стандарты безопасности: поддержка Passkey, MFA и других современных методов аутентификации.
➖ Простота интеграции: готовые компоненты и SDK упрощают процесс внедрения в существующие проекты.
➖ Отсутствие привязки к поставщику: возможность самостоятельного размещения обеспечивает полный контроль над данными и инфраструктурой.
🌐 Ссылки:
➖ GitHub: github.com/teamhanko/hanko
➖ Документация: docs.hanko.io
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #Hanko #Passkey #Authentication #OpenSource #CyberSecurity #UserManagement #MFA #SSO #WebAuthn
Пароли устарели. Время для новых решений.
🚀 Что такое Hanko?
Hanko — это полностью открытая платформа для аутентификации и управления пользователями, созданная для современной цифровой среды. Она предлагает:
🧩 Совсем коротко
Hanko предоставляет разработчикам полный контроль над процессами аутентификации и управления пользователями. С помощью Hanko Elements можно легко внедрить компоненты входа и регистрации в любое веб-приложение. Эти компоненты легко настраиваются и интегрируются с различными фреймворками, такими как React, SvelteKit, Remix и другими.
🛠️ Преимущества Hanko
🌐 Ссылки:
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #Hanko #Passkey #Authentication #OpenSource #CyberSecurity #UserManagement #MFA #SSO #WebAuthn
Please open Telegram to view this post
VIEW IN TELEGRAM
1
🔐 Secretless Broker — секреты под замком, без ключей в коде
⚡️ Secretless Broker — open-source прокси, созданный в CyberArk для того, чтобы ваши приложения никогда не видели и не хранили чувствительные секреты вроде паролей или API-ключей. Он буквально убирает секреты из кода, из конфигураций и из среды выполнения — и всё это без радикальных переделок архитектуры.
🚀 Принцип работы
Secretless Broker — sidecar-прокси, который встраивается рядом с вашим приложением (например, в Kubernetes Pod), перехватывает запросы к защищённым сервисам и добавляет к ним аутентификацию.
👉 Само приложение при этом общается с прокси как будто напрямую с целевой БД или API — никаких секретов внутри кода или переменных окружения.
🔑 Инструмент сам «подцепляет» секреты из защищённого хранилища (например, HashiCorp Vault, CyberArk Conjur, Kubernetes Secrets) и прозрачно использует их для подключения к нужным сервисам.
Таким образом, вы минимизируете риск утечек и исключаете «hardcoded credentials» вообще.
🧩 Что поддерживается?
✅ PostgreSQL
✅ MySQL
✅ MSSQL
✅ MongoDB
✅ Redis
✅ SSH
✅ LDAP
✅ AWS RDS
✅ Generic HTTP API
⚙️ Архитектура
Решение состоит из:
🔸 Listener’ов — слушают подключение приложения (например, через локальный сокет или порт)
🔸 Handlers — управляют аутентификацией к целевому сервису
🔸 Providers — берут секреты из хранилища и подают их на вход Handler’у
Эти блоки конфигурируются через YAML, который задаёт, протокол и параметры подключений использовать.
🛡️ За счёт чего митигируем риски?
✋ Разработчику не нужно знать секреты — даже при отладке.
✋ DevOps не таскает ключи по CI/CD пайплайнам.
✋ Секреты обновляются централизованно, без перекатывания приложений.
✋ Снижается вероятность компрометации ключей при инцидентах.
💥 Почему не классический Secret Managers?
Обычные Secret Managers — это всё равно «тайник», к которому должен обратиться ваш код.
Secretless Broker убирает сам момент «доставки» секрета в приложение: приложение его никогда не видит.
🐳 Kubernetes ready
Проект активно используется в Kubernetes как sidecar-контейнер, что идеально подходит для реализации Zero Trust и DevSecOps. Есть примеры Helm-чартов, манифестов, CRD — всё для быстрого старта в кластерной среде.
🌟 Фишки
✨ Поддержка динамических ротаций секретов
✨ Горячая перезагрузка конфигов
✨ Плагины для кастомных провайдеров
🔎 Полезные ссылки
👉 Документация: secretless.io
👉 GitHub: github.com/cyberark/secretless-broker
👉 Примеры Kubernetes: k8s examples
✅ Итог
Secretless Broker интересный инструмент, который позволяет:
🔐 держать секреты вне приложения,
🚫 минимизировать attack surface,
⚡️ ускорить DevOps,
и сделать кибербезопасность нативной частью пайплайнов.
Stay secure and read SecureTechTalks 📚
#секреты #cyberark #devsecops #kubernetes #opensource #security #infrastructure #api #authentication #SecureTechTalks
⚡️ Secretless Broker — open-source прокси, созданный в CyberArk для того, чтобы ваши приложения никогда не видели и не хранили чувствительные секреты вроде паролей или API-ключей. Он буквально убирает секреты из кода, из конфигураций и из среды выполнения — и всё это без радикальных переделок архитектуры.
🚀 Принцип работы
Secretless Broker — sidecar-прокси, который встраивается рядом с вашим приложением (например, в Kubernetes Pod), перехватывает запросы к защищённым сервисам и добавляет к ним аутентификацию.
👉 Само приложение при этом общается с прокси как будто напрямую с целевой БД или API — никаких секретов внутри кода или переменных окружения.
🔑 Инструмент сам «подцепляет» секреты из защищённого хранилища (например, HashiCorp Vault, CyberArk Conjur, Kubernetes Secrets) и прозрачно использует их для подключения к нужным сервисам.
Таким образом, вы минимизируете риск утечек и исключаете «hardcoded credentials» вообще.
🧩 Что поддерживается?
✅ PostgreSQL
✅ MySQL
✅ MSSQL
✅ MongoDB
✅ Redis
✅ SSH
✅ LDAP
✅ AWS RDS
✅ Generic HTTP API
⚙️ Архитектура
Решение состоит из:
🔸 Listener’ов — слушают подключение приложения (например, через локальный сокет или порт)
🔸 Handlers — управляют аутентификацией к целевому сервису
🔸 Providers — берут секреты из хранилища и подают их на вход Handler’у
Эти блоки конфигурируются через YAML, который задаёт, протокол и параметры подключений использовать.
🛡️ За счёт чего митигируем риски?
✋ Разработчику не нужно знать секреты — даже при отладке.
✋ DevOps не таскает ключи по CI/CD пайплайнам.
✋ Секреты обновляются централизованно, без перекатывания приложений.
✋ Снижается вероятность компрометации ключей при инцидентах.
💥 Почему не классический Secret Managers?
Обычные Secret Managers — это всё равно «тайник», к которому должен обратиться ваш код.
Secretless Broker убирает сам момент «доставки» секрета в приложение: приложение его никогда не видит.
🐳 Kubernetes ready
Проект активно используется в Kubernetes как sidecar-контейнер, что идеально подходит для реализации Zero Trust и DevSecOps. Есть примеры Helm-чартов, манифестов, CRD — всё для быстрого старта в кластерной среде.
🌟 Фишки
✨ Поддержка динамических ротаций секретов
✨ Горячая перезагрузка конфигов
✨ Плагины для кастомных провайдеров
🔎 Полезные ссылки
👉 Документация: secretless.io
👉 GitHub: github.com/cyberark/secretless-broker
👉 Примеры Kubernetes: k8s examples
✅ Итог
Secretless Broker интересный инструмент, который позволяет:
🔐 держать секреты вне приложения,
🚫 минимизировать attack surface,
⚡️ ускорить DevOps,
и сделать кибербезопасность нативной частью пайплайнов.
Stay secure and read SecureTechTalks 📚
#секреты #cyberark #devsecops #kubernetes #opensource #security #infrastructure #api #authentication #SecureTechTalks
👍1
🔨 Brutus: выдержит ли ваш логин реальную атаку?
Brute-force часто воспринимают как что-то устаревшее.
На митапах обсуждают zero-day и AI-атаки, а перебор паролей звучит почти скучно. Однако множество инцидентов до сих пор начинаются с подбора пароля.
🧠 Что делает Brutus
Brutus - инструмент для системного тестирования аутентификации. Он помогает понять, как ведёт себя login-механизм под нагрузкой и при ошибках.
С его помощью можно проверить:
🔍 есть ли user enumeration
⏱ реально ли работает rate limiting
🔐 корректно ли реализован lockout
🔄 можно ли обойти защиту сменой сессии или IP
Brutus эмулирует реальный login flow с токенами, CSRF, multi-step процессом, а не просто отправляет POST-запрос в цикле.
🎯 Типовой сценарий
Вы уверены, что после 5 попыток аккаунт блокируется. Запускаете тест и... выясняется:
➖ блокируется только текущая сессия
➖ блокировка действует 30 секунд
➖ сервер по-разному отвечает на «неверный логин» и «неверный пароль»
Сначала собираем валидные аккаунты. Потом атакуем только их. Brutus поможет увидеть такие расхождения заранее.
📉 Компрометация
Credential-based атаки не экзотика. Чаще всего компрометация - это комбинация:
🔁 повторно использованных паролей
❌ отсутствия MFA
💤 слабой политики блокировки
Brute-force не устарел. Уверенность, что «у нас все точно настроено правильно» продолжает держаться на тестах.
🔗 GitHub: https://github.com/praetorian-inc/brutus
Stay secure and читайте SecureTechTalks 📚
#pentest #authentication #bruteforce #appsec #websecurity #redteam #infosec #cybersecurity #securetechtalks
Brute-force часто воспринимают как что-то устаревшее.
На митапах обсуждают zero-day и AI-атаки, а перебор паролей звучит почти скучно. Однако множество инцидентов до сих пор начинаются с подбора пароля.
🧠 Что делает Brutus
Brutus - инструмент для системного тестирования аутентификации. Он помогает понять, как ведёт себя login-механизм под нагрузкой и при ошибках.
С его помощью можно проверить:
🔍 есть ли user enumeration
⏱ реально ли работает rate limiting
🔐 корректно ли реализован lockout
🔄 можно ли обойти защиту сменой сессии или IP
Brutus эмулирует реальный login flow с токенами, CSRF, multi-step процессом, а не просто отправляет POST-запрос в цикле.
🎯 Типовой сценарий
Вы уверены, что после 5 попыток аккаунт блокируется. Запускаете тест и... выясняется:
Сначала собираем валидные аккаунты. Потом атакуем только их. Brutus поможет увидеть такие расхождения заранее.
📉 Компрометация
Credential-based атаки не экзотика. Чаще всего компрометация - это комбинация:
🔁 повторно использованных паролей
❌ отсутствия MFA
💤 слабой политики блокировки
Brute-force не устарел. Уверенность, что «у нас все точно настроено правильно» продолжает держаться на тестах.
🔗 GitHub: https://github.com/praetorian-inc/brutus
Stay secure and читайте SecureTechTalks 📚
#pentest #authentication #bruteforce #appsec #websecurity #redteam #infosec #cybersecurity #securetechtalks
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🔑 Пароли уходят, но мы всё ещё за них держимся
Давно известно, что пароли слабое звено, но люди продолжают их использовать и, если честно, делают это предсказуемо плохо.
Мы переиспользуем пароли, храним их где попало и спокойно вводим их на фишинговых сайтах (даже зная о рисках). Поведение не меняется годами.
🧠 Технология уже есть
На этом фоне passkeys выглядят как очевидное решение. Они убирают саму идею пароля, вместо него используется пара криптографических ключей, где приватная часть остаётся на устройстве, а вход подтверждается через биометрию или PIN.
Получается, что красть нечего, ведь нет пароля, который можно перехватить, слить или переиспользовать. Фишинг в классическом виде тоже перестаёт работать.
Нюанс: люди уже начинают пользоваться passkeys… и не до конца понимают, что это вообще такое. Для многих это просто «ещё один способ входа», а не принципиально новая модель безопасности.
⚙️ Почему тормозит прогресс
С точки зрения безопасности всё выглядит решённым. Однако сервисы внедряют passkeys неравномерно, пользовательский опыт не везде идеален, а компании не спешат ломать привычные сценарии логина. В итоге пароли остаются просто потому, что “мы так привыкли”. Это тот редкий случай, когда инерция сильнее здравого смысла.
💣 Атаки никуда не денутся
Важно не обманываться, passkeys не делают систему “неуязвимой”. Они просто убирают огромный класс атак, связанных с паролями.
Вектор атаки смещается. Вместо кражи учётных данных фокус уходит на устройства, сессии и всё ту же социальную инженерию. То есть поверхность атаки не исчезает, она трансформируется.
🔗 Ссылка на исследование NCSC
Stay secure and read SecureTechTalks 📚
#CyberSecurity #Passkeys #FIDO2 #Authentication #NCSC #Infosec #Phishing #IdentitySecurity #SecureTechTalks
Давно известно, что пароли слабое звено, но люди продолжают их использовать и, если честно, делают это предсказуемо плохо.
Мы переиспользуем пароли, храним их где попало и спокойно вводим их на фишинговых сайтах (даже зная о рисках). Поведение не меняется годами.
🧠 Технология уже есть
На этом фоне passkeys выглядят как очевидное решение. Они убирают саму идею пароля, вместо него используется пара криптографических ключей, где приватная часть остаётся на устройстве, а вход подтверждается через биометрию или PIN.
Получается, что красть нечего, ведь нет пароля, который можно перехватить, слить или переиспользовать. Фишинг в классическом виде тоже перестаёт работать.
Нюанс: люди уже начинают пользоваться passkeys… и не до конца понимают, что это вообще такое. Для многих это просто «ещё один способ входа», а не принципиально новая модель безопасности.
⚙️ Почему тормозит прогресс
С точки зрения безопасности всё выглядит решённым. Однако сервисы внедряют passkeys неравномерно, пользовательский опыт не везде идеален, а компании не спешат ломать привычные сценарии логина. В итоге пароли остаются просто потому, что “мы так привыкли”. Это тот редкий случай, когда инерция сильнее здравого смысла.
💣 Атаки никуда не денутся
Важно не обманываться, passkeys не делают систему “неуязвимой”. Они просто убирают огромный класс атак, связанных с паролями.
Вектор атаки смещается. Вместо кражи учётных данных фокус уходит на устройства, сессии и всё ту же социальную инженерию. То есть поверхность атаки не исчезает, она трансформируется.
🔗 Ссылка на исследование NCSC
Stay secure and read SecureTechTalks 📚
#CyberSecurity #Passkeys #FIDO2 #Authentication #NCSC #Infosec #Phishing #IdentitySecurity #SecureTechTalks
👍1