Сегодня предлагаем к рассмотрению новую модель смарт-карт ридера JCR721 производства"Аладдин Р.Д.".JCR721 профессиональный отечественный доверенный смарт-карт ридер для работы со смарт-картами в корпоративной среде, имеет привычный вид дляEnterprise-сегмента.

Немного о полезных свойствах и корпусе

Корпус ридера выполнен из высококачественного пластика. На корпусе есть прорезиненные ножки, которые предотвращают скольжение по поверхности стола во время работы с устройством.

Смарт-карта погружается плавно за счёт специального механизма микролифт^TM, благодаря которому смарт-карт ридер не царапает поверхность карты.

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

В случае с карт-ридеромJCR721 контактная площадка остаётся невредимой даже после 10 тысяч подключений.

Так выглядит карта и контактная площадкапосле 1 000подключений на обычном ридере со скользящими контактами

Так выглядит карта и контактная площадкапосле 10 000подключений на ридере JCR721 с механизмом микролифт^TM

Отметим, что ресурс карт-ридераJCR721 не менее 200 000 подключений смарт-карт (вместо50000).

Внешний вид и подключение

Смарт-карт ридерJCR721 имеет пластиковый корпус, шнур для подключения к персональному компьютеру. Разъём шнура для подключения стандартныйUSB2.0Type-A. Для корректной работы на ПК требуется хотя бы один свободный порт USB 2.0 Full-speed (12 Мбит/с), ридер также может работать с USB 1.1, 2.0, 3.0, 3.1. Необходимо обеспечить подачу электропитания 5В 0.25В при токе 300 мА, которое должно обеспечиваться исправным USB-портом (USB 2.0). Для стабильной работы требуется подключение к ПК, не используя дополнительные переходники, можно использоватьUSB-хабы с внешним источником питания, но еслиUSB-хаб не имеет внешнего источника, то этого может быть недостаточно для работы ридера, т.к. сам по себеUSB-хаб обеспечивает менее 100мАна порт.

Также ридерJCR721 имеет и шнур для подключения к современным ноутбукам и портативным устройствам, имеющим разъемUSB3.1Type-C.

Если говорить о цвете корпуса, то можно отметить, что есть два стандартных цвета, светлый и тёмный. Производитель позволяет провести кастомизацию корпуса, добавив надпись на корпус или логотип компании. При заказе можно определить тип нанесения надписи или логотипа на поверхность ридераJCR721 выбрать либо тампопечать, либо метод лазерной гравировки.

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

Также производитель при больших объемах партий готов обсудить и цвет корпуса, и длину кабеля.

Можно отметить, учитывая все эти параметры, что ридер предназначен для интенсивного использования с любыми типами контактных микропроцессорных смарт-карт. Поддерживает работу с любыми контактными смарт-картами (MCU) стандарта ГОСТ Р ИСО/МЭК 7816-3-2013 Class A, B, C (5V, 3V, 1.8V) по протоколам Т=0/Т=1. Может использоваться в системах ГИС, АСУ ТП, для обеспечения безопасности персональных данных 1-го уровня защищённости, на предприятиях КИИ (критической информационной инфраструктуры), в госорганах, на предприятиях ОПК, Министерства Обороны, в банках, многофункциональных центрах (МФЦ), офисах обслуживания, в проектах типа "Электронное удостоверение", "Электронное правительство", "Электронное декларирование" и многих других.

Компания "Аладдин Р.Д." заявляет, что ридер является доверенным средством работы с данными пользователя, которые хранятся или будут храниться на смарт-картах. Ридер спроектирован по новым Требованиям доверия ФСТЭК России, в том числе для работы с гостайной.

Если рассматривать ридер для поддержки Memory-карт, работавшими по протоколам I²C (S=8), 3-wire(S=9), 2-wire(S=10), картами-счётчиками, ранее применявшимися в "телефонных картах", то на данном этапе этой поддержки нет.

Ещё немного о преимуществах нового смарт-карт ридера JCR721

Ридер очень быстрый, поддерживает все современные смарт-карты, реальная подтверждённая скорость обмена данными со смарт-картой до 625 Кбит/с. Быстродействие ридеров при работе со смарт-картой зависит от нескольких факторов. Фактор 1 скорость обмена с хостом (ПК) по интерфейсу USB 2.0., а также фактор 2 тактовая частота, подаваемая ридером на смарт-карту.

В большинстве ридеров эта частота, фиксированная (как правило, 4 МГц). Некоторые ридеры могут подавать различные частоты из фиксированного перечня (указывается в функциональном дескрипторе CCID-устройства). Смарт-карт, работающих на частоте выше 5 МГц, практически нет, поэтому чем выше частота, подаваемая ридером на смарт-карту, тем больше шансов, что данный ридер будет несовместим с большинством имеющихся на рынке смарт-карт. Стоит различать скорость обмена данными со смарт-картой и скорость при работе со смарт-картой. Последняя складывается из времени отправки команды на смарт-карту, времени обработки команды смарт-картой и времени передачи ответа от смарт-карты на ПК.

Работает смарт-карт ридер JCR721 со всеми современными операционными системами, включая Linux (со всеми российскими дистрибутивами), macOS, ОС "Эльбрус", МС ВС, Android, Sailfish/Аврора, на процессорах IA-32, IA-64, x86-64, ARM, Эльбрус, Байкал и на Microsoft Windows. Также ридер может быть подключен к ПК, где используются средства виртуализации, такие, как Hyper-V, Citrix XenServer, Virtual Box, VMWare и др.

Для работы ридера JCR721 не требуется установки специального прикладного ПО, работа ведётся через стандартные программные интерфейсы PC/SC, является CCID-совместимым устройством, не требует установки специальных драйверов и работает сразу при подключении к USB-порту компьютера (Plug and Play).

Нужно отметить, что в современных версиях ОС Windows, Linux, macOS, МС ВС, "Эльбрус", Android8 (Oreo), Sailfish Mobile при подключении ридер в системе должен определиться автоматически, при этом на его корпусе должен загореться зелёный индикатор. В этих операционных системах для работы уже существует предустановленный CCID-драйвер и входит в состав данных операционных систем. А вот для работы с операционными системами версий Microsoft Windows XP SP3 CCID-драйвер может быть установлен администратором из "Каталога Центра обновления" Microsoft при первом подключении к рабочей станции. Также для архитектуры X86, CCID-драйвер можно скачать по ссылке:http://catalog.update.microsoft.com/v7/site/ScopedViewRedirect.aspx?updateid=8e217a56-9ed7-456b-aee8-674c5c7bcdbe

Актуальный список поддерживаемых ОС, гипервизоров, виртуальных сред и процессоров можно узнать на продуктовой странице сайта Производителя https://www.aladdin-rd.ru/catalog/readers/JCR-721

Но вот если ридер автоматически не определился в системе, то одной из возможных причин может быть использование устаревших версий ОС или версий Firmware ("прошивок") терминального оборудования. Для устранения проблемы следует прописать указанные VID/PID в Info.plis и/или обратиться с этой проблемой к производителю ОС или терминального оборудования.

Идентификатор класса устройств USB: 0x0B

VID (Vendor ID): 0х24DC

PID (Product ID): 0х0428

Для Astra Linux 1.4, Astra Linux 1.5 и МС ВС 3.0 подсистема поддержки работы со смарт-картами PC/SC и CCID-драйвер перед первым использованием ридера должны быть установлены на рабочую станцию администратором, согласно инструкциям для определённого типа операционных систем. Работа ридера в этих ОС "из коробки" не гарантируется.

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

Итак, производитель заявляет следующий ряд характеристик:

- Климатическое исполнениеустройства: группа 1.1 УХЛ-4

- Температура эксплуатации: +2510С

- Относительная влажность воздуха: от 40% до 60%

- Атмосферное давление: 96 кПа - 103 кПа (720 - 770 мм рт. ст.)

Предельными условиями эксплуатацииявляются параметры:

- Температура: от 0С до +70С, при температуре воздуха выше +30С влажность не должна превышать 70%

- Относительная влажность воздуха: до 80%, без конденсата

- Атмосферное давление: 84 кПа - 106,7 кПа (630 - 800 мм рт. ст.)

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

Ридер безопасен для здоровья человекаи соответствует требованиям Единых санитарно-эпидемиологических и гигиенических требований к товарам, подлежащим санитарно-эпидемиологическому надзору. Сертификат соответствия можно найти на сайте производителя во вкладке "Доп. ресурсы"https://www.aladdin-rd.ru/catalog/readers/JCR-721.

Ридер имеет повышенную защищённость от пробоя статическим электричеством (до 15 киловольт), не оказывает влияния на работу электронного оборудования, чувствительного к электромагнитным излучениям и помехам, имеет повышенную защищённость от воздействия электромагнитных излучений и помех.

Небольшое сравнение ридера JCR721 с ближайшими аналогами

Для сравнения мы выбрали несколько параметров: качество контактной группы и её ресурс, поддержка типов смарт-карт, безопасность и доверие.

Качество контактной группы, её ресурс:

Поддержка различных типов карт:

Безопасность и доверие:

Немаловажно отметить, что цена для ридера адекватна для больших проектов.

Цена взята с сайта рассматриваемых поставщиков в России посостоянию на 14 октября 2020 г.

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

В настоящее время киберпреступность стала проблемой мирового уровня. Например, Дмитрий Самарцев, директор BI.ZONE в сфере кибербезопасности привёл на Всемирном экономическом форуме следующие цифры. В 2018 году ущерб мировой экономики от киберпреступности составил по его словам 1.5 триллиона долларов. В 2022 году прогнозируются потери уже в 8 триллионов, а в 2030 ущерб от киберпреступлений может превысить 90 триллионов долларов. Чтобы уменьшить потери от киберпреступлений, необходимо совершенствовать методы обеспечения безопасности пользователей. В настоящее время существует множество методов аутентификации и авторизации, которые помогают реализовать надежную стратегию безопасности. Среди них многие эксперты выделяют в качестве лучшей авторизацию на основе токенов.

