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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

поэтому крупные игроки не любят полагаться только на SSL:

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

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

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

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

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

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

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

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

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