Проверка подлинности дайджест: Настройка дайджест-проверки подлинности на основе утверждений для веб-приложения в SharePoint Server — SharePoint Server

Настройка дайджест-проверки подлинности на основе утверждений для веб-приложения в SharePoint Server — SharePoint Server





Twitter




LinkedIn




Facebook




Адрес электронной почты










  • Статья


  • Чтение занимает 2 мин


APPLIES TO:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

Вы можете настроить дайджест-проверку подлинности для одной или нескольких зон в веб-приложении на основе утверждений SharePoint Server. Веб-приложение — это веб-сайт служб IIS, который SharePoint Server создает и использует. Зоны представляют собой разные логические пути для получения доступа к одному веб-приложению. В каждом веб-приложении можно создать до пяти зон. Каждую зону представляет отдельный веб-сайт в IIS. Зоны позволяют применять разные условия доступа и политики для больших групп пользователей. Чтобы настроить дайджест-проверку подлинности для одной или нескольких зон в веб-приложении SharePoint Server, используйте консоль диспетчера IIS вместо центра администрирования SharePoint Server.

В отличие от обычной проверки подлинности дайджест-проверка подлинности шифрует учетные данные пользователя для повышения безопасности. Учетные данные пользователя отправляются в виде дайджеста сообщения MD5, в котором исходное имя пользователя и пароль не могут быть определены. При дайджест-проверке подлинности используется протокол с запросом и подтверждением, который требует от запросившей стороны представить действительные учетные данные в ответ на запрос с сервера. Для проверки подлинности относительно сервера клиент должен предоставить в ответ дайджест сообщения MD5, который содержит строку пароля общего секрета. Алгоритм хэша MD5 описан в стандарте RFC 1321. Сведения о доступе к RFC 1321 см. в статье «Internet Engineering Task Force (https://go.microsoft.com/fwlink/p/?LinkId=159913).

Перед началом работы

Перед выполнением указанной процедуры проверьте соответствие следующим условиям:

  • Ваша система работает под управлением SharePoint Server.

  • Пользователь и сервер IIS должны быть членами или доверенными одного и того же домена.

  • Пользователи должны иметь действительную учетную запись Windows, хранимую в доменных службах Active Directory (AD DS) на контроллере домена.

  • Домен должен использовать контроллер домена Windows Server 2008 или Windows Server 2008 R2.

    Примечание.

    Для SharePoint Server 2016 домен должен использовать Windows Server 2012 R2 или Windows Server 2016 контроллер домена.

  • Вы понимаете дайджест-проверку подлинности для веб-трафика.

    Дополнительные сведения см. в разделе «Что такое дайджест-проверка подлинности»? (/previous-versions/windows/it-pro/windows-server-2003/cc778868(v=ws.10))

Настройка IIS для включения дайджест-проверки подлинности

Используйте консоль диспетчера Диспетчер IIS, чтобы настроить IIS для включения дайджест-проверки подлинности для одной или нескольких из следующих зон для веб-приложения с проверкой подлинности на основе утверждений:

  • По умолчанию

  • Интрасеть

  • Экстрасеть

Зона по умолчанию — это зона, которая создается первой при создании веб-приложения. Остальные зоны создаются путем расширения веб-приложения. Дополнительные сведения см. в статье «Расширение веб-приложений на основе утверждений» в SharePoint.

Настройка IIS для включения дайджест-проверки подлинности

  1. Убедитесь, что вы входите в группу «Администраторы» сервера, на котором настраиваются службы IIS.

  2. В меню Пуск выберите Администрирование и Диспетчер служб IIS, чтобы запустить консоль диспетчера Диспетчер IIS.

  3. Разверните узел Сайты в дереве консоли, щелкните веб-сайт IIS, соответствующий зоне веб-приложения, для которой необходимо настроить дайджест-проверку подлинности.

  4. В режиме просмотра возможностей в IIS дважды щелкните Проверка подлинности.

  5. В режиме просмотра возможностей в разделе Проверка подлинности щелкните правой кнопкой мыши Дайджест-проверка подлинности и нажмите кнопку Включить.

  6. Щелкните правой кнопкой мыши Дайджест-проверка подлинности и выберите пункт Изменить.

  7. В диалоговом окне «Изменение параметров дайджест-проверки подлинности» в текстовом поле «Область » введите соответствующую область и нажмите кнопку «ОК «.

    Область — это доменное имя DNS или IP-адрес, которые будут использовать учетные данные, проверенные в вашем внутреннем домене Windows. Необходимо настроить имя области для дайджест-проверки подлинности.

Теперь веб-сайт будет настроен на использование дайджест-проверки подлинности.

См. также

Концепции

Настройка обычной проверки подлинности для веб-приложений на основе утверждений

Другие ресурсы

Планирование методов проверки подлинности для пользователей в SharePoint Server

Расширение веб-приложений, основанных на утверждениях, в SharePoint






НОУ ИНТУИТ | Лекция | Целостность сообщения и установление подлинности сообщения

Лекция 1: 12345 || Лекция 2 >

Аннотация: Это первая из трех лекций, посвященных целостности сообщения, установлению подлинности сообщения и установлению подлинности объекта.
Здесь мы обсудим общие идеи, связанные с
криптографическими хэш-функциями,
которые используются, чтобы создать
дайджест сообщения из сообщения.
Дайджесты сообщения гарантируют целостность сообщения. Затем мы поговорим о том, как простые дайджесты сообщения могут быть модифицированы, чтобы подтвердить подлинность сообщения. Использованию
криптографических хэш-функций в стандартной криптографии посвящена
лекция 2

Ключевые слова: целостность, криптографическая хэш-функция, дайджест сообщения, криптографическая хэш-функция , устойчивость ко второму прообразу, устойчивость к коллизиям, случайная модель Oracle , математическая модель, функция, Oracle, таблица, дайджест, алгоритм, принцип голубиных ящиков, проблемы дней рождения, SHA-512, идеальные модели, доказательство, modification, detection, код обнаружения модификации (MDC), message authentication, код установления подлинности сообщения (MAC), код обнаружения модификации, вложенный MAC, код аутентификации сообщения, основанный на шифровании базового сообщения, входной блокнот, выходной блокнот, алгоритмы хэширования, CBC, устойчивость второго прообраза, modularity, mach

1.

1. Целостность сообщения

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

Документ и отпечатки пальцев

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

Сообщение и дайджест сообщения

Электронный эквивалент и пары «отпечаток пальца — документ» — это пара сообщение-дайджест. Чтобы сохранить целостность сообщения, оно обрабатывается алгоритмом, называемым криптографической хэш-функцией. Функция создает сжатое изображение сообщения, которое может использоваться подобно отпечатку пальца. рис. 1.1 показывает сообщение, криптографическую хэш-функцию и дайджест сообщения.

Рис.
1.1.
Сообщение и дайджест

Различия

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

Дайджест сообщения должен быть защищен от изменения.

Проверка целостности

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

увеличить изображение
Рис.
1.2.
Проверка целостности

Криптографические критерии хэш-функции

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

увеличить изображение
Рис.
1.3.
Критерии криптографической функции

Устойчивость прообраза

intuit.ru/2010/edi»>Криптографическая функция должна быть устойчива к прообразу. Если дана хэш-функция h и y = h(M), то для Евы должно быть экстремально трудно найти сообщение, такое, что y = h(M’). рис. 1.4 иллюстрирует эту идею.

увеличить изображение
Рис.
1.4.
Прообраз

Если хэш-функция — неустойчивый прообраз, Ева может перехватить дайджест h(M), создать сообщение M’ и затем передать M’ Бобу вместо исходного М.

Атака прообраза

Дано: y = h (M) Найти: такое М’, что y = h (M’).

Пример 1.1

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

Решение

intuit.ru/2010/edi»>Не можем. Метод сжатия без потерь создает сжатое сообщение, которое должно быть обратимо. Вы можете обработать сжатое сообщение, чтобы получить первоначальный текст.

Пример 1.2

Можем ли мы использовать функцию контрольной суммы как криптографическую хэш-функцию?

Решение

Не можем. Функция контрольной суммы — не стойкий прообраз. Ева может найти несколько сообщений, контрольная сумма которых соответствует данной.

Устойчивость ко второму прообразу

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

увеличить изображение
Рис.
1.5.
Второй прообраз

Ева перехватывает (имеет доступ к) сообщение М и его дайджест h(M). Она создает другое сообщение М.’ М., но h (M) = h(M’). Ева передает М.’ и h (M’) Бобу. Ева подделала сообщение.

Атака второго прообраза

Дана Атака: М и h (M) Найти: такое M’ = М, что h (M) = h (M’).

Устойчивость к коллизиям

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

увеличить изображение
Рис.
1.6.
Устойчивость к коллизиям

Дальше >>

Лекция 1: 12345 || Лекция 2 >

Что такое дайджест-аутентификация? — Переполнение стека

спросил

Изменено
5 лет, 4 месяца назад

Просмотрено
117 тысяч раз

Чем дайджест-аутентификация отличается от обычной аутентификации, кроме отправки учетных данных в виде обычного текста?

  • дайджест-аутентификация

4

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

Сервер предоставляет клиенту одноразовый номер (одноразовый номер), который он объединяет с именем пользователя, областью, паролем и запросом URI. Клиент запускает все эти поля с помощью метода хэширования MD5 для создания хеш-ключа.

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

На стороне сервера тот же метод используется для генерации хеш-ключа, только вместо использования пароля, введенного в браузере, сервер ищет ожидаемый пароль для пользователя из своей базы данных пользователей. Он ищет сохраненный пароль для этого имени пользователя, выполняет тот же алгоритм и сравнивает его с тем, что отправил клиент. Если они совпадают, доступ предоставляется, в противном случае он может отправить обратно 401 Unauthorized (нет входа или неудачный вход) или 403 Forbidden (доступ запрещен).

Дайджест-аутентификация стандартизирована в RFC2617. В Википедии есть хороший обзор этого:

Вы можете думать об этом так:

  1. Клиент делает запрос
  2. Клиент возвращает одноразовый номер с сервера и запрос аутентификации 401
  3. Клиент отправляет обратно следующий массив ответов (имя пользователя, область, generate_md5_key (одноразовый номер, имя пользователя, область, URI, пароль_данный_пользователем_в_браузер)) (да, это очень упрощено)
  4. Сервер берет имя пользователя и область (плюс он знает URI, запрашиваемый клиентом) и ищет пароль для этого имени пользователя. Затем он выполняет свою собственную версию generate_md5_key(nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
  5. Он сравнивает вывод generate_md5(), который он получил, с тем, что отправил клиент, если они совпадают с тем, что клиент отправил правильный пароль. Если они не совпадают, отправленный пароль был неправильным.

7

Хэш учетных данных отправляется по сети.

 HA1 = MD5 (имя пользователя: область: пароль)

В Википедии есть отличная статья на эту тему

0

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

1

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Типы базовой и дайджест-аутентификации

Опубликовано от Dimitri Osler

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

Basic HTTP

Первая версия SIP использовала Basic HTTP-аутентификацию . К этой системе довольно легко получить доступ с помощью атак «человек посередине». Этот тип аутентификации уже некоторое время обесценивает .

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

Действительно небезопасно.

Дайджест-аутентификация

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

Давайте подробно рассмотрим сообщения, которыми обмениваются между клиентом и сервером:

Сервер требует аутентификации: 

 WWW-аутентификация: Digest realm="[email protected]",

 qop="авторизация, авторизация-инт",

 одноразовый номер = "dcd98b7102dd2f0e8b11d0f600bfb0c093",

 opaque="5ccc069c403ebaf9f0171e9517f40e41"

Клиент добавляет аутентификационную информацию: 

 Авторизация: Digest username="Mufasa",

 область = "[email protected]",

 одноразовый номер = "dcd98b7102dd2f0e8b11d0f600bfb0c093",

 uri="/каталог/index.html",

 qop = авторизация,

 нк=00000001,

 cnonce="0a4f113b",

 ответ = "6629fae49393a05397450978507c4ef1",

 opaque="5ccc069c403ebaf9f0171e9517f40e41"

Значение «ответа» вычисляется в следующих трех шагах (если значения объединяются, они разделяются двоеточиями):

  1. Вычисляется хэш MD5 объединенного имени пользователя, области аутентификации и пароля. Результат обозначается как HA1.
  2. Вычисляется хэш MD5 комбинированного URI метода и дайджеста (например, «GET» и «/dir/index.html»). Результат обозначается как HA2.
  3. Вычисляется хэш MD5 объединенного результата HA1, одноразового номера сервера (nonce), счетчика запросов (nc), одноразового номера клиента (cnonce), кода качества защиты (qop) и результата HA2. Результатом является значение «ответ», предоставленное клиентом.
 HA1 = MD5 («Муфаса: [email protected]: Круг Жизни»)

 = 939e7578ed9e3c518a452acee763bce9

 HA2 = MD5 ("GET:/dir/index.html" )

 = 39aff3a2bab6126f332b942af96d3366

 Ответ = MD5 ("939e7578ed9e3c518a452acee763bce9:\

 dcd98b7102dd2f0e8b11d0f600bfb0c093:\

 00000001:0a4f113b:аутентификация:\

 39aff3a2bab6126f332b942af96d3366" )

 = 6629fae49393a05397450978507c4ef1

Преимущества использования этого метода следующие: Это позволяет некоторым реализациям (например, JBoss (https://en.wikipedia.org/wiki/JBoss) хранить HA1, а не открытый пароль.

  • Одноразовый номер клиента был введен в RFC 2617 (https://tools.ietf.org/html/rfc2617), что позволяет клиенту предотвратить атаки с использованием выбранного открытого текста, такие как радужные таблицы (https://en.wikipedia.org/wiki/Rainbow_table), которые в противном случае могут угрожать схемам дайджест-аутентификации.
  • Одноразовый номер сервера разрешено содержать временные метки, что означает, что сервер может проверять атрибуты одноразового номера , отправленные клиентами, для предотвращения повторных атак.
  • Сервер также разрешен от до поддерживать список недавно выпущенных или серверов одноразовые значения для предотвращения повторного использования.

    • недостатки этой конфигурации включают:

    • Многие из параметров безопасности в RFC 2617 являются необязательными . Если качество защиты (QOP) не указано сервером, клиент будет работать в устаревшем режиме RFC 2069 с пониженной безопасностью (https://tools. ietf.org/html/rfc2069)

      • .

    • Аутентификация дайджест-доступа уязвима для посредника (MitM) атака  (https://en.wikipedia.org/wiki/Man-in-the-middle_attack). Например, злоумышленник MitM может указать клиентам использовать базовую аутентификацию доступа или устаревший режим аутентификации доступа RFC2069. Чтобы расширить это, аутентификация дайджест-доступа не предоставляет клиентам механизма для проверки подлинности сервера

      • .

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

    В заключение, Дайджест является улучшением , но все же имеет существенные недостатки .