HTTP Basic Authentication вместо сертификации клиента TLS

Ниже приведен ответ из этого вопроса;

Признанный ответ фактически не затрагивает вопрос вообще. Он упоминает только SSL в контексте передачи данных и фактически не охватывает аутентификацию.

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

Если вы не используете аутентификацию клиента TLS, вам нужно использовать что-то вроде схемы проверки подлинности на основе дайджеста (например, пользовательской схемы Amazon Web Service) или OAuth или даже обычной HTTP-аутентификации (но только через SSL).

Поэтому, учитывая использование HTTPS без сертификации клиента мой вопрос здесь - плакат, если мы не используем клиентский сертификат SSL, сервер не знает, с кем его разговаривают. Я понимаю здесь, если я использую токен аутентификации для доступа к аутентификации клиента с сервером. Тогда сервер не знает, кто отправляет токен даже, если этот токен сопряжен с идентификатором пользователя в моей базе данных серверов.

Прежде всего

1 - это настоящая проблема? Если я специально использую Https? (Без проверки подлинности клиента TLS)

2- и, что наиболее важно, если предположить, что это важный недостаток безопасности; Как можно использовать базовую аутентификацию Http здесь в качестве плаката? Базовая аутентификация Http просто отправляет закодированный пароль пользователя в заголовке. Поэтому, когда клиент получает токен ( в ответ после отправки пароля пользователя), то для остальных своих запросов он будет использовать этот токен в этом заголовке вместо пароля, и все будет в порядке внезапно

Still Server не знает, откуда идет запрос, возможно, сервер имеет действительный токен с совпадающим пользователем в своей базе данных, но неизвестно, кто действительно отправляет его. (пока я все еще вижу это очень сильно, что токен будет украден поверх https и использован кем-то другим!)

Всякий раз, когда я привожу этот вопрос, я получаю ответы.. "Ну... вы отправляете токен, но сервер не знает, кому отправить токен, не очень безопасный", поэтому я понимаю это, поскольку браузер сохраняет своего рода сертификацию auth и сервер знает, где запрос приходит из нужного места. ТОГДА я могу быть уверен, что парный пользователь с этим токеном (проверенный из моей БД) "действительно прав"

Или, может быть, то, что здесь сказано, неверно

Ответ 1

[the] poster говорит, что если мы не используем клиентский сервер сертификации SSL, он действительно не знает, с кем его разговаривают.

Это не то, что я сказал:) Вот что я сказал:

Если вы не используете аутентификацию клиента TLS, только SSL не является жизнеспособным механизмом аутентификации для REST API.

один является ключевым словом здесь. Также:

Если вы не используете аутентификацию клиента TLS, вам нужно использовать что-то вроде схемы аутентификации на основе дайджеста (например, пользовательской схемы Amazon Web Service) или OAuth или даже обычной HTTP-аутентификации (но только через SSL).

Другими словами, аутентификация клиента TLS является одним из способов аутентификации клиента REST API. Поскольку исходный вопрос SO касался собственно SSL, я упоминал, что TLS-клиент authc является единственной "встроенной" формой аутентификации, если вы полагаетесь только на TLS. Поэтому, если вы используете TLS и не используете клиентскую лицензию TLS, вы должны использовать другую форму аутентификации для аутентификации вашего клиента.

Существует много способов аутентификации клиентов REST. TLS client authc - это только один из них (единственный "встроенный" для TLS и обычно очень безопасный). Однако TLS является протоколом сетевого уровня и, по мнению большинства, слишком сложна для многих конечных пользователей для настройки. Таким образом, большинство предложений REST API выбирают простой в использовании протокол уровня приложения, такой как HTTP, потому что его легче использовать (например, просто установить HTTP-заголовок).

Итак, если вы собираетесь использовать маршрут заголовка HTTP, вам нужно использовать значение заголовка для аутентификации клиента REST.

В HTTP-аутентификации у вас есть заголовок, Authorization и его значение (имя заголовка довольно неудачно, потому что оно обычно используется для аутентификации, а не так часто для контроля доступа, а также авторизации). Значением заголовка Authorization является то, что используется сервером для выполнения аутентификации, и оно составлено (обычно) из трех токенов

