Защита API: базовая аутентификация SSL и HTTP против подписи

Question

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

Различные API-интерфейсы, кажется, выполняют одно из двух действий:

1. Использование базовой аутентификации HTTP с SSL

В каждом запросе в качестве имени пользователя указывается поддомен, а в качестве пароля - ключ API.Поскольку мы используем SSL, то это должно быть безопасно от подмены.

Известные API: Google Checkout , Freshbooks , GitHub , Zendesk

Создание подписи запроса с общим секретом

Обычно достигается упорядочением пар ключ / значение и использованием HMAC-SHA1 с общим секретом для генерации подписи.,Затем подпись отправляется с запросом и проверяется на другом конце.

Известные API: Google Checkout , Amazon AWS

PS: это не ошибка, Google Checkout поддерживает оба

Редактировать: Просто прочитайте, что OAuth 2 сбрасывает подписи в пользу отправки имени пользователя / пароля через SSL.

Есть ли у кого-нибудь мнение о том, что выбрать: SSL против подписи?

Answer 1

Базовая аутентификация HTTP через SSL совершенно безопасна из моих исследований.

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

Поэтому достаточно передать имя пользователя и пароль без создания подписи.

Answer 2

Игорь ответ не совсем верно. Хотя TLS гарантирует, что транспортный уровень зашифрован и безопасен, он все же не настолько безопасен, как использование, например, TLS с взаимной аутентификацией, когда клиент аутентифицируется с использованием «сильной криптографии» в форме цифровой подписи. Есть две основные причины, почему это все же лучше, чем обычная аутентификация по TLS:

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

• Можно утверждать, что для цифровых подписей на стороне клиента также используется пароль, обычно для доступа к закрытому ключу. Но это все равно ситуация, отличная от той, что у нас с Basic Auth: во-первых, закрытый ключ находится в качестве ресурса на компьютере клиента, поэтому, даже если он будет восстановлен, он затронет только одного человека вместо всех, а во-вторых, для типичного ключа. для контейнерных форматов, таких как PKCS # 12, также имеется шифрование на основе пароля, используемое для доступа к ключу. Эти алгоритмы были специально разработаны для замедления атакующих с целью уменьшения их попыток перебора в единицу времени, что также является преимуществом для цифровых подписей.

Нет сомнений в том, что TLS Basic Auth гораздо удобнее в настройке и использовании, но для сред с высокой степенью безопасности я всегда предпочел бы «сильную криптографию», а не решения для пользователей и паролей, это стоит того.

Answer 3

Проблема Heartbleed с OpenSSL иллюстрирует потенциальные ловушки использования исключительно SSL для защиты API.В зависимости от использования API и его последствий, если транспорт SSL был скомпрометирован, могут потребоваться дополнительные меры безопасности, как указано в ответе Emboss.

Answer 4

Можно использовать поддомен в качестве имени пользователя, если существует какая-то форма секрета.

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

Используя S3, вы можете создать подпись, отправить ее в браузер и выполнить прямую загрузку из браузера в S3.

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

Answer 5

Отвечая на старый поток, поскольку никто по-настоящему не коснулся основной темы

SSL / TLS в корне ошибочен , как и все PKI, поскольку они полагаются на цепочку доверия, которая была доказана в большей степени.и более раз подвержены атакам MiM :

• Органы по сертификации были и могут быть взломаны.Одним из многих примеров является случай DigiNotar , когда ЦС был взломан в течение нескольких месяцев, прежде чем было подтверждено нарушение, все сертификаты были отозваны.В то же время правительство Ирана создало прекрасные и действительные сертификаты SSL для google.com, facebook.com, twitter.com и т. Д.

• Инструменты фильтрации прокси-серверов компании, такие как Zscaler, которые расшифровывают и повторно шифруют.весь трафик на лету для неуказанных "целей безопасности".См. этот вопрос / ответ по SO

• Ошибки с наиболее распространенной реализацией SSL (openSSL) обнаруживаются постоянно (но со временем ситуация должна улучшиться?)

Следовательно, крупные игроки не любят полагаться только на SSL:

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

Альтернативой модели PKI является Сеть доверия , которая не полагается на единый орган для проверки подлинности сертификатов, а скорее на мнение, представленное большинством известных и доверенных партнеров ИЛИ известных, но не обязательно доверенных партнеров

Эта модель все еще не идеальна, поскольку она подвержена пресловутой атаке 51% , точно так же, как и для цепочки биткойнов (это пример распределенного доверенного режима).л) * * тысяча сорок-одна

Answer 6

Я хотел бы указать на некоторые вещи, упомянутые на security.stackexchange.com, поскольку вы говорите: «Базовая аутентификация HTTP через SSL совершенно безопасна из моих исследований». Вы можете утверждать, что пункты 3 и 4 ниже редко применимы для API REST, но это действительно зависит от того, как они реализованы.

"Есть несколько проблем с HTTP Basic Auth:

• Пароль отправляется по проводам в кодировке base64 (которая может быть легко конвертируется в открытый текст).
• Пароль отправляется повторно, для каждого запроса. (Большая атака окно)
• Пароль кешируется веб-браузером, как минимум для длина окна / процесса. (Может быть тихо использован любым другой запрос к серверу, например CSRF).
• Пароль может постоянно храниться в браузере, если пользователь
  Запросы. (То же, что и в предыдущем пункте, кроме того, может быть украдено
  другой пользователь на общей машине).

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

Итак, как и во всем, важно взглянуть на всю картину. Защищает ли HTTPS пароль при передаче? - Да.

Этого достаточно? Обычно нет. (Я хочу сказать, всегда нет - но это действительно зависит от того, какой у вас сайт и насколько он должен быть защищен.) "