До появления токена авторизации повсеместно использовалась система паролей и серверов. Сейчас эта система всё ещё остаётся актуальной из-за своей простоты и доступности. Используемые традиционные методы гарантируют пользователям возможность получить доступ к их данным в любое время. Это не всегда эффективно.

Рассмотрим эту систему. Как правило, идеология их применения базируется на следующих принципах:

1. Осуществляется генерация аккаунтов, т.е. люди придумывают сочетание букв, цифр или любых известных символов, которые станут логином и паролем.

2. Для осуществления возможности входа на сервер, пользователю требуется сохранять эту уникальную комбинацию и всегда иметь к ней доступ.

3. При необходимость заново подключиться к серверу и авторизироваться под своим аккаунтом, пользователю требуется заново вводить пароль и логин.

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

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

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

Типы токенов авторизации

Токены авторизации различаются по типам. Рассмотрим их:

1. Устройства, которые необходимо подключить физически. Например: ключи, диски и тому подобные. Тот, кто когда-либо использовал USB-устройство или смарт-карту для входа в систему, сталкивался с подключенным токеном.

2. Устройства, которые находятся достаточно близко к серверу, чтобы установить с ним соединение, но оно не подключаются физически. Примером такого типа токенов может служить "magic ring" от компании Microsoft.

3. устройства, которые могут взаимодействовать с сервером на больших расстояниях.

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

Процесс токен авторизации

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

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

Что такое аутентификация на основе токенов?

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

1. аутентификация по паролю (обычное запоминание комбинации символов)

2. аутентификация по биометрии (отпечаток пальца, сканирование сетчатки глаза, FaceID)

3. аутентификация токенов

Аутентификация токенов требует, чтобы пользователи получили сгенерированный компьютером код (или токен), прежде чем им будет предоставлен доступ в сеть. Аутентификация токенов обычно используется в сочетании с аутентификацией паролей для дополнительного уровня безопасности (двухфакторная аутентификация (2FA)). Если злоумышленник успешно реализует атаку грубой силы, чтобы получить пароль, ему придется обойти также уровень аутентификации токенов. Без доступа к токену получить доступ к сети становится труднее. Этот дополнительный уровень отпугивает злоумышленников и может спасти сети от потенциально катастрофических нарушений.

Как токены работают?

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

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

Хотя эти традиционные системы аутентификации токенов все еще действуют сегодня, увеличение количества смартфонов сделал аутентификацию на основе токенов проще, чем когда-либо. Смартфоны теперь могут быть дополнены, чтобы служить генераторами кодов, предоставляя конечным пользователям коды безопасности, необходимые для получения доступа к их сети в любой момент времени. В процессе входа в систему пользователи получают криптографически безопасный одноразовый код доступа, который ограничен по времени 30 или 60 секундами, в зависимости от настроек на стороне сервера. Эти мягкие токены генерируются либо приложением-аутентификатором на устройстве, либо отправляются по запросу через SMS.

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

Безопасно ли использование токенов?

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

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

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

Рекомендации по аутентификации на основе токенов

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

1. Правильный веб-токен. Хотя существует целый ряд веб-токенов, ни один из них не может обеспечить ту же надежность, которую предоставляет веб-токен JSON (JWT). JWT считается открытым стандартом (RFC 7519) для передачи конфиденциальной информации между несколькими сторонами. Обмен информацией осуществляется цифровой подписью с использованием алгоритма или сопряжения открытого и закрытого ключей для обеспечения оптимальной безопасности.

2. Приватность.

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

Что такое JSON веб-токены?

JSON Web Token (JWT) - это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. Эта информация может быть подтверждена благодаря цифровой подписи. JWT может быть подписан с помощью секрета (с помощью алгоритма HMAC) или иным образом, например, по схемам RSA или ECDSA.

В своей компактной форме веб-токены JSON состоят из трех частей, разделенных точками: заголовок, полезная нагрузка, подпись. Поэтому JWT выглядит обычно выглядит следующим образом: xxxx.yyyy.zzzz.

Заголовок состоит из двух частей: типа токена, которым является JWT, и используемого алгоритма подписи, такого как HMAC SHA256 или RSA.

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

Зарегистрированная - это набор ключей, который не является обязательными, но рекомендуются для обеспечения улучшения безопасности. Например, iss - уникальный идентификатор стороны, генерирующей токен, exp - время в формате Unix Time, определяющее момент, когда токен станет не валидным, и другие.

Публичная информация может быть определена по желанию теми, кто использует JWT. Но они должны быть определены в реестре веб-токенов IANA JSON или определены как URI, который содержит устойчивое к коллизиям пространство имен. Частная - это пользовательская информация, созданная для обмена данными между сторонами, которые согласны их использовать. Получим вторую часть с помощью кодирования Base64Url.

Тоже не понял, что за прикол там происходит.

Подпись же используется для проверки того, что сообщение не было изменено по пути, а в случае токенов, подписанных закрытым ключом, она также может подтвердить, что отправитель JWT тот, за себя выдает.

Выходные данные представляют собой три строки Base64-URL, разделенные точками, которые могут быть легко переданы в средах HTML и HTTP, будучи при этом более компактными по сравнению со стандартами на основе XML, такими как SAML.

Пример:

eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJKb2huIEdvbGQiLCJhZG1pbiI6dHJ1ZX0K.LIHjWCBORSWMEibq-tnT8ue_deUqZx1K0XxCOXZRrBI

К плюсам использования JWT можно отнести размер - токены в этом языке кода крошечные и могут быть переданы между двумя пользователями довольно быстро; простоту - токены могут быть сгенерированы практически из любого места, и их не нужно проверять на сервере; контроль - можно указать, к чему пользователь может получить доступ, как долго будет длиться это разрешение и что он может делать во время входа в систему.

К минусам стоит отнести всего один ключ - JWT полагается на один ключ, из-за чего вся система окажется под угрозой в случае, если он будет скомпрометирован; сложность - JWT токены не так просто понять, из-за чего, разработчик, не обладающий глубокими знаниями алгоритмов криптографической подписи, может непреднамеренно поставить систему под угрозу; ограничения - нет возможности отправлять сообщения всем клиентам, и невозможно управлять клиентами со стороны сервера.

Почему стоит использовать токены авторизации?

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

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

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

Токены авторизации могут обеспечить повышенную безопасность. Сервер содержит конфиденциальные документы, которые могут нанести компании или стране серьезный ущерб при выпуске. Простой пароль не может обеспечить достаточную защиту.

Есть и другие преимущества использования этой технологии. Но даже уже перечисленных достаточно, чтобы внедрить её на сервера.

Всем привет! Меня зовут Наталья Бессонова, я директор проектов блока цифровой идентичности Ростелеком. В этой статье хочу рассказать о том, как мы выбирали пассивный лайвнесс по одному изображению лица для Единой биометрической системы.

На Хабре не так много статей, посвященных лайвнесс в биометрических системах, а те, что есть, описывают методы и алгоритмы определения лайвнесс или, проще говоря, принадлежности биометрических образцов живому человеку. Отдадим должное их авторам статьи интересные и содержательные, но что если нас интересует насколько хорошо они работают на данных, не входящих ни в один из открытых дата-сетов? Как понять, насколько лайвнесс действительно плох или хорош и какой следует выбирать при необходимости? В этой статье я опишу подход к выбору пассивного singleshot-лайвнесс (т.е. по одному изображению) лица для Единой биометрической системы.

Зачем нужен лайвнесс

Существует мнение, что для обмана любой биометрической системы достаточно украсть биометрический образец (изображение лица, запись голоса). Именно для обнаружения и пресечения таких попыток атак на биометрическое предъявление и предназначен лайвнесс. Чтобы лучше понять, что именно в теме лайвнесс беспокоит людей, давайте прочитаем комментарии к смежным статьям (орфография авторов сохранена, ниже указаны ссылки на статьи):

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

Удалённая банковская идентификация: от сложного к простому, или Банки, зачем вам биометрия?

Мнение автора основано на устаревшей информации. Конкурс Deepfake Detection Challenge по распознаванию дипфейков на видео действительно существует, он проводится компаниями Amazon, Facebook и Microsoft. В этом году отечественная компания NtechLab заняла третье место среди более 2,2 тысячи команд со всего мира.

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

Ну и да. Уж что-что а социальная инженерия с биометрией упростится просто в разы. Про пин код с карты ещё хоть как-то можно объяснить, что никому не показывать, а вот биометрия Ну откуда бабульки (или даже мне) знать для каких целей меня сейчас снимают: чтобы подтвердить мою личность или чтобы украсть?

Как защитить биометрические данные пользователей от криминального использования

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

Я вообще, в принципе говорю, что биометрия туфта, немного долее дорогая в обслуживании и легко преодолимая при наличии достаточных средств и мотивации. Защита от чуть более продвинутого дурака.

Новый метод биометрии: биоакустическая подпись

Да, взломать можно любую систему, однако для этого должна быть сопоставимая материальная выгода. Для изготовления качественного инструмента атаки необходимы большие ресурсы.

Биометрия по лицу, работающая с обычной веб-камеры крайне ненадежна и легко обманывается фоткой. Нормальные лицевые биометрии включают в себя дополнительные средства определения фейков: ИК, 3D и так далее.

Как Сбербанк собирает согласие на обработку биометрии

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

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

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

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

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

Делай по ГОСТу