Имя схемы аутентификации HTTP, за которой следует
пробел (почти всегда пробельный символ), за которым следует
Текстовое значение, специфичное для схемы.

Одна общая схема проверки подлинности HTTP - это схема Basic, которая очень... ну... базовая:). Текстовое значение, специфичное для схемы, представляет собой просто следующее вычисляемое значение:

String concatenated = username + ":" + raw_password;
String schemeSpecificTextValue = base_64_encode(concatenated.toCharArray());

Итак, вы можете видеть, что соответствующий заголовок выглядит следующим образом:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Сервер знает, как разбирать значение. В нем говорится: "Эй, я знаю схему Basic, поэтому я собираюсь взять конечное текстовое значение, base64 декодирует его, а затем у меня будет имя пользователя и пароль. Тогда я вижу, соответствуют ли эти значения тем, что Я сохранил."

И это по существу Basic аутентификация. Поскольку эта схема, в частности, включает в себя исходный необработанный пароль base64, он не считается безопасным, если вы не используете соединение TLS. TLS гарантирует (главным образом), что любопытные глаза не могут перехватывать заголовки (например, через проверку пакетов) и видеть, что такое пароль. Вот почему вы никогда не должны использовать аутентификацию HTTP Basic, если она не связана с TLS-соединением. Всегда - даже в среде интрасети компании.

Существуют и другие, более безопасные схемы аутентификации HTTP, конечно. Примером может служить любая схема, использующая аутентификацию на основе дайджеста.

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

Вот почему этот метод более безопасен: передается только хеш - не сам сырой пароль. Это означает, что этот метод может использоваться для аутентификации запросов даже по каналам clear-text (non TLS) (но вы хотели бы сделать это, только если сами данные запроса не чувствительны).

Некоторые схемы проверки подлинности на основе дайджеста:

OAuth 1.0a, также известный как RFC 5849.
HTTP-дайджест-доступ аутентификация (используется браузерами изначально).
Пользовательская схема Stormpath (полное раскрытие, я технический директор Stormpath).
Пользовательская схема Amazon AWS.

Stormpath и Amazon более безопасны для REST, чем OAuth 1.0a, потому что они всегда аутентифицируют полезную нагрузку на объект запроса. OAuth 1.0a делает это только для содержимого application/x-www-form-urlencoded, которое не имеет отношения к API REST, которые используют полезную нагрузку application/xml или application/json (которая в наши дни кажется наиболее REST API).

Интересно, что OAuth2 не основывается на дайджесте - он использует то, что я считаю менее безопасным, называемое "токенами-носителями", которое, на мой взгляд, является симптомом OAuth 2 проблемы.

Наконец, да, это бесстыдный плагин, но если вы не хотите беспокоиться об этом, просто используйте Stormpath (многие варианты использования бесплатны). Мы автоматизируем этот материал, чтобы ваши приложения не нуждались.

Ответ 2

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

Дело в том, что в принципе все эти аутентификаторы могут быть украдены и использованы для олицетворения пользователя. Пароль может быть зарегистрирован, сертификат может быть скопирован с диска, на котором он хранится, может быть украден аппаратный токен (и, возможно, обратный дизайн и клонирование), и даже шаблон сетчатки пользователя может, в принципе, сканироваться, записываться и подделываться. самое лучшее, что мы можем сделать, - это в каждом случае попытаться сделать это как можно "очень трудным".

Ответ 3

Возможно, я не понимаю вопроса.

Ответ, который вы указали, говорит мне, что если вы не используете какую-либо форму аутентификации, будь то клиентские сертификаты, HTTP BASICAUTH или что-то еще, сервер не знает, с кем он связывается.

(Возможно, это хорошо для вашего приложения, возможно, это не так, только вы можете ответить на это.)

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

В этом контексте аутентификация - это процесс установления личности через некоторые учетные данные.

Аутентификация не гарантирует, что учетные данные не были украдены. SSL гарантирует (я бы не сказал, что это "гарантирует" ), учетные данные безопасны в пути между клиентом и сервером.

Когда вы используете GMail, вы используете SSL, как Google знает, что он разговаривает с вами?