Можете ли вы обнаружить уязвимость в моем протоколе аутентификации?

Question

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

У меня два вопроса:

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

2. Можете ли вы определить критическую ошибку или уязвимость в следующем дизайне?

Если вы, как коммуна, можете одобрить этот проект, я рассмотрю возможность извлечения этого кода в плагин Ruby on Rails.

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

подробности:

Поставщик аутентификации ("AP"):

• Центральная служба, которая содержит все данные о пользователях.
• В этой настройке существует только один «AP».
• Возможно наличие нескольких «AP», но это не должно относиться к этому контексту.
• «AP» знает каждое «S» заранее.

Клиент аутентификации (служба "S"):

• Существует несколько внутренних и внешних веб-сервисов.
• Каждый сервис заранее знает «AP» и его открытый ключ.

Актер («А»):

• Конечный пользователь, который аутентифицируется сама с AP по логину и паролю
• Может запрашивать непосредственно любой URI "S" или "AP" до ее входа в систему

Соединения между "A", "S" и "AP" защищены HTTPS.

Кратко описана логика аутентификации:

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

1) Поставщик авторизации "AP"

• «AP» отправляет HTTP-запрос POST «сервер-сервер» на «S», чтобы получить одноразовый номер.
• «AP» генерирует токен аутентификации.
• Токен аутентификации - это объект XML, который включает:
  • срок годности (через 2 минуты),
  • ранее запрошенный одноразовый номер (для предотвращения воспроизведения),
  • идентифицирующее имя "S" (токен для Service_1 не подходит для Service_2),
  • информация о конечном пользователе.
• Токен аутентификации зашифрован с помощью AES256, а ключ шифрования и вектор инициализации подписаны личным ключом RSA точки доступа.
• Результирующие строки («data», «key» и «iv») сначала кодируются в Base64, а затем в URL, чтобы их можно было доставить в строке запроса URL.
• Конечный пользователь "A" перенаправлен по HTTP на службу "S" (запрос HTTPS GET).

2) Сервис "S"

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

Примечания:

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

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

Поскольку токен аутентификации доставляется как HTTP-запрос GET, он будет сохранен, например, в файле журнала Apache.Использование одноразового одноразового номера и даты истечения срока действия должно минимизировать вероятность повторной атаки.Для запроса POST потребуется страница HTML с формой, которая автоматически отправляется Javascript, поэтому используется GET.

Служба "S" генерирует одноразовый номер только в межсерверном API-запросе.Поэтому запросы на генерирование без аутентификации не должны представлять DoS-уязвимости.

Answer 1

Вы вводите в заблуждение аутентификацию («Я тот, кем я говорю») и авторизацию / контроль доступа («Мне разрешен доступ к этому»). Вы можете просто внедрить OAuth, а затем запросить сервер по HTTPS с помощью «разрешено ли этому идентификатору OAuth доступ ко мне?». Вам не нужно беспокоиться о повторных атаках, поскольку вы используете HTTPS.

«Безопасность трудна, поэтому я создам свою собственную».

Маркер аутентификации зашифрован AES256, а ключ шифрования и вектор инициализации подписаны личным ключом RSA точки доступа.

AES-256 и AES-192 имеют расписания слабых ключей. Но вы не используете это для конфиденциальности; Вы используете это как своего рода проверку «целостности». Это не работает: атакующий получает «подписанный» токен аутентификации. Атакующий восстанавливает ключ и IV. Атакующий шифрует другой токен аутентификации с тем же ключом и IV и использует одну и ту же «подпись».

Что не так с хешированием и подписью хеша? Также обратите внимание, что если вы собираетесь использовать пользовательскую подпись, вам нужно быть осторожным с заполнением (IIRC PKCS - что угодно добавляет не менее 11 байтов).

РЕДАКТИРОВАТЬ: И если вы используете шифр, где вы должны использовать хэш / MAC, вы действительно не должны разрабатывать протокол безопасности!

Answer 2

Вот несколько быстрых мыслей по вопросу 1:

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

• Тем не менее, я понимаю, что в то время OpenID, возможно, был не очень устоявшимся.Кроме того, OpenID все еще является относительно новым и, возможно, еще не все его ограничения определены.

• Тем не менее, вы будете использовать OpenID в ограниченном сценарии, где большая проблема OpenIDнескольких актеров) не входит в игру.Вы будете использовать только «техническое ядро» OpenID, которое легче понять.

• Ваши требования и обзор вашего протокола напоминают мне о Kerberos.Я также испытываю желание подтолкнуть к использованию единого входа LDAP +, но я не знаю, какие конкретные решения для этого существуют.

• В пользу вашего протокола является то, что вы 'Мы нашли время, чтобы описать это подробно.Именно это ставит вас выше, чем большинство самодельных разработчиков протоколов безопасности!

Answer 3

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

Так в чем же уязвимость?

Конечный пользователь "A" перенаправлен HTTP на службу "S" (запрос HTTPS GET).

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

«Сложность - худший враг безопасности.»

- Брюс Шнайер

Токен аутентификации зашифрован с помощью AES256, ключ шифрования и вектор инициализации подписаныпо секретному ключу RSA AP.

Прежде всего RSA может использоваться для шифрования сообщения, поэтому aes не требуется.HTTPS, с другой стороны, будет более эффективным и проверенным на безопасность.Я не понимаю, почему вы должны передавать токен аутентификации клиенту, когда у вас уже есть защищенный канал связи между серверами.Сервер может просто сказать: «Эй, кто-то был перенаправлен ко мне с этим идентификатором сессии, какова его информация о состоянии?».Это вопрос самого слабого звена в цепочке, и идентификатор вашей сессии должен быть достаточно сильным.Это потребовало бы, чтобы идентификатор сеанса был отправлен клиентом как запрос GET или POST, когда происходит передача обслуживания, которая может открыть дверь для фиксации сеанса .Вы можете проверить IP-адрес до и после передачи обслуживания, иногда IP-адрес клиента может законным образом измениться, но передача обслуживания будет очень узким окном, в котором это может произойти, и, что наиболее важно, оно вообще останавливает фиксацию сеанса.

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

Answer 4

Вы действительно просто подписываете ключ AES и затем отправляете зашифрованный токен, подпись RSA ключа и затем ключ-iv в PLAINTEXT?

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

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