В июле 2020 года в России введена в действие серия стандартов 58624, устанавливающая термины, классификацию и детальное описание атак на биометрическое предъявление для последующего определения эксплуатационных характеристик. До этого времени не было стандартного руководства для объективной и сопоставимой оценки лайвнесс. Стандарты описывают испытания, объектом которых могут являться:

• подсистема лайвнесс;

• подсистема сбора биометрических данных;

• биометрическая система полностью (контроль качества, распознавание и лайвнесс).

В нашем случае мы поговорим об испытаниях лайвнесс и измерении его способности правильно классифицировать атаки и подлинные предъявления. Для лайвнесс определяют метрики, включающие вероятности ошибок классификации, вероятности отсутствия ответа и метрики производительности. Подробное их описание и расчет можно прочитать в ГОСТ Р 58624.3, мы же приведем их интерпретацию:

• вероятность ошибки классификации предъявления при атаке вычисляют как долю атак, ошибочно классифицируемых как живые люди;

• вероятность ошибки классификации подлинных биометрических предъявлений вычисляют как долю живых людей, классифицируемых как атаки; вероятность отсутствия ответа на предъявление артефакта (ВООПА) вычисляют как долю атаки, на которую лайвнесс не ответил. ВООПА рассчитывается отдельно для каждого инструмента атаки;

• вероятность отсутствия ответа на подлинное биометрическое предъявление вычисляют как долю подлинных предъявлений, на которую лайвнесс не ответил;

• длительность обработки подсистемой обнаружения атаки на биометрическое предъявление вычисляют как время, необходимое лайвнесс для классификации.

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

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

У нас был сервер, пять веб-камер, один смартфон и пять сотен фотографий

Для испытаний лайвнесс необходимо использовать базу данных, включающую определенное множество типов атак с использованием репрезентативного набора инструментов атак и репрезентативного набора подлинных субъектов.

В соответствии с требованиями FIDO Biometrics существует три уровня атак, различающихся главным образом усилиями, необходимыми для создания инструмента атаки. Уровень А включает в себя простые распечатки фотографий или фотографии, представленные на дисплее, в то время как уровень В дополнительно включает бумажные маски или видео человека. Уровень С представляет собой силиконовые маски или высококачественные видеозаписи человека, представленные, например, на дисплее с высоким разрешением.

Для наших испытаний мы выбрали следующие инструменты атак:

• фотографию лица предъявление распечатанной на цветном принтере фотографии высокого разрешения;

• 2D-маску предъявление распечатанной на цветном принтере фотографии высокого разрешения с обрезанным фоном;

• модифицированную фотографию лица предъявление распечатанной на цветном принтере фотографии высокого разрешения с вырезанными отверстиями под рот, нос, глаза;

• изображение лица на дисплее предъявление выводимой на дисплее фотографии;

• 3D-маску предъявление силиконовой маски или маски, распечатанной на 3D-принтере.

Отметим, что каждый метод лайвнесс специализируется на разных инструментах атак. Например, для пассивного singleshot-лайвнесс атака с использованием deepfake не является актуальной, так как для работы такого лайвнесс используется только одно изображение, а не видео, что делает достаточным использование одной фотографии лица для попытки атаки.

На фото внизу представлен стенд по сбору базы на примере атаки с использованием фотографии лица.

Полученная база данных состоит из не менее 300 образцов на каждый инструмент атаки (за исключением силиконовых масок), что дает минимальную достоверную вероятность 1%. Для сбора образцов использовались несколько веб-камер и мобильный телефон:

• Logitech C270;

• Logitech C930;

• Logitech B920;

• Logitech Brio;

• Intel Realsense D415;

• Xiaomi Redmi6.

Также необходимо отметить, что для создания инструментов атак использовались только фотографии, сделанные при сотрудничестве пользователя, так как качество этих изображений достаточно высокое.

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

Спецификация сервера, на котором проходили испытания:

1) CPU - Intel(R) Core(TM) i5-6600 CPU (4 ядра, 3.30 ГГц, AVX и AVX2 поддерживаются);
2) GPU - Nvidia GeForce GTX 1070 (8 ГБ видеопамяти);
3) ОЗУ - 16 ГБ DDR4;
4) ПЗУ - SSD накопитель SAMSUNG 970 EVO 500ГБ.

Результаты

Я провела испытания 12 методов лайвнесс от независимых вендоров. Все методы, кроме одного, являются пассивными singleshot-методами, для их работы на вход API подаётся RGB изображение лица, на выходе получается liveness score, отражающий насколько предъявленное изображение похоже на подлинное предъявление лица. Один из методов основан на применении 3D-камеры Intel RealSense D415 и, соответственно, на вход принимает RGB изображение и карту глубины изображаемой сцены, а на выходе отдаёт всё тот же liveness score. В таблице ниже приведен перечень измеренных значений эксплуатационных характеристик каждого из протестированных методов лайвнесс.

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

Также интересно взглянуть на распределение ошибок по инструментам атаки для лучшего решения. Как видно на следующем рисунке, большая часть кривых выглядит как ступенька. Это связано с тем, что метод справился с классификацией с минимальной достоверно измеряемой ошибкой. Например, для случая с силиконовыми масками, где в нашем тесте было минимальное количество образцов атаки, оценка ВОКПА составила 9% и сказать, что действительное значение ВОКПА меньше, мы не можем, для уточнения её значения требуется больше примеров.

Что делать дальше

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

• увеличить количество образцов для каждого вида атаки;

• собрать базы данных для оценки методов лайвнесс для конкретных приложений или продуктов;

• собрать базы данных для оценки конкретных методов лайвнесс.

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

Буду рада ответить на вопросы в комментариях, если они у вас есть.

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

Прежде чем мы расскажем о крестражах как об элементе безопасности, давайте вспомним наиболее важные правила безопасности в интернете. Если этот раздел вам неинтересен, можете пролистнуть страницу до крестражей.

Правила интернет-безопасности

1. Длинный пароль лучше короткого. Если длина пароля составляет 16 символов, его почти невозможно подобрать. => cutesamantha15101995 > cutesamantha

2. Случайные пароли лучше, чем пароли, позволяющие идентифицировать владельца пароля.=> process-cancel-stingy-garnet > cutesamantha15101995

Примечание: технически кодовая фраза process-cancel-stingy-garnet отлично может использоваться в качестве пароля. Она длинная и легко запоминается. В отличие от, скажем, B6fSpxMj&f6DU@5^k длинного сложного пароля из случайных символов.

3. Иметь принципиально разные пароли для разных учётных записей.

Один и тот же пароль для разных учётных записей это всё равно, что один и тот же ключ для разных замков. Ведь вся суть нескольких замков в том, что они _разные_! Кроме того, если использовать несколько паролей, отличающихся одним словом, которое легко угадать (например, ниже), то вы сильно рискуете. Пароли должны отличаться. Например:

bounce-unfold-stunning-chute        process-cancel-stingy-facebooksymptom-untouched-unpaid-arena  >   process-cancel-stingy-twittersediment-tweak-annually-koala       process-cancel-stingy-gmail

4.По возможности используйте двухфакторную / многофакторную аутентификацию.

Google, Facebook и многие другие сайты предлагают функцию двухфакторной аутентификации, когда второй фактор требуется только при входе в систему с нового устройства или из нового местоположения. Каждый раз вводить проверочный код не требуется. Это редкое сочетание удобства и безопасности!

Примечание: рекомендую использовать andOTP (или любые другие приложения на основе TOTP), поскольку его нельзя подделать или подсмотреть на заблокированном экране, как SMS OTP, и для него не требуется мобильная сеть или подключение к интернету. Вы также можете использовать биометрию (отпечаток пальца или распознавание лица).

Ух. Насколько реально вообще использовать длинный пароль для несметного количества сайтов, чтобы все они существенно отличались друг от друга, и при этом помнить каждый? Безопасность способна обеспечить серьёзную головную боль!

[Enter] Менеджер паролей

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

Они с легкостью включают все вышеперечисленные меры для надежной онлайн-безопасности. Я согласен, чтобы настроить менеджер паролей впервые, потребуются определённые усилия. Но после этого он вы просто бездумно пользуетесь им.

Например, генератор паролей BitWardenпозволяет создать случайный пароль с разными характеристиками.

Ура, я в безопасности!

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

Что, если:

• Ваш главный пароль (пароль к вашему менеджеру паролей) скомпрометирован из-за нарушения безопасности или вы оставили его в виде открытого текста письме, заметках или другом приложении?

• Кто-то на время получил доступ к вашей разблокированной системе (компьютеру или телефону), когда вы отошли, а ваш менеджер паролей был запущен, и его содержимое можно было посмотреть?

Ответ: тыоблажался.

Когда кладёшь все яйца в одну корзину, то рискуешь, что все они могут уйти в небытие одним махом.И что тогда делать?

Пароли как крестраж

Несмотря на все злодеяния, Волан-де-Морт сделал одно хорошее дело для нас, маглов. Он рассказал всему миру про концепцию крестража. Для непосвящённых: крестраж это любой объект, в котором вы храните частичку своей души, складывая пресловутые яйца своей души в разные корзины, чтобы получить квази-бессмертие.

Основная идея: вы разделяете свой пароль на 2 части. Одна хранится в менеджере паролей, а другая в вашей голове (которую можно назвать крестраж).

По сути, в любой момент времени вы и ваш менеджер паролей знаете только часть пароля. Это и есть двойной скрытый пароль. Фактически, как и Сами-Знаете-Кто, вы разбиваете свой пароль (душу) на части и храните их в разных местах.

До:

#Как хранится в диспетчере паролейЛогин: rickПароль: rollthepeople1732#Фактически выглядитЛогин: rickПароль: rollthepeople1732

Теперь:

