Безопасность схем аутентификации REST

В предыдущем ответе SSL упоминался только в контексте передачи данных и фактически не касался аутентификации.

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

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

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

Для тех, кто заинтересован, я подробно остановился на вопросе SO о схемах аутентификации HTTP. и как они работают.

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

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

HTTP Digest - более безопасный подход, поскольку он предотвращает передачу секретного токена; вместо этого это хэш, который сервер может проверить на другом конце. Хотя это может быть излишним для менее чувствительных приложений, если вы приняли меры, упомянутые выше. В конце концов, пароль пользователя уже передается в виде обычного текста, когда он входит в систему (если вы не выполняете какое-то необычное шифрование JavaScript в браузере), а также их файлы cookie при каждом запросе.

Обратите внимание, что с API-интерфейсами клиенту лучше передавать токены - случайно сгенерированные строки - вместо пароля, с которым разработчик входит на веб-сайт. Таким образом, разработчик должен иметь возможность войти на ваш сайт и сгенерировать новые токены, которые можно использовать для проверки API.

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

(Обновлено, чтобы охватить последствия установления соединения только по протоколу SSL.)

Или вы можете использовать известное решение этой проблемы и использовать SSL. Самоподписанные сертификаты бесплатны, и это личный проект, верно?

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

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

Фактически, исходная аутентификация S3 действительно позволяет подписывать контент, хотя и со слабой подписью MD5. Вы можете просто применить их необязательную практику включения заголовка Content-MD5 в HMAC (строка, которая должна быть подписана).

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

Их новая схема аутентификации v4 более безопасна.

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

Помните, что ваши предложения затрудняют взаимодействие клиентов с сервером. Им необходимо понять ваше инновационное решение и соответствующим образом зашифровать данные. Эта модель не очень подходит для общедоступного API (если вы не amazon \ yahoo \ google ..).

В любом случае, если вам нужно зашифровать содержимое тела, я бы посоветовал вам проверить существующие стандарты и решения, такие как:

Шифрование XML (стандарт W3C)

Безопасность XML