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

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

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

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

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

Notable APIs: Google Checkout, Freshbooks, GitHub, Zendesk

  1. создайте подпись запроса с общим секретом

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

Notable APIs: Google Checkout, Amazon AWS

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

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

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

6 ответов


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

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

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


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

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

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

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


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

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

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

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


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


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

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

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

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

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

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

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

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

эта модель все еще не идеальна, хотя и подвержена пресловутому 51% атаки точно так же, как для Bitcoin Blockchain (это пример распределенной доверенной модели)


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

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

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

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

Итак, как и во всем, что важно, чтобы посмотреть на всю картину. HTTPS защищает пароль в пути? - Утвердительный ответ.

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