#Как хранится в диспетчере паролей Логин: rickpassword: roll-the-people-venus#Как хранится в вашей головеКрестраж: papel#Фактически выглядит Логин: rickПароль: roll-the-people-venuspapel

Крестраж добавляет дополнительный уровень безопасности, разблокировать который можете только вы. Это своего рода двухфакторная аутентификация. Опять же, чем длиннее крестраж, тем лучше. Но простое слово тоже подойдет, если крестраж известен только вам.

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

Последний момент

Безопасность никогда не бывает абсолютной. Можно попытаться защитить систему настолько, насколько это в принципе возможно. Но не стоит говорить, что она полностью безопасна (если вы видите, что кто-то утверждает обратное, то это обычно означает, что он пускает пыль в глаза). Если мы не можем сделать систему полностью безопасной, лучше всего сделать её как можно более безопасными. И хороший способ добиться этого: Глубокая защита. Убедитесь, что даже если один уровень безопасности будет нарушен, существуют другие. Создание многослойной защиты для смягчения возможного ущерба - это то, чего пытаются добиться многие специалисты по информационной безопасности.

Резюмируем

1. Используйте хороший менеджер паролей.

2. Используйте TOTP/биометрию вместо OTP на основе SMS.

3. Используйте крестраж для наиболее важных учёток.

P.S. Имейте в виду, что крестражирование работает нормально только до тех пор, пока вы не подключите свой мозг к NeuraLink и случайно не загрузите свои мысли в интернет, где все смогут их увидеть ;).

Что ещё интересного есть в блогеCloud4Y

В Китае создали настольный квантовый компьютер стоимостью $5000

Тим Бернерс-Ли предлагает хранить персональные данные в подах

Виртуальные машины и тест Гилева

Создание группы доступности AlwaysON на основе кластера Failover

Как настроить SSH-Jump Server

Подписывайтесь на нашTelegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Когда я нашёл эту уязвимость и сообщил о ней, она стала моим первым оплаченным баг-репортом на HackerOne. $35,000 это также самая высокая награда, которую я получил от HackerOne (и я считаю, что самая высокая оплата от GitHub на сегодня). Многие найденные ошибки, кажется, это удача и интуиция, вместе взятые. В этом посте я расскажу, как мыслил, приближаясь к цели.

Как началась история

Ковид ударил весной, в первый год старшей школы. От нечего делать между онлайн-занятиями я начал охоту за багами. Конкретно эта награда была за сообщение об уязвимости приватных страниц Github в рамках программы Баг Баунти. В частности, было и два бонуса CTF (capture the flag состязание по типу захвата флага, здесь в информационной безопасности):

• $10000 чтение флага flag.private-org.github.io без взаимодействия с пользователем. Бонус в $5000 за то, что флаг читается с аккаунта внутри приватной организации.

• $5000: чтение флага flag.private-org.github.io через взаимодействие с пользователем.

Поток аутентификации

Страницы GitHub размещаются в отдельном домене github.io, поэтому куки-файлы аутентификации github.com не отправляются на сервер приватных страниц. Таким образом, аутентификация частной страницы не имеет возможности определить личность пользователя без дополнительной интеграции с github.com, поэтому GitHub создал собственный поток аутентификации. И ввёл возможность существования багов. На момент отчёта этот поток выглядел так:

А теперь подробнее.

При посещении приватной страницы сервер проверяет, существует ли файл куки __Host-gh_pages_token. Если этот файл не установлен или установлен неправильно, сервер приватной страницы перенаправит на https://github.com/login. Этот начальный редирект также устанавливает nonce, который хранится в куки __Host-gh_pages_session.

Обратите внимание, что этот куки использует префикс куки __Host-, который, в теории, в качестве дополнительной защиты в глубину, предотвращает его установку из JS с родительского домена.

/login перенаправляет на /pages/auth?nonce=&page_id=&path=. Затем эта конечная точка генерирует временный куки-файл аутентификации, который она передаёт https://pages-auth.github.com/redirect в параметре token; nonce, page_id, и path присылаются аналогично.

/redirect просто перенаправляет на https://repo.org.github.io/__/auth. Эта последняя конечная точка затем устанавливает куки аутентификации для домена repo.org.github.io, __Host-gh_pages_token и __Host-gh_pages_id. Также вместе с ранее установленным __Host-gh_pages_session на валидность проверяется nonce.

На протяжении всего потока аутентификации такая информация, как исходный путь запроса и идентификатор страницы, хранится в параметрах запроса path и page_id соответственно. Nonce также передаётся в параметре nonce. Хотя поток аутентификации, возможно, немного изменился (отчасти из-за этого отчёта), общая идея остаётся прежней.

Эксплоит

CRLF возвращается

Первая уязвимость CRLF-инъекция в параметре page_id запроса https://repo.org.github.io/__/auth.

Возможно, лучший способ найти уязвимые места поиграть. Исследуя поток аутентификации, я заметил, что парсинг page_id, похоже, игнорировал пробельные символы. Интересно, что он также рендерил параметр непосредственно в заголовок Set-Cookie. К примеру, page_id=12345%20 вернул это:

Set-Cookie: __Host-gh_pages_id=12345 ; Secure; HttpOnly; path=/

Псевдокод предположительно такой:

page_id = query.page_iddo_page_lookup(to_int(page_id))set_page_id_cookie(page_id)

Другими словами, page_id преобразуется в целое число, а также отображается напрямую в заголовок Set-Cookie. Проблема была в том, что мы не можем отобразить текст напрямую. Несмотря на то, что у нас была классическая CRLF-инъекция, размещение любых непробельных символов привело к поломке парсинга целого. Мы могли бы прервать поток аутентификации, отправив page_id=12345%0d%0a%0d%0a, но, кроме интересного ответа, никакого немедленного воздействия не было.

; Secure; HttpOnly; path=/Cache-Control: privateLocation: https://83e02b43.near-dimension.github.io/X-GLB-L

Дополнительное примечание: заголовок Location: был добавлен после заголовка Set-Cookie, поэтому наш ответ Location выталкивает за пределы отправленных HTTP-заголовков. Это редирект на 302, но, несмотря на это, заголовок Location игнорируется и отображается содержимое тела.

Из грязи в князи

Немного просмотрев на GitHub Enterprise (который дал доступ к исходному коду), я заподозрил, что сервер приватных страниц реализован на Nginx OpenResty. Будучи относительно низкоуровневым, возможно, он имел проблемы с нулевыми байтами. А попытка не пытка, правильно?

Оказалось, что добавление нулевого байта прерывает парсинг целого. Другими словами, можно передать такую полезную нагрузку:

"?page_id=" + encodeURIComponent("\r\n\r\n\x00<script>alert(origin)</script>")

А вот и XSS!

Обратите внимание, что, если в заголовке есть нулевой байт, ответ будет отклонён. Таким образом, нулевой байт должен прийти в начале тела (это означает, что мы не можем выполнить атаку через инъекцию в заголовок).

Мы добились выполнения произвольного JavaScript на странице приватного домена. Единственная проблема нужен способ обойти nonce. Параметры page_id и path известны, а nonce не позволяет нам отправлять жертв вниз по потоку аутентификации с отравленным page_id. Нам нужно либо зафиксировать, либо спрогнозировать nonce.

Обходим nonce

Первое наблюдение поддомены одной организации могут устанавливать куки-файлы друг на друга. Так происходит потому, что *.github.io нет в публичном списке суффиксов. Таким образом установленные на private-org.github.io куки передаются на private-page.private-org.github.io.

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

Ну, ладно... неправильно говорить не во всех. Похоже, в смысле этого обхода уязвим только IE. Придётся постараться. А что, если атаковать сам nonce? генерация выглядит надёжной, и, если честно, криптография не моя сильная сторона. Найти обход применяемой в nonce энтропии, несмотря ни на что, это казалось маловероятным. Как же тогда зафиксировать nonce?

Вернёмся к истокам RFC. В конце концов, я наткнулся на интересную идею как нормализовать куки? В частности, как следует обращаться с куки с учётом верхнего регистра. "__HOST-" это то же самое, что "__Host-"? Легко убедиться, что в браузерах с куками разного регистра обращаются по-разному:

document.cookie = "__HOST-Test=1"; // worksdocument.cookie = "__Host-Test=1"; // fails

Оказывается, сервер приватных страниц GitHub при разборе куки-файлов игнорирует заглавные буквы. И у нас есть префиксный обход. А теперь собираем доказательство концепции атаки XSS!

<script>const id = location.search.substring("?id=".length)document.cookie = "__HOST-gh_pages_session=dea8c624-468f-4c5b-a4e6-9a32fe6b9b15; domain=.private-org.github.io";location = "https://github.com/pages/auth?nonce=dea8c624-468f-4c5b-a4e6-9a32fe6b9b15&page_id=" + id + "%0d%0a%0d%0a%00<script>alert(origin)%3c%2fscript>&path=Lw";</script>

Уже этого достаточно, чтобы заработать бонус в $5000. Но я хотел посмотреть, получится ли продвинуться дальше.

Отравление кэша

И вот ещё один недостаток дизайна выяснилось, что в ответ на конечную точку /__/auth? кэшировалось только целое значение page_id. Само по себе это безвредно: установленный этой конечной точкой токен скопирован на личную страницу и не имеет никаких других привилегий.

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

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

Злоумышленник контролирует unprivileged.org.github.io и хочет добраться до privileged.org.github.io. Он атакует поток аутентификации unprivileged.org.github.io и полезная нагрузка XSS кэшируется.

Когда привилегированный пользователь посещает unprivileged.org.github.io, он подвергается XSS атаке на домен unprivileged.org.github.io. Куки могут устанавливаться на общем родительском домене org.github.io, поэтому теперь злоумышленник может атаковать privileged.org.github.io.

Эти действия позволяют любому злоумышленнику с разрешениями на чтение приватной страницы постоянно атаковать поток аутентификации этой страницы. Ё-моё!

Публичные и приватные страницы

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

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

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

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

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

Так мы заработали максимальный бонус CTF. Устойчивость достигается отравлением кэша или другим техниками, которые мы оставим читателям в качестве упражнения.

Заключение

Этой уязвимости присвоили высокий приоритет, базовая выплата составила 20 000 долларов, а с бонусом CTF мы заработали 35 000 долларов. Довольно круто, что такая относительно малоизвестная уязвимость, как инъекция CRLF, обнаружилась на GitHub. Хотя большая часть кода написана на Ruby, некоторые компоненты, такие как аутентификация приватной страницы, написаны не на этом языке и могут быть уязвимы к низкоуровневым атакам. В общем, везде, где есть сложные взаимодействия, ошибки только ждут, чтобы мы их нашли.

Обнаруженная уязвимость кажется одной на миллион. Это как продеть нитку в иголку должен выстроиться целый ряд событий. В то же время, думаю, чтобы найти нечто подобное, требуется в меру развитая интуиция и навыки, которые как раз можно получить на курсе Этичный хакер.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

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

Меня зовут Роман Литвинов, я разработчик в команде Учи.ру. Хочу вам рассказать именно о такой истории из практики и о нашем сервисе под названием Butler, о дворецком, через которого проходит каждый пользователь, прежде чем зайти на платформу.

Итак, овсянка, сэр.

По мере роста популярности платформы система аутентификации перестала соответствовать нашим требованиям, как и некоторые другие части нашей архитектуры. Когда весной 2020 года в базе Учи.ру стало больше 11 млн активных пользователей (8 млн учеников, примерно 350 тыс. учителей и около 3,5 млн родителей), существующая реализация стала медленной, непрозрачной и потребляла слишком много памяти. Мы решили ее обновить.

Поставили перед собой следующие цели:

• повысить производительность;

• внедрить новые технологии защиты учетных данных;

• выделить аутентификацию из монолита в микросервис;

• подключить мобильное приложение.

При этом хотелось иметь возможность поддерживать функции, которые до этого не реализовывались.

В список новых функций попали:

• принудительное отключение пользователя;

• блокировка аккаунта;

• верификация;

• шифрование паролей учеников;

• поддержка jwt-токенов и двухфакторной аутентификации;

• интеграция с социальными сетями;

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

Сложности работы с таблицами. Роли пользователей

Долгая аутентификация

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

Проблема уникальности почты и логина

Если родитель одновременно является учителем и хочет зарегистрироваться на Учи.ру, он должен завести две учетные записи. Это значит, что его e-mail будет числиться в двух разных таблицах. Та же история может происходить, если один человек является и сотрудником, и родителем или и сотрудником, и учителем и т. д. Если e-mail один, то сложно определить, какого именно пользователя нужно аутентифицировать.

Чтобы упростить процесс начала работы с системой, детям из одного класса выдают общий логин, привязанный к номеру школы. То есть у ребят в одной школе отличаются только пароли.

Теперь мы используем Butler

Чтобы исправить ситуацию, мы решили вынести аутентификацию в отдельный сервис. Для этого был создан Butler. Саму аутентификацию было решено проводить на базе открытой библиотеки Ruby под названием rodauth. Ее, конечно, пришлось немного доработать, но в целом решение подходило. Параллельно с улучшением своего продукта мы внесли небольшой вклад в развитие open source-сообщества.

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

Всех пользователей перенесли из нескольких таблиц в единую базу данных. Принадлежность к разным таблицам в прошлом позволила определить роли и записать их в отдельный столбец.

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

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

Небольшой тюнинг решения

Конечно, нам пришлось изменить настройки окружения. Например, для web-версии системы срок действия токена был выставлен небольшим около 30 минут. Потому что иначе, если ученик забудет разлогиниться на компьютере в школе, то его учетной записью может воспользоваться кто-то из другого класса на следующих уроках.

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

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

Обновление камень преткновения

Обновлять исходный код open-source компонента нужно аккуратно, потому что в открытых проектах вопросы обратной совместимости не всегда оказываются решены полностью. Так, нам нужно было установить обновление, которое требовалось для внедрения очередной фичи. Но с этим обновлением возникал обязательный параметр связи между access-токеном и refresh-токеном. Раньше он был необязательным и от нашего внимания ускользнул. Это значит, что все выданные токены перестали бы работать разом, если бы мы накатили это обновление. То есть, если бы мы сразу обновили всю систему, это привело бы к сбросу всех активных сессий.

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

Криптография и защита от брутинга

Хранить логины и пароли в новой базе данных было решено в зашифрованном виде. Тогда дополнительным тормозом стал один из наиболее используемых алгоритмов в экосистеме Ruby BCrypt.

Его реализация на Ruby отнимала слишком много процессорного времени, затрачивая 250 мс на создание хеша со стандартным костом, равным 12. Зачастую подобную операцию необходимо проводить дважды в течение цикла вопрос-ответ, поскольку требуется проверка на использование этого же пароля пользователем прежде. Вкупе со множественным использованием колбеков в монолите ситуация стала приводить к большому времени ожидания внутри транзакций БД (idle in transaction), что начало сказываться на производительности системы. На этих самых колбеках висело слишком много бизнес-логики, что не позволило свести проблему к простому рефакторингу.

Выходом из положения стала смена алгоритма шифрования на более гибкий, который поддерживает конфигурацию как по затрачиваемой памяти, так и временному ресурсу. Мы взяли открытый алгоритм Argon2 и постепенно мигрировали пользователей с одного на второй, благо в rodauth имелись зачатки функционала для осуществления плавного перехода. Для этого потребовалось внести изменения в саму библиотеку rodauth. К счастью, Jeremy Evans ее автор оказался очень открытым человеком, пошел нам навстречу.

В сервисе rodauth также нашлось встроенное решение по защите от брутинга паролей. После определенного количества попыток аккаунт блокируется на некоторое время. Разблокировку можно провести за счет подтверждения через e-mail или вручную.

Перенос аккаунтов

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

В процессе миграции были обнаружены множественные записи с грязными данными, которые содержат повторы и не соответствуют RFC. Например, пользователи ошибались при введении почты или делали это намеренно.

Важным пунктом миграции стала необходимость не завершать активные сессии пользователей и не менять данные их учетных записей, то есть пароли нельзя было сбрасывать. К счастью, зная salt и cost-factor, можно просто перенести хеш без потери функциональности.

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

Результаты

В итоге нам удалось оторвать от монолита кусочек, снизив его требования к производительности, и запустить современный сервис аутентификации. Разработчикам теперь стало немного сложнее: они не могут просто загрузить себе копию монолита и проверять свои гипотезы. Теперь вместе с монолитом нужно запускать Butler, чтобы хотя бы первый раз пройти аутентификацию. Но я уверен, что все мы к этому легко привыкнем.

Главный плюс же в том, что мы получили внимательного дворецкого: полноценный быстрый и безопасный сервис аутентификации с единой точкой входа. При этом он так же работает на базе Ruby, как и основная часть системы Учи.ру. Теперь процессы аутентификации происходят быстрее в десятки раз, а памяти нужно на это примерно в 5 раз меньше, чем раньше.

К старту курса о разработке на Java делимся переводом вводной статьи о Quarkus "родной" для Kubernetes Java-платформе для создания высокопроизводительных веб-, бессерверных (serverless) и нативных приложений (оптимизированных для используемых микропроцессоров). В ней используются предварительная компиляция AOT и агрессивная оптимизация, например сканирование путей к классам, перезагрузка конфигурации и предварительная конфигурация самозагрузки приложения в процессе сборки. Результатом становится впечатляющая скорость загрузки. Другими словами, приложения, созданные с Quarkus, запускаются не просто быстро, а очень быстро!

Так же как для платформ Spring и Micronaut, в Quarkus можно использовать преимущество GraalVM для преобразования JVM-приложений в нативные исполняемые файлы, что ещё больше повышает их быстродействие.

Такой прирост производительности позволяет этой Java-платформе конкурировать с бессерверными, облачными и созданными на основе Kubernetes средами, создавая приложения Supersonic Subatomic Java. В Quarkus используются стандарты Java (такие, как MicroProfile, JAX-RS), а также лучшие из существующих Java-библиотек (например, Hibernate и Vert.x). Есть даже поддержка аннотаций Spring.

Quarkus + JHipster = простое ускорение Java

История технологий разработки наглядно демонстрирует, что совместить различные компоненты бывает очень непросто. Разработчики любят, когда им предлагается что-то авторитетно-одобренное, и как раз здесь на сцену выходит JHipster.

JHipster это сопровождаемая сообществом разработчиков полнофункциональная платформа разработки, позволяющая создавать, развивать и развёртывать веб-приложения и ориентированные на микросервисы архитектуры. Стандартной серверной платформой в JHipster является Spring Boot, но постоянно появляются всё новые и новые возможности. Одним из таких вариантов стала blueprint-схема JHipster Quarkus.

Помимо прочего, одной из ключевых возможностей, определяющих успех JHipster, стала его расширяемость с помощью blueprint-схем. Blueprint-схема действует как плагин JHipster и позволяет вам переопределять стандартное поведение, настраивая его на свой вкус.

Например, blueprint-схема Kotlin с JHipster является популярным дополнением, которое любят использовать разработчики. Использование blueprint-схемам многократно расширяет границы возможностей. Вот почему в JHipster есть даже реализации без Java (такие, как Node + NestJS и .NET Core). Эта публикация познакомит вас с основными шагами по использованию JHipster, blueprint-схемой Quarkus, а также протоколом OAuth для создания оптимизированного для работы на конкретных микропроцессорах и безопасного полнофункционального приложения.

Создание Java-приложения с Quarkus

Прежде чем приступить к работе, необходимо установить несколько инструментов.

Предварительные требования:

• Java 11+;

• Node.js 12+;

• Docker;

• Okta CLI 0.8.0+.

Установите JHipster и его blueprint-схему Quarkus, используя npm:

# Install JHipster globallynpm install -g generator-jhipster@6.10.5# Install the JHipster Quarkus blueprintnpm install -g generator-jhipster-quarkus@1.1.1

Команда jhipster-quarkus сокращение для jhipster --blueprints quarkus. Посмотреть все варианты её синтаксиса можно с помощью команды --help.

$ jhipster-quarkus --help

Создание приложения в среде JHipster Quarkus

mkdir okta-jhipster-quarkus-example && cd okta-jhipster-quarkus-example# oh-my-zsh users: take okta-jhipster-quarkus-example

Чтобы запустить мастер создания приложений, можно выполнить команду jhipster-quarkus:

jhipster-quarkus

В этой вводной статье основным вопросом будет выполнение аутентификации.

Среда JHipster Quarkus позволяет использовать JWT (с возможностью управления пользователями в базе данных приложений) или аутентификацию OAuth 2.0/OIDC с применением поставщиков идентификационной информации, таких как Keycloak и Okta. OIDC расшифровывается как OpenID Connect, этот протокол представляет собой тонкий слой поверх протокола аутентификации OAuth 2.0. Его основная задача обеспечить аутентификацию и идентификацию пользователя.

Ниже представлен пример ответов на вопросы мастера создания приложений.

После того как вы ответите на все эти вопросы, JHipster создаст код вашего приложения и выполнит команду npm install.

{  "generator-jhipster": {    "promptValues": {      "packageName": "com.mycompany.myapp",      "nativeLanguage": "en"    },    "jhipsterVersion": "6.10.5",    "applicationType": "monolith",    "baseName": "jhipster",    "packageName": "com.mycompany.myapp",    "packageFolder": "com/mycompany/myapp",    "serverPort": "8080",    "authenticationType": "oauth2",    "cacheProvider": "no",    "enableHibernateCache": true,    "websocket": false,    "databaseType": "sql",    "devDatabaseType": "h2Disk",    "prodDatabaseType": "mysql",    "messageBroker": false,    "buildTool": "maven",    "embeddableLaunchScript": false,    "useSass": true,    "clientPackageManager": "npm",    "clientFramework": "angularX",    "clientTheme": "none",    "clientThemeVariant": "",    "creationTimestamp": 1614834465776,    "jhiPrefix": "jhi",    "entitySuffix": "",    "dtoSuffix": "DTO",    "otherModules": [      {        "name": "generator-jhipster-quarkus",        "version": "1.1.1"      }    ],    "enableTranslation": true,    "nativeLanguage": "en",    "languages": ["en"],    "blueprints": [      {        "name": "generator-jhipster-quarkus",        "version": "1.1.1"      }    ]  }}

В этом файле содержатся все ответы на исходные вопросы мастера JHipster, что позволит создать приложение без дополнительных запросов.

Убедитесь, что выполняемая с помощью Keycloak аутентификация OAuth 2.0/OIDC действительно работает

Помимо прочих файлов JHipster Quarkus создаёт файлы для инструментального средства Docker Compose, помогающие загрузить среду разработки, настроенную для вашего только что созданного приложения. При этом даже выполняется импорт данных Keycloak, заданных по умолчанию для пользователей и приложений, и вам не придётся делать это самим.

https://gitlab.webant.ru/russia_quiz/frontend/-/merge_requests

Если Keycloak запущен и работает, вы сможете выполнить вход в систему. Запустите ваше приложение с помощью Maven:

./mvnw

Вы можете видеть, что приложение запускается за 3,351 с, также выводится обширный список расширений Quarkus (включая oidc). Перейдите по адресу http://localhost:8080 в предпочитаемом вами браузере и нажмите ссылку sign in (вход).

Вы будете перенаправлены в Keycloak для входа в систему. При запросе идентификационных данных введите admin/admin.

После успешного прохождения аутентификации вы будете перенаправлены обратно в ваше приложение Quarkus.

Как работает поддержка протокола аутентификации OAuth 2.0 в JHipster Quarkus

Одной из проблем при разработке blueprint-схем JHipster, таких как Quarkus, является необходимость найти правильный баланс между повторным использованием существующих механизмов и добавлением индивидуальных реализаций.

С самого первого дня своего появления JHipster осуществлял интеграцию всех современных платформ для создания веб-приложений (Angular, React или даже Vue.js), совмещая их с фактически стандартными Java-технологиями, такими как Spring Boot и Spring Cloud.

В реализации JHipster Quarkus OAuth 2.0 за основу взято URI-перенаправление login/oauth2/code/oidc, предполагающее использование платформы аутентификации Spring Security. Настоятельно рекомендуем выполнять аутентификации на стороне сервера, поскольку это намного безопаснее (так как у браузера нет необходимости управлять какими-либо идентификационными данными и хранить какие-либо маркеры доступа).

В среде JHipster Quarkus, чтобы повторно использовать без изменений клиентские приложения и реализовать на серверной стороне механизм аутентификации по протоколу OAuth 2.0, в бэкенде должны быть открыты два HTTP-маршрута. Вот почему в JHipster Quarkus предусмотрен контроллер UserOauth2Controller и настраиваемые свойства Quarkus OIDC, позволяющие обеспечить правильную работу всего механизма.

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

Объединение JHipster Quarkus с сервисом Okta

Из этого раздела вы узнаете, как использовать сервис Okta в качестве провайдера протокола аутентификации OAuth 2.0/OIDC. В Okta предусмотрены два варианта для конфигурирования OIDC-приложения. Это можно выполнить либо в консоли разработчика, либо с помощью инфраструктуры Okta CLI.

Использование инфраструктуры Okta CLI для конфигурирования JHipster

Инфраструктура Okta CLI автоматизирует для вас все конфигурации JHipster и Okta. Для установки Okta CLI можно воспользоваться популярными менеджерами пакетов.

macOS (с помощью Homebrew):

brew install --cask oktadeveloper/tap/okta

Linux (с помощью Flatpak):

# Add Flathub repoflatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo# install the packageflatpak install com.okta.developer.CLI# add this to your appropriate dot filealias okta="flatpak run com.okta.developer.CLI"

Windows (с помощью Chocolatey):

choco install okta -version 0.8.0

Вы также можете просто передать его в оболочку bash:

curl https://raw.githubusercontent.com/okta/okta-cli/master/cli/src/main/scripts/install.sh | bash

Если у вас ещё нет аккаунта разработчика в Okta, откройте терминал, перейдите в каталог приложения Quarkus и выполните okta register. Если у вас есть аккаунт, выполните okta login.

$ okta registerFirst name: DanielLast name: PetismeEmail address: daniel.petisme@gmail.comCompany: OktaCreating new Okta Organization, this may take a minute:OrgUrl: https://dev-9323263.okta.comAn email has been sent to you with a verification code.Check your emailVerification code: 232819New Okta Account created!Your Okta Domain: https://dev-9323263.okta.comTo set your password open this link:https://dev-9323263.okta.com/welcome/drpt2SjbRAPR-gvVHhnm

Если у вас уже есть аккаунт разработчика Okta, выполните команду okta login. Затем из каталога приложения Quarkus выполните okta apps create jhipster. Примите предлагаемые по умолчанию предложения для перенаправления URI.

$ okta apps create jhipsterApplication name [okta-jhipster-quarkus-example]:Redirect URICommon defaults:  Spring Security - http://localhost:8080/login/oauth2/code/okta  Quarkus OIDC - http://localhost:8080/callback  JHipster - http://localhost:8080/login/oauth2/code/oidcEnter your Redirect URI(s) [http://localhost:8080/login/oauth2/code/oidc, http://localhost:8761/login/oauth2/code/oidc]:Enter your Post Logout Redirect URI(s) [http://localhost:8080/, http://localhost:8761/]:Configuring a new OIDC Application, almost done:Created OIDC application, client-id: 0oa5ozjxyNQPPbKc65d6Creating Authorization Server claim 'groups':Adding user daniel.petisme@gmail.com to groups: [ROLE_USER, ROLE_ADMIN]Creating group: ROLE_USERCreating group: ROLE_ADMIN

Конфигурация приложения Okta записывается здесь: /Users/daniel/workspace/okta-jhipster-quarkus-example/.okta.env

ПРИМЕЧАНИЕ: идентификаторы URI, перенаправленные http://localhost:8761*, предназначены для реестра JHipster, который часто используется при создании микросервисов с помощью JHipster. В инфраструктуре Okta CLI они добавляются по умолчанию. Они не требуются для приложения, создаваемого в этой вводной статье, но если их оставить, то никакого вреда точно не будет.

Инфраструктура Okta CLI создаст файл .okta.env в текущем каталоге. Если посмотреть на него, то вы увидите, что в нём содержатся несколько ключей и значений, предназначенных для протокола OIDC.

$ cat .okta.envexport QUARKUS_OIDC_AUTH_SERVER_URL="http://personeltest.ru/aways/dev-9323263.okta.com/oauth2/default"export QUARKUS_OIDC_CLIENT_ID="0oa5ozjxyNQPPbKc65d6"export QUARKUS_OIDC_CREDENTIALS_SECRET="KEJ0oNOTFEUEFHP7i1TELLING1xLm1XPRn"export QUARKUS_OIDC_AUTHENTICATION_REDIRECT_PATH="/login/oauth2/code/oidc"export JHIPSTER_OIDC_LOGOUT_URL="http://personeltest.ru/aways/dev-9323263.okta.com/oauth2/default/v1/logout"

Установите файл, чтобы задать переменные среды, и запустите ваше приложение с помощью Maven.

source .okta.env./mvnw

Обязательно добавьте \*.env в ваш файл .gitignore, чтобы в коммиты не попадал ваш секрет клиента.

Как только приложение будет запущено, в окне в режиме инкогнито откройте http://localhost:8080 и выполните вход. Вам будет предложено ввести свои идентификационные данные Okta.

После успешного прохождения аутентификации вы будете перенаправлены обратно в ваше приложение. На начальной странице должен отображаться ваш адрес электронной почты.

Инфраструктура Okta CLI упрощает конфигурирование JHipster и выполняет следующие полезные операции.

1. Создаётся приложение OIDC с правильным перенаправлением URI.

2. Заводятся группы ROLE_ADMIN и ROLE_USER, требуемые для JHipster.

3. Ваш текущий пользователь добавляется в группы ROLE_ADMIN и ROLE_USER.

4. Создаётся заявка на группы на заданном по умолчанию сервере авторизации, и к ней добавляются эти пользовательские группы.

Но вдруг вы не любите работать из командной строки? Не паникуйте, тут есть кому прикрыть вашу спину! Инфраструктура Okta CLI проста в использовании, но для тех, кому это необходимо, есть возможность выполнить настройки с помощью интерфейса пользователя. Именно поэтому я так подробно рассматриваю каждый шаг по настройке приложения OIDC, работающего с JHipster Quarkus.

Использование консоли разработчика Okta для настройки JHipster

Если у вас нет аккаунта разработчика Okta, необходимо нажать ссылку sign up (вход). Тут нет ничего сверхсложного: просто укажите имя, фамилию, адрес электронной почты, выберите надёжный пароль и всё вы готовы двигаться дальше. Выполнив вход в систему, вы попадаете в консоль разработчика:

Разверните вложенное меню Applications (Приложения) на панели навигации слева, затем выберите в меню Applications > Create App Integration (Приложения > Создать интеграцию приложений), чтобы запустить мастер создания приложений.

Выберите OIDC и Web Application. Затем нажмите кнопку Next (Далее).

Теперь вам необходимо будет указать некоторые настройки для приложения.

• Name (Имя): можете указать любое имя на свой вкус, но разве JHipster Quarkus чем-то не подходит?

• Login redirect URIs (Перенаправление URI при входе): определяет, будет ли Okta выполнять перенаправление в браузере клиента после аутентификации. Установите для него http://localhost:8080/login/oauth2/code/oidc, именно это значение настроено по умолчанию.

• Logout redirect URIs (Перенаправление URI при выходе): http://localhost:8080 указывается, куда будет перенаправляться пользователь после выполнения выхода.

• Group assignments (Назначения групп): определяет, какие группы могут использовать это приложение.

Используйте предлагаемые значения по умолчанию для всех остальных настроек. Завершив ввод требуемых настроек для своего приложения, нажмите Save (Сохранить). На экране отобразятся подробные сведения о вашем приложении.

Наиболее важными являются следующие значения:

• идентификационные данные клиента (ID и секрет клиента). Они позволяют приложению Java выполнять аутентификацию в сервисах Okta для последующей обработки потоков аутентификации и авторизации пользователей;

• домен Okta, из которого Quarkus будет выводить конечные точки адресов URL для протоколов OAuth/OIDC.

Создание групп пользователей

Теперь настало время для создания групп пользователей. По умолчанию для JHipster требуются две следующие группы:

• ROLE_USER: для аутентифицированных пользователей;

• ROLE_ADMIN: для аутентифицированных пользователей с административными правами для этого приложения.

В консоли разработчика выберите в меню Directory > Groups (Каталог > Группы). Нажмите Add Group (Добавить группу) и создайте группу ROLE_ADMIN

Теперь добавьте группу ROLE_USER.

Всё, вы завершили создание групп, теперь займёмся добавлением пользователей.

Создание пользователей

Чтобы увидеть различие между обычными и административным пользователями, создайте пользователей в каждой из групп. Используя консоль разработчика Okta, выберите в меню Directory > People (Каталог > Люди). Нажмите Add Person (Добавить человека). Начните с создания пользователя Administrator.

Основным моментом тут является привязка пользователя Administrator к группе ROLE_ADMIN. Чтобы определить исходный пароль, который пользователь должен будет изменить, исключительно в демонстрационных целях для данной вводной статьи использована стратегию выбора пароля Set by Admin (Задаётся администратором). В реальном проекте я рекомендую использовать стратегию Set by User (Задаётся пользователем) с активацией по электронной почте. Теперь добавим обычного пользователя.

Убедитесь, что пользователь User входит в группу ROLE_USER. Очень важно использовать действующий адрес электронной почты, так как он может понадобиться при восстановлении пароля. Выберите в меню Applications > JHipster Quarkus (Приложения > JHipster Quarkus) и нажмите Assignments (Назначения). Назначьте группам пользователей, которых только что создали.

Добавление заявки на группы к маркеру ID

Последнее, о чём необходимо вам позаботиться, это настроить заявку на группы, включающую группы пользователей в маркер ID. Выберите в меню Security > API (Безопасность > API), а затем нажмите default (по умолчанию). Щёлкните Claims > Add Claim (Заявки > Добавить заявку). Введите следующие значения:

• Name (Имя): groups (группы);

• Include in token type (Включить тип маркера): ID Token (Маркер ID);

• Value type (Тип значения): groups (группы);

• Filter (Фильтр): Matches regex with a value of .* (Соответствует регулярному выражению со значением .*).

Нажмите Create (Создать). Конфигурация Okta для JHipster готова!

Настройка Quarkus OIDC для Okta

В этот момент необходимо, чтобы приложение JHipster Quarkus уже было запущено и для использования Keycloak в качестве провайдера идентификационных данных для него. Давайте изменим настройки для работы с Okta. Во-первых, необходимо выйти из веб-приложения JHipster, чтобы предотвратить конфликт файлов cookie. Выберите Account > Sign Out (Аккаунт > Выход).

ПРИМЕЧАНИЕ: можно оставить приложение запущенным. Quarkus поддерживает работу в так называемом режиме для разработки (Dev Mode), обеспечивающем горячую перезагрузку любых исходных или ресурсных файлов при каждом их обновлении. Это исключительно удобно!

Откройте для редактирования файл src/main/resources/application.properties и найдите в нём раздел со следующей конфигурацией OIDC.

# OAuth 2.0 and OIDCquarkus.oidc.enabled=truequarkus.oidc.auth-server-url=http://localhost:9080/auth/realms/jhipster/%dev.quarkus.oidc.client-id=web_app%dev.quarkus.oidc.credentials.secret=web_appquarkus.oidc.application-type=hybridquarkus.oidc.authentication.scopes=profile,address,email,address,phone,offline_accessquarkus.oidc.authentication.cookie-path=/quarkus.oidc.authentication.redirect-path=/login/oauth2/code/oidcquarkus.oidc.authentication.restore-path-after-redirect=falsejhipster.oidc.logout-url=http://localhost:9080/auth/realms/jhipster/protocol/openid-connect/logout%test.quarkus.oidc.client-id=dummy%test.quarkus.oidc.application-type=service%test.jhipster.oidc.logout-url=some-dummy-logoutUrl

Показанные выше значения предназначены для Keycloak. Вами необходимо обновить следующие свойства, чтобы интегрировать своё приложение с Okta;

• quarkus.oidc.auth-server-url: корневой URL для API Okta, полученный из домена приложения OIDC;

• quarkus.oidc.client-id: ID клиента для приложения OIDC;

• quarkus.oidc.credentials.secret: секрет клиента для приложения OIDC;

• jhipster.oidc.logout-url: в JHipster браузер будет запускать выход из системы. Серверная сторона должна предоставлять эту информацию (пока её невозможно получить с помощью OIDC-поиска).

После того как вы обновите этот файл, ваши настройки должны выглядеть примерно так:

# OAuth 2.0 and OIDCquarkus.oidc.enabled=truequarkus.oidc.auth-server-url=https://dev-9323263.okta.com/oauth2/defaultquarkus.oidc.client-id=0oaajhdr9q9jxbBM95d6quarkus.oidc.credentials.secret=NEVERSHOWSECRETSquarkus.oidc.application-type=hybridquarkus.oidc.authentication.scopes=profile,address,email,address,phonequarkus.oidc.authentication.cookie-path=/quarkus.oidc.authentication.redirect-path=/login/oauth2/code/oidcquarkus.oidc.authentication.restore-path-after-redirect=falsejhipster.oidc.logout-url=https://dev-9323263.okta.com/oauth2/default/v1/logout

Перезапустите приложение, перейдите по адресу http://localhost:8080. Нажмите sign in (вход) и вы будете перенаправлены на страницу входа Okta.

Введите admin в качестве имени пользователя и пароль, который вы задали. Okta определит, что это ваш первый вход в систему, и предложит сменить пароль. После выполнения вы будете перенаправлены в ваше приложение Quarkus.

Переход в нативный формат с помощью Quarkus и GraalVM

Заключительным шагом в данной вводной статье будет упаковка приложения Java в виде нативного выполняемого файла (оптимизированного для используемого микропроцессора). И снова JHipster надёжно прикрывает ваши тылы, делая для вас всё необходимое. Просто выполните в Maven команду package с профилем native:

./mvnw package -Pnative -DskipTests

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

[error]: Build step io.quarkus.deployment.pkg.steps.NativeImageBuildStep#build threw an exception: java.lang.RuntimeException: Cannot find the `native-image` in the  GRAALVM_HOME, JAVA_HOME and System PATH. Install it using `gu install native-image`

Самым простым способом решения этой проблемы будет применение SDKMAN для установки Java 11 с GraalVM:

sdk install java 21.0.0.2.r11-grl

Затем выполните gu install native-image:

$ gu install native-imageDownloading: Component catalog from www.graalvm.orgProcessing Component: Native ImageDownloading: Component native-image: Native Image  from github.comInstalling new component: Native Image (org.graalvm.native-image, version 21.0.0.2)

Как только процесс завершится, перезапустите команду package в Maven:

./mvnw package -Pnative -DskipTests

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

• ознакомиться с проектом JHipster Quarkus Blueprint;

• исследовать сайт для разработчиков Okta;

• изучить эти великолепные руководства по Quarkus.

Спустя примерно три минуты нативный выполняемый файл должен быть готов:

Запустите его как нативный выполняемый файл, используя команду target/*runner:

Ваше старое доброе Java-приложение запустится через 1 секунду! Помните, я рассказывал о приросте памяти? Ниже привожу команду, как посмотреть потребление памяти в мегабайтах:

$ ps -o pid,rss,command | grep --color jhipster | awk '{$2=int($2/1024)"M";}{ print;}'30951 46M ./target/jhipster-1.0.0-SNAPSHOT-runner31433 0M grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --color jhipster

Ваше приложение потребляет менее 50 МБ памяти. Перейдите по адресу http://localhost:8080 и убедитесь, что всё исправно работает. Теперь наслаждайтесь своим успехом!

Дальнейшая разработка с помощью JHipster Quarkus

Надеюсь, вы получили удовольствие от данной вводной статьи, пройдя все этапы создания нативного приложения и применяя для этого Java, Quarkus и JHipster. Не правда ли, впечатляет, как JHipster и Okta CLI делают для вас основную тяжёлую работу?! Вы можете найти пример, созданный в этой вводной статье, на GitHub. Если вы заинтересованы в дополнительном изучении blueprint-схем Quarkus, посмотрите проект generator-jhipster-quarkus, также размещённый на GitHub.

Совсем недавно Java считали медленным языком программирования, а вернее было бы сказать, что медленной была виртуальная машина Java, но это не помешало языку стать одним из самых востребованных по версии TIOBE. Сегодня Java становится всё быстрее, а это значит, что она ещё надолго сохранит способность конкурировать с новыми языками; кроме того, в последнее время наметилась тенденция к упрощению синтаксиса Java. Если вам интересен этот язык и работа с ним в перспективе, то вы можете посмотреть на программу обучения нашего курса по Java, где студенты за 14 месяцев получают всестороннюю подготовку к трудоустройству в качестве Java-разработчика.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

В digital-агентстве Convergent, где я работаю, в потоке множество проектов, и у каждого из них может быть собственная админка. Есть несколько окружений (дев, стейдж, лайв). А ещё есть разные внутрикорпоративные сервисы (как собственной разработки, так и сторонние вроде Redmine или Mattermost), которыми ежедневно пользуются сотрудники.

Наша команда всегда была распределённой между несколькими офисами, но с учётом событий последнего года все сотрудники перешли на удалёнку. Так мы столкнулись с необходимостью организовать всё многообразие внутренних и клиентских сервисов в единой системе.

В данной статье я хочу поделиться опытом создания собственной внутренней системы аутентификации на основе OpenResty, а также спецификации OAuth2. В качестве основного языка программирования мы используем PHP, а фреймворк Yii 2.

Суммирую необходимый функционал:

• Единое место управления всеми доступами. Здесь происходит выдача и отзыв доступов в административные панели сайтов и списки доменов;

• По умолчанию весь доступ запрещён, если не указано обратное (доступ к любым доменам контролируется с помощью OpenResty);

• Аутентификация для сотрудников;

• Аутентификация для клиентов.

Закрытый доступ к сайтам и инфраструктуре

Начну со схемы, как мы организовали инфраструктуру доступов.

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

Фронт-контроллером в данном случае выступает OpenResty это модифицированная версия nginx, которая в т. ч. поддерживает из коробки язык Lua. На нём я написал прослойку, через которую проходят все HTTP(s)-запросы.

Вот так может выглядеть код скрипта аунтентификации (в упрощенном варианте):

function authenticationPrompt()    ngx.header.www_authenticate = 'Basic realm="Restricted by OpenResty"'    ngx.exit(401)endfunction hasAccessByIp()    local ip = ngx.var.remote_addr    local domain = ngx.var.host    local port = ngx.var.server_port    local res, err = httpc:request_uri(os.getenv("AUTH_API_URL") .. "/ip.php", {        method = "GET",        query = "ip=" .. ip .. '&domain=' .. domain .. '&port=' .. port,        headers = {          ["Content-Type"] = "application/x-www-form-urlencoded",        },        keepalive_timeout = 60000,        keepalive_pool = 10,        ssl_verify = false    })    if res ~= nil then        if (res.status == 200) then            session.data.domains[domain] = true            session:save()            return true        elseif (res.status == 403) then            return false        else            session:close()            ngx.say("Server error: " .. res.body)            ngx.exit(500)        end    else        session:close()        ngx.say("Server error: " .. err)        ngx.exit(500)    endendfunction hasAccessByLogin()    local header = ngx.var.http_authorization    local domain = ngx.var.host    local port = ngx.var.server_port    if (header ~= nil) then        header = ngx.decode_base64(header:sub(header:find(' ') + 1))        login, password = header:match("([^,]+):([^,]+)")        if login == nil then            login = ""        end        if password == nil then            password = ""        end        local res, err = httpc:request_uri(os.getenv("AUTH_API_URL") .. '/login.php', {            method = "POST",            body = "username=" .. login .. '&password=' .. password .. '&domain=' .. domain .. '&port=' .. port,            headers = {              ["Content-Type"] = "application/x-www-form-urlencoded",            },            keepalive_timeout = 60000,            keepalive_pool = 10,            ssl_verify = false        })        if res ~= nil then            if (res.status == 200) then                session.data.domains[domain] = true                session:save()                return true            elseif (res.status == 403) then                return false            else                session:close()                ngx.say("Server error: " .. res.body)                ngx.exit(500)            end        else            session:close()            ngx.say("Server error: " .. err)            ngx.exit(500)        end    else        return false    endendos = require("os")http = require "resty.http"httpc = http.new()session = require "resty.session".new()session:start()if (session.data.domains == nil) then    session.data.domains = {}endlocal domain = ngx.var.hostif session.data.domains[domain] == nil then    if (not hasAccessByIp() and not hasAccessByLogin()) then        session:close()        authenticationPrompt()    else        session:close()    endelse    session:close()end

Алгоритм работы скрипта довольно простой:

• Поступает HTTP-запрос от пользователя;

• OpenResty запускает скрипт auth.lua;

• Скрипт определяет запрашиваемый домен и отправляет два запроса на внешний бэкенд;

• Первый на проверку IP-адреса пользователя в базу;

• Если IP отсутствует, выводит браузерное окно для ввода логина и пароля, отправляет второй запрос на проверку доступа;

• В любой другой ситуации выводит окно Вход.

На GitHub я выложил рабочий пример, который можно быстро развернуть с помощью Docker.

Немного расскажу о том, как выглядит управление в нашей системе.

Отмечу, что IP-адреса попадают в базу при аутентификации пользователя. Это сделано специально для сотрудников. Такие адреса помечают как временные и доступные ограниченное время, после чего они удаляются.

В случаях, когда нужно разрешить межсерверное взаимодействие, через панель управления можно добавить IP-адреса вручную.

Для клиентов же создаются простые доступы по паре логин-пароль. Такие доступы ограничиваются в пределах определенных доменных адресов.

Управление базой сотрудников подтягивается в ID через синхронизацию с другой внутренней системой. Каждый новый сотрудник при добавлении в нашу CRM автоматически получает учётную запись в ID, а также все нужные письма с доступами и инструкциями для последующей настройки и работы.

Каждый день мы начинаем работу с данной аутентификации, таким образом добавляя свой IP-адрес в белый список для получения доступа к инфраструктуре.

Двухфакторная аутентификация

Для обеспечения двухфакторной аутентификации для сотрудников решено было добавить Google Authenticator. Такой механизм защиты позволяет больше обезопасить себя от утечки доступов. Для PHP есть готовая библиотека sonata-project/GoogleAuthenticator. Пример интеграции можно посмотреть здесь.

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

OAuth и OpenID

Третье, и не менее важное для нас, создание OAuth-сервера. За основу мы взяли модуль thephpleague/oauth2-server. Для Yii 2 готового решения не было, поэтому написали собственную имплементацию сервера. OAuth2 достаточно обширная тема, расписывать её работу в данной статье не буду. Библиотека имеет хорошую документацию. Также она поддерживает различные фреймворки, включая Laravel и Symfony.

Таким образом, любой сторонний сервис, который поддерживает кастомные OAuth2 конфигурации, достаточно просто подключается к нашей системе. Значимой фишкой такой интеграции стало подключение нашего ID к Mattermost. Последний в бесплатной версии поддерживает только аутентификацию с помощью GitLab, которую удалось эмулировать через наш сервис.

Также для всех наших проектов на Yii был разработан модуль для подключения ID. Это позволило вынести всё управление доступами в админпанели для сотрудников в централизованное место. Кстати, если интересно, я писал статью о модульном подходе, который мы применили в нашем digital-агентстве.

Заключение

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

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

Ссылки по теме

• Мой пример Basic Digest аутентификации на Lua и OpenResty

• GoogleAuthenticator на PHP

• OAuth2 сервер на PHP