Что такое basic authentication как она работает

Аутентификация и авторизация в микросервисных приложениях

Автор: Вячеслав Михайлов, Solutions Architect

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

Что такое аутентификация?

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

Идентификация — процесс определения, что за человек перед нами. Аутентификация — процесс подтверждения, что этот человек именно тот, за кого себя выдает. Авторизация — процесс принятия решения о том, что именно этой аутентифицированной персоне разрешается делать. То есть, это три разных, последовательных и взаимно не заменяемых понятия. Идентификацию часто подразумевают в составе аутентификации. Самое главное — четко различать аутентификацию и авторизацию.

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

Способы аутентификации

При использовании HTTP-протокола простейший способ аутентификации — Basic access authentication. В принципе этот протокол устарел и уже редко используется в интернете, особенно в незащищенных соединениях, но еще сохраняется во внутрикорпоративных системах, просто потому что некоторые из них созданы достаточно давно. Стоит разобраться, как он работает.

HTTP Basic Authentication

Первым, что при обращении к защищенному ресурсу сервер выдаст пользователю, не имеющему доступа, будет ошибка 401 Unauthorized. При этом ответ также содержит информацию о типе аутентификации (в нашем случае – Basic), который он может принимать, и контекст, в рамках которого эта аутентификация действует (Realm). Пользователь вводит логин и пароль, они упаковываются в Base64 и отправляются на сервер для проверки. Здесь существуют различные опасности. Самая распространенная — угроза man-in-the-middle attack, или атаки посредника, в ходе которой при использовании незащищенного соединения учетные данные могут перехватить злоумышленники в момент передачи от клиента к серверу или обратно.

HTTP Digest Authentication

Следующим этапом развития технологии стала чуть более сложная система HTTP digest authentication, которая исключает передачу учетных данных в открытом виде — здесь для проверки используется MD5-хеш с некоторыми примесями, что позволяет избежать подбора логина и пароля. Конечно, этот алгоритм выглядит более надежным, но и он подвержен целому ряду не самых сложных атак. Например, вот тут можно почитать об атаках более подробно.

Forms Authentication

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

Token Authentication

На схеме хорошо видно, как и в какой последовательности приложения обмениваются информацией при использовании аутентификацией по токенам.

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

OAuth2 & Open ID Connect

Дальнейшее усовершенствование процесса понадобилось ввиду того, что токен-аутентификация требует присутствия пользователя в момент получения доступа к защищенному ресурсу. Потому что Identity provider при передаче ему управления будет с пользователем взаимодействовать, запрашивая, например, логин и пароль.

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

В 2006 году в ходе работы над реализацией протокола Open ID для Twitter обнаружилась потребность в новом открытом протоколе авторизации. В 2007 инженеры Google и AOL начали совместную работу над ним, а в 2009 Twitter предложил своим пользователям решение, делегировавшее сторонним сервисам доступ к аккаунтам и основанное на протоколе OAuth. Три года спустя была опубликована новая версия — OAuth 2, упростившая разработку клиентских приложений и получившая целый ряд новых возможностей, среди которых оказалось и обновление токена без участия пользователя. Многие сервисы начали использовать этот протокол еще до его официального утверждения.

Разбираемся детально ху из ху

OpenID 1.0 (2006) & OpenID 2.0 (2007) позволяли приложению(арб) запрашивать у доверенного сервера (authority) проверку пользователя(user). Отличия между версиями для нас несущественны.

Взгляд сверху

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

Single sign-on — технология единого входа — позволяет пользователю переключаться между различными приложениями без повторной аутентификации. Используя SSO можно избежать множественных логинов, так что пользователь просто не будет замечать этих переключений. При этом ситуации, когда в рамках вашей инфраструктуры таких приложений будет больше одного, встречаются постоянно. Технология единого входа особенно удобна в больших энтерпрайз-системах, состоящих из десятков приложений, слабо связанных между собой. Вряд ли пользователи будут довольны, вводя логин и пароль при каждом обращении к системе учета рабочего времени, корпоративному форуму или внутренней базе документов.

В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом.

На рисунке выше показано, какие именно протоколы используются при каждом типе взаимодействия.

Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. OAuth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.

Терминология OAuth2 & OpenID Connect

Сервис выдачи токенов

Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.

Клиент

Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «Security Token Service» у которого клиент запрашивает токен для доступа).

Пользователь

User — собственно конечный пользователь — человек.

Область (scope)

Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес сервиса выдачи токенов в составе запроса на аутентификацию.

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

Scopes бывают двух видов:

Запрос на аутентификацию

Authentication/Token Request — процесс запроса аутентификации.

Токен личности

Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.

Токен доступа

Access Token — информация, что конкретному пользователю разрешается делать. Клиент запрашивает Access Token и затем использует его для доступа к ресурсам (Web APIs). Access Token содержит информацию о клиенте и пользователе, если она присутствует. Важно понимать, что есть такие типы авторизации, при которых пользователь в процессе непосредственно не участвует (подробнее об этом в следующей части)

Токен обновления

Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.

Более подробно о составе токенов в разделе «структура токена».

Процесс аутентификации

При обращении пользователя к клиенту, тот перенаправляет пользователя на Open ID Connect Provider, который запрашивает у пользователя логин и пароль. В случае успешного прохождения проверки параметров аутентификации он возвращает назад identity token и access token, с которыми пользователь может обращаться к защищенному ресурсу.

Структура токена

Формат

В реализации OAuth2 используется так называемый jwt-токен, который состоит из трех частей. Допустим, при обращении к Identity provider вы отправляете логин/пароль и в ответ получаете токен. Он будет включать в себя: Header (заголовок), Payload (контент) и Signature (подпись). На сайте jwt.io его можно декодировать и посмотреть содержимое формате JSON. На этом сайте вы также найдете описание правил формирования jwt-токенов.

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

Кроме identity tokens, есть еще и аccess tokens, которые содержат информацию о выданных пользователю клеймах. Срок действия access token достаточно короткий, потому что его хищение может обеспечить несанкционированный доступ к ресурсу. Т. е. злоумышленник, если ему удастся заполучить токен этого типа, доступ получит на очень непродолжительное время. Для получения нового access token используется refresh token, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.

Основные поля

Кратко остановимся на том, какие есть стандартные полях в токене и зачем они нужны:

Заключение первой части

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

Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:

Минимальная реализация интеграции веб-клиента с Identity Server:

Минимальная реализация интеграции веб-API с Identity Server:

Источник

RFC 7617 | «Базовая» схема аутентификации HTTP

Аннотация

Этот документ определяет «Basic» (базовую) схему проверки подлинности протокола передачи гипертекста (HTTP), которая передает учетные данные в виде пар «user-id/password» (идентификатор пользователя/пароль), закодированных с использованием Base64.

Скачать оригинальный документ на английском языке RFC 7617 PDF

Оглавление

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc7617.

Уведомление об авторских правах

Copyright (c) 2015 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

Этот документ может содержать материалы из Документов IETF или Вкладов IETF, опубликованных или обнародованных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из этих материалов, возможно, не предоставили Доверие IETF право разрешать модификации таких материалов. вне процесса стандартизации IETF. Без получения адекватной лицензии от лица (лиц), контролирующих авторские права на такие материалы, этот документ не может быть изменен вне процесса стандартизации IETF, и его производные работы не могут быть созданы вне процесса стандартизации IETF, кроме как для форматирования его для публикация в качестве RFC или перевод на другие языки, кроме английского.

1. Введение

Этот документ определяет «Basic» (базовую) схему проверки подлинности по протоколу гипертекста (HTTP), которая передает учетные данные в виде пар «user-id/password» (идентификатор пользователя/пароль), закодированных с использованием Base64 (схемы проверки подлинности HTTP определены в [RFC7235 #]).

Эта схема не считается безопасным методом аутентификации пользователя, если только она не используется в сочетании с некоторой внешней защищенной системой, такой как TLS (Transport Layer Security, [RFC5246 #]), поскольку идентификатор пользователя и пароль передаются по сети в виде открытого текста.

«Базовая» схема ранее была определена в разделе 2 [RFC2617 #]. В этом документе обновляется определение, а также рассматриваются вопросы интернационализации путем введения параметра аутентификации «charset» (раздел 2.1).

Другими документами, обновляющими RFC 2617, являются «Протокол передачи гипертекста (HTTP / 1.1): аутентификация» ([RFC7235 #], определяющий структуру аутентификации), «Аутентификация доступа к дайджесту HTTP» ([RFC7616 #], обновление определения схемы аутентификации «Дайджест»). ) и «Поля заголовка ответа HTTP-аутентификация-информация и прокси-аутентификация-информация» ([RFC7615 #]). Взятые вместе, эти четыре документа устарели RFC 2617.

1.1. Терминология и обозначения

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #].

Термины «protection space» (пространство защиты) и «realm» (область) определены в разделе 2.2 [RFC7235 #].

Термины «(символьный) репертуар» и «схема кодирования символов» определены в разделе 2 [RFC6365 #].

2. «Базовая» схема аутентификации

Базовая схема аутентификации основана на модели, которая необходима клиенту для аутентификации с использованием идентификатора пользователя и пароля для каждого пространства защиты («realm») — («области»). Значение области — это строка произвольной формы, которую можно сравнить только на равенство с другими областями на этом сервере. Сервер будет обслуживать запрос только в том случае, если сможет подтвердить идентификатор пользователя и пароль для пространства защиты, применяемого к запрашиваемому ресурсу.

Базовая схема аутентификации использует платформу аутентификации следующим образом.

См. Также раздел 4.1 [RFC7235 #], в котором правильно обсуждается сложность синтаксического анализа.

Обратите внимание, что имена схем и параметров сопоставляются без учета регистра.

Для учетных данных используется синтаксис «token68», определенный в Разделе 2.1 [RFC7235 #]. Значение вычисляется на основе идентификатора пользователя и пароля, как указано ниже.

HTTP/1.1 401 Unauthorized
Date: Mon, 04 Feb 2014 16:50:53 GMT
WWW-Authenticate: Basic realm=»WallyWorld»

где «WallyWorld» — это строка, назначенная сервером для идентификации пространства защиты.

Прокси-сервер может ответить аналогичным вызовом, используя код состояния 407 (Требуется аутентификация прокси-сервера) ([RFC7235 #], раздел 3.2) и поле заголовка Proxy-Authenticate ([RFC7235 #], раздел 4.3).

Чтобы получить авторизацию, клиент:

В первоначальном определении этой схемы аутентификации не была указана схема кодировки символов, используемая для преобразования прохода пользователя в последовательность октетов. На практике большинство реализаций выбирают либо кодировку, зависящую от локали, такую ​​как ISO-8859-1 ([ISO-8859-1]), либо UTF-8 ([RFC3629 #]). По причинам обратной совместимости эта спецификация продолжает оставлять кодировку по умолчанию неопределенной, если она совместима с US-ASCII (отображение любого символа US-ASCII на один октет, соответствующий коду символа US-ASCII).

Идентификатор пользователя и пароль НЕ ДОЛЖНЫ содержать управляющих символов (см. «CTL» в Приложении B.1 к [RFC5234 #]).

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

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

Если пользовательский агент хочет отправить идентификатор пользователя «Aladdin» (Алладин) и пароль «open sesame» (Сезам откройся), он будет использовать следующее поле заголовка:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

2.1. «Кодировка» параметр аутентификации

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

Единственное допустимое значение — «UTF-8»; он должен сопоставляться без учета регистра (см. [RFC2978 #], раздел 2.3). Это указывает на то, что сервер ожидает, что символьные данные будут преобразованы в форму нормализации Unicode C («NFC»; см. Раздел 3 [RFC5198 #]) и будут закодированы в октеты с использованием схемы кодирования символов UTF-8 ([RFC3629 #]).

Для идентификатора пользователя (user-id) получатели ДОЛЖНЫ поддерживать все символы, определенные в профиле «UsernameCasePreserved», определенном в разделе 3.3 [RFC7613 #], за исключением символа двоеточия («:»).

Для пароля получатели ДОЛЖНЫ поддерживать все символы, определенные в профиле «OpaqueString», определенном в Разделе 4.2 [RFC7613 #].

Другие значения зарезервированы для будущего использования.

Примечание. «charset» (Кодировка) определяется только для вызовов, так как обычная проверка подлинности использует один токен для учетных данных (синтаксис «token68»); таким образом, синтаксис учетных данных не является расширяемым.

Примечание. Название «charset» (Кодировка) выбрано для соответствия разделу 2.1.1 [RFC2831 #]. Лучшим названием было бы «accept-charset», так как оно касается не сообщения, в котором оно появляется, а ожидания сервера.

В приведенном ниже примере сервер запрашивает аутентификацию в области «foo», используя обычную аутентификацию, с предпочтением для схемы кодирования символов UTF-8:

WWW-Authenticate: Basic realm=»foo», charset=»UTF-8″

Обратите внимание, что значением параметра может быть либо токен, либо строка в кавычках; в этом случае сервер решил использовать нотацию в кавычках.

Имя пользователя — «test», а пароль — строка «123», за которой следует символ Unicode U + 00A3 (POUND SIGN). Используя схему кодировки символов UTF-8, пользовательский проход становится:

’t’ ’e’ ’s’ ’t’ ’:’ ’1’ ’2’ ’3’ pound
74 65 73 74 3A 31 32 33 C2 A3

Кодирование этой последовательности октетов в Base64 ([RFC4648 #], раздел 4) дает:

Таким образом, поле заголовка авторизации будет:

Authorization: Basic dGVzdDoxMjPCow==

Или для прокси-аутентификации:

Proxy-Authorization: Basic dGVzdDoxMjPCow==

2.2. Повторное использование учетных данных

Учитывая абсолютный URI ([RFC3986], раздел 4.3) аутентифицированного запроса, область аутентификации этого запроса получается путем удаления всех символов после последней косой черты («/») символа компонента пути («hier_part»; см. [ RFC3986], раздел 3). Клиент ДОЛЖЕН предположить, что ресурсы, идентифицируемые URI с совпадением префикса области аутентификации, также находятся в пределах пространства защиты, указанного значением области этого аутентифицированного запроса.

Клиент МОЖЕТ превентивно (в целях профилактики) отправить соответствующее поле заголовка авторизации с запросами ресурсов в этом пространстве без получения другого запроса от сервера. Аналогично, когда клиент отправляет запрос прокси-серверу, он МОЖЕТ повторно использовать идентификатор пользователя и пароль в поле заголовка «Proxy-Authorization» без получения другого запроса от прокси-сервера.

Например, предоставлен аутентифицированный запрос:

запросы к URI ниже могут использовать известные учетные данные:

http://example.com/docs/
http://example.com/docs/test.doc
http://example.com/docs/?page=1

в то время как URI

будет рассматриваться как выходящий за рамки аутентификации.

Обратите внимание, что URI может быть частью нескольких областей проверки подлинности (таких как « http://example.com/ » и « http://example.com/docs/ »). Эта спецификация не определяет, какие из них должны рассматриваться с более высоким приоритетом.

3. Вопросы интернационализации

Идентификаторы пользователей или пароли, содержащие символы вне набора символов US-ASCII, вызовут проблемы совместимости, если оба партнера по обмену информацией не согласятся, какую схему кодирования символов следует использовать. Серверы могут использовать новый параметр «charset» (раздел 2.1), чтобы указать предпочтение «UTF-8», увеличивая вероятность того, что клиенты переключатся на эту кодировку.

Параметр «realm» (область) содержит данные, которые можно считать текстовыми; тем не менее, в [RFC7235 #] не определен способ надежной передачи символов, отличных от US-ASCII. Это известная проблема, которую необходимо устранить при пересмотре этой спецификации.

4. Вопросы безопасности

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

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

Поскольку обычная проверка подлинности включает передачу паролей в виде открытого текста, она НЕ ДОЛЖНА использоваться (без таких усовершенствований, как HTTPS [RFC2818 #]) для защиты конфиденциальной или ценной информации.

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

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

Обычная проверка подлинности также уязвима для подделки поддельными серверами. Если пользователь может поверить, что он подключается к хосту, содержащему информацию, защищенную обычной аутентификацией, когда фактически подключается к враждебному серверу или шлюзу, то злоумышленник может запросить пароль, сохранить его для дальнейшего использования, и симулировать ошибку. Разработчики серверов должны защищаться от такого рода подделок; в частности, программные компоненты, которые могут взять на себя управление кадрированием сообщений в существующем соединении, должны использоваться осторожно или не использоваться вообще (например, сценарии NPH («непарсированный заголовок»), как описано в разделе 5 [RFC3875 #] ).

Серверы и прокси-серверы, реализующие базовую аутентификацию, должны хранить пароли пользователей в той или иной форме для аутентификации запроса. Эти пароли должны храниться таким образом, чтобы утечка данных пароля не делала их тривиально восстанавливаемыми. Это особенно важно, когда пользователям разрешено устанавливать свои собственные пароли, поскольку известно, что пользователи выбирают слабые пароли и используют их повторно в областях аутентификации. Хотя полное обсуждение хороших методов хеширования паролей выходит за рамки этого документа, операторы серверов должны приложить усилия, чтобы минимизировать риски для своих пользователей в случае утечки данных пароля. Например, серверы должны избегать хранения пользовательских паролей в виде открытого текста или в виде несоленых дайджестов. Дополнительные сведения о современных методах хэширования паролей см. В разделе «Password Hashing Competition» (Конкурс хэширования паролей) ( ).

Использование схемы кодирования символов UTF-8 и нормализации вносит дополнительные соображения безопасности; см. Раздел 10 [RFC3629 #] и Раздел 6 [RFC5198 #] для получения дополнительной информации.

5. Соображения IANA

Запись для «Базовой» схемы аутентификации была обновлена для ссылки на эту спецификацию.

6. Ссылки

6.1. Нормативные ссылки

[RFC20] Cerf, V., «ASCII format for network interchange», STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969,
.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
.

[RFC4648] Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 4648, DOI 10.17487/RFC4648, October 2006,
.

[RFC5198] Klensin, J. and M. Padlipsky, «Unicode Format for Network Interchange», RFC 5198, DOI 10.17487/RFC5198, March 2008,
.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
.

[RFC6365] Hoffman, P. and J. Klensin, «Terminology Used in Internationalization in the IETF», BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011,
.

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Authentication», RFC 7235, DOI 10.17487/RFC7235, June 2014,
.

[RFC7613] Saint-Andre, P. and A. Melnikov, «Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords», RFC 7613, DOI 10.17487/RFC7613, August 2015,
.

6.2. Информационные ссылки

[ ISO-8859-1] International Organization for Standardization, «Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin alphabet No. 1», ISO/IEC
8859-1:1998, 1998.

[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, «HTTP Authentication: Basic and Digest Access Authentication», RFC 2617, DOI 10.17487/RFC2617, June 1999,
.

[RFC2831] Leach, P. and C. Newman, «Using Digest Authentication as a SASL Mechanism», RFC 2831, DOI 10.17487/RFC2831, May 2000,
.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008,
.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, DOI 10.17487/RFC7231, June 2014,
.

[RFC7615] Reschke, J., «HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields», RFC 7615, DOI 10.17487/RFC7615, September 2015,

[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, «HTTP Digest Access Authentication», RFC 7616, DOI 10.17487/RFC7616, September 2015,
.

Приложение А. Изменения по сравнению с RFC 2617

Определение схемы было переписано, чтобы соответствовать более новым спецификациям, таким как [RFC7235 #].

Был добавлен новый параметр аутентификации «charset«. Он носит исключительно рекомендательный характер, поэтому существующие реализации не нужно менять, если только они не хотят воспользоваться дополнительной информацией, которая ранее была недоступна.

Приложение B. Вопросы развертывания для параметра ‘charset’

B.1. Агенты пользователей

Пользовательские агенты, не использующие ‘charset’, будут продолжать работать, как и раньше, игнорируя новый параметр.

Пользовательские агенты, которые уже используют кодировку UTF-8 по умолчанию, по определению реализуют кодировку.

Другие пользовательские агенты могут сохранять свое поведение по умолчанию и переключаться на UTF-8 при просмотре нового параметра.

B.2. Серверы

Серверы, которые не поддерживают символы не-US-ASCII в учетных данных, не требуют каких-либо изменений для поддержки ‘charset’.

Серверы, которые должны поддерживать символы не-US-ASCII, но не могут использовать схему кодирования символов UTF-8, не будут затронуты; они будут продолжать функционировать так же или так же плохо, как и раньше.

Наконец, серверы, которые должны поддерживать символы, отличные от US-ASCII, и могут использовать схему кодирования символов UTF-8, могут включить этот параметр, указав параметр charset в запросе на проверку подлинности. Клиенты, которые понимают параметр charset, затем начнут использовать UTF-8, в то время как другие клиенты будут продолжать отправлять учетные данные в кодировке по умолчанию, с неверными или без учетных данных. До тех пор, пока все клиенты не будут обновлены для поддержки UTF-8, серверы, вероятно, будут видеть как UTF-8, так и «устаревшие» кодировки в запросах. Когда происходит сбой обработки как UTF-8 (из-за сбоя декодирования как UTF-8 или несоответствия идентификатора пользователя / пароля), сервер может попытаться выполнить откат к ранее поддерживаемой унаследованной кодировке для размещения этих устаревших клиентов. Обратите внимание, что неявные повторные попытки должны быть сделаны осторожно; например, некоторые подсистемы могут обнаруживать повторяющиеся сбои при входе в систему и рассматривать их как потенциальную атаку, предполагающую учетные данные.

В.3. Почему бы просто не переключить кодировку по умолчанию на UTF-8?

Сегодня используются сайты, которые по умолчанию используют локальную схему кодировки символов, такую как ISO-8859-1 ([ISO-8859-1]), и ожидают, что пользовательские агенты будут использовать эту кодировку. Аутентификация на этих сайтах перестанет работать, если пользовательский агент переключится на другую кодировку, такую как UTF-8.

Обратите внимание, что сайты могут даже проверять поле заголовка «User-Agent» ([RFC7231 #], раздел 5.5.3), чтобы решить, какую схему кодирования символов ожидать от клиента. Следовательно, они могут поддерживать UTF-8 для некоторых пользовательских агентов, но по умолчанию использовать что-то другое для других. Пользовательские агенты в последней группе должны будут продолжать делать то, что они делают сегодня, пока большинство этих серверов не будут обновлены, чтобы всегда использовать UTF-8.

Благодарности

Эта спецификация берет на себя определение «Базовой» схемы аутентификации HTTP, ранее определенной в RFC 2617. Мы благодарим Джона Фрэнкса (John Franks), Филиппа М. Холлама-Бейкера (Phillip M. Hallam-Baker), Джеффри Л. Хостетлера (Jeffery L. Hostetler), Скотта Д. Лоуренса (Scott D. Lawrence), Пола Дж. Лича (Paul J. Leach), Ари Луотонена (Ari Luotonen) и Лоуренса С. Стюарта (Lawrence C. Stewart) за их работу над этой спецификацией, из которой были заимствованы значительные объемы текста. См. Раздел 6 [RFC2617 #] для дальнейших подтверждений.

Мы также благодарим членов Рабочей группы HTTPAUTH и других рецензентов, а именно Стивена Фаррелла (Stephen Farrell), Роя Филдинга (Roy Fielding), Дэниела Кана Гиллмора (Daniel Kahn Gillmor), Тони Хансена (Tony Hansen), Бьорна Хёрмана (Bjoern Hoehrmann), Кари Хуртту (Kari Hurtta), Амоса Джеффриса (Amos Jeffries), Бенджамина Кадука (Benjamin Kaduk), Майкла Келлера (Michael Koeller), Эрика Лоуренса (Eric Lawrence), Барри Лейбу (Barry Leiba), Джеймс Мангер (James Manger), Алексей Мельников (Alexey Melnikov), Кэтлин Мориарти (Kathleen Moriarty), Юрген Шенвельдер (Juergen Schoenwaelder), Ярон Шеффер (Yaron Sheffer), Мерал Ширазипур (Meral Shirazipour), Майкл Свит (Michael Sweet) и Мартин Томсон (Martin Thomson) за отзывы об этой редакции.

Источник