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

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

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

  • Использовать базовую проверку подлинности HTTP с помощью SSL

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

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

  1. Создать подпись запроса с разделяемым секретом

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

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

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

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

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

ОТВЕТЫ

Ответ 1

HTTP Basic Authentication over SSL отлично защищена от моих исследований.

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

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

Ответ 2

Ответ Игоря не совсем прав. Хотя TLS гарантирует, что транспортный уровень зашифрован и защищен, он по-прежнему не столь безопасен, как использование, например, TLS с взаимной аутентификацией, когда клиент аутентифицируется с использованием "сильной криптографии" в виде цифровой подписи. Есть две основные причины, по которым это еще лучше, чем Basic Authentication over TLS:

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

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

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

Ответ 3

Хорошо использовать субдомен как имя пользователя, если существует какая-то форма секретности.

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

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

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

Ответ 4

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

Ответ 5

Отвечая на старую нить, поскольку никто не затронул основную точку

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

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

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

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

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

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

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

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

Ответ 6

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

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

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

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

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

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