Parus16.ru

Парус №16
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Аутентификация по сертификатам

Аутентификация по сертификатам

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

Инфраструктура, используемая для поддержки сертификатов в организации, называется инфраструктурой открытого ключа (Public Key Infrastructure, PKI). [22]

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

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

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

1. Клиент подает запрос аутентификации.

2. Сервер создаст вопрос.

3. Рабочая станция использует свой секретный ключ для шифрования вопроса.

4. Ответ возвращается серверу.

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

6. Если наблюдается совпадение, клиент успешно проходит аутентификацию. Данная концепция представлена на рис. 4.2.

Рис. 4.2. Аутентификация с использованием открытого и секретного ключей

Здесь полезно понять, что исходный набор ключей генерируется клиентом и в центр сертификации передается только открытый ключ. СА генерирует сертификат и подписывает его с помощью секретного ключа, после чего возвращает копию сертификата пользователю и его базе данных. [23]

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

Данная система может использоваться в электронной коммерции или в любой другой сфере, где требуется машинная аутентификация или необходимы безопасные соединения. Transport Layer Security (TLS) — это версия SSL, стандартизированная для использования в Интернете (RFC 2246). Несмотря на то, что TLS и SSL выполняют одну и ту же функцию, они не являются совместимыми: сервер, использующий SSL, не может установить защищенный сеанс с клиентом, который использует только TLS. Необходимо обеспечить совместимость приложений с SSL или TLS, прежде чем использовать одну из этих двух систем.

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

В наиболее распространенном варианте использования SSL организация получает SSL-сертификат сервера из открытого центра сертификации, такого как VeriSign, и устанавливает его на свой Веб-сервер.

Процесс аутентификации состоит из следующих этапов.

1. Пользователь вводит URL сервера в браузере.

2. Запрос клиента на веб-страницу передается на сервер.

3. Сервер получает запрос и отправляет свой сертификат сервера клиенту.

4. Браузер клиента проверяет свое хранилище сертификатов на наличие сертификата от центра сертификации, выпустившего сертификат сервера.

5. Если обнаруживается сертификат СА, браузер подтверждает сертификат посредством проверки подписи на сертификате сервера с использованием открытого ключа, имеющегося в сертификате СА.

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

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

8. Зашифрованный ключ возвращается серверу.

9. Сервер расшифровывает ключ с помощью собственного секретного ключа сервера. Для компьютера теперь общий ключ шифрования, который может использоваться для обеспечения безопасности соединений между ними.[24]

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

  • Если веб-сервер не настроен соответствующим образом на требование использования SSL, сервер не аутентифицируется относительно клиента, и может быть установлено обычное незащищенное соединение. Безопасность зависит от того, укажет ли пользователь в строке URL браузера протокол https:/ вместо http:/.
  • Если у клиента нет копии сертификата СА, она будет предложена ему сервером. Несмотря на то, что это обеспечивает наличие шифруемого соединения между клиентом и сервером, данный подход не обеспечивает аутентификацию сервера. Безопасность соединения здесь зависит от пользователя, который, в лучшем случае, откажется от соединения с сервером, который не идентифицирован третьей стороной.
  • Процесс получения сертификата СА в хранилище браузера не является четко контролируемым. В прошлом данное обстоятельство могло потребовать уплаты денежных средств или зависело от ваших связей. Теперь же Microsoft требует, чтобы сертификаты, устанавливаемые все браузеры, были выпущены центрами сертификации, прошедшими соответствующий аудит.
  • Основой является защита секретного ключа. В то время как реализации по умолчанию требуют лишь нахождения ключа в защищенной области системы, возможно, применить аппаратные системы, требующие хранения секретного ключа только на аппаратном устройстве.
  • Как в случае с любой системой, базирующейся на PKI, решение о предоставлении сертификата организации для его использования на сервере этой организации зависит от политик, созданных людьми, и, таким образом, данное решит принимается именно людьми. Поэтому могут допускаться различные ошибки Сертификат SSL, определяющий сервер как принадлежащий компании, может быть выпущен каким-либо лицом, не являющимся представителем этой компании. Кроме того, если даже истек срок действия сертификата или обнаружена другая проблема и выдан сигнал тревоги, многие пользователи просто проигнорируют это предупреждение.

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

Для SSL-сеансов обычно применяются 40- и 128-разрядный уровни шифрования. Первый вариант подходит для большинства ситуаций, включая электронную коммерцию, а второй — обеспечивает дополнительную защиту важных личных и финансовых сведений клиента. В версиях Microsoft Windows для США реализовано 128-, а в экспортных версиях — 40-разрядное шифрование. Чтобы обновить сервер для 128-разрядного шифрования, необходимо установить специальный пакет обновления, распространяемый Microsoft.

Читайте так же:
Бесплатно восстановить фото с карты памяти

Необходимо различать уровень шифрования SSL-сеансов (стойкость ключа сеанса, выраженная в разрядах) и уровень шифрования SSL-сертификатов (стойкость открытого и закрытого ключей сертификата, выраженная в разрядах). Обычно длина ключа шифрования, открытого или закрытого, составляет 512 или 1024 разряда. Внутренние американские и экспортные версии большинства приложений и ОС поддерживают ключи шифрования длиной 512 разрядов. Ключи длиной 1 024 и более разрядов во многих случаях не поддерживаются.

Когда пользователь пытается установить SSL-соединение с Web-сервером, клиентский браузер и сервер на основе своих ключей шифрования определяют максимально возможный уровень шифрования. Если длина ключей шифрования 512 разрядов, используется 40-разрядное, если 1 024 — 128-разрядное шифрование. Также доступны другие длины ключей и уровни шифрования.

Статьи к прочтению:

Сертификат (28 выпуск)

Похожие статьи:

Если между отправителем и получателем нет конфиденциальной схемы передачи асимметричных ключей, то возникает серьезная опасность появления…

Идентификацию и аутентификацию можно считать основой программно-технических средств безопасности, поскольку остальные сервисы рассчитаны на обслуживание…

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

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

В настоящее время для такой проверки применяется информация трех видов.

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

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

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

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

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

Удаленная аутентификация

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

Доступ по паролю

Простейший протокол аутентификации — доступ по паролю (Password Access Protocol, PAP): вся информация о пользователе (логин и пароль) передается по сети в открытом виде (рис. 1). Полученный сервером пароль сравнивается с эталонным паролем данного пользователя, который хранится на сервере. В целях безопасности на сервере чаще хранятся не пароли в открытом виде, а их хэш-значения (о хэшировании см. "Цифровая подпись — как это делается", "BYTE/Россия" № 1'2004).

Рис. 1. Схема протокола PAP.

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

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

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

Запрос-ответ

В семейство протоколов, называемых обычно по процедуре проверки "запрос-ответ", входит несколько протоколов, которые позволяют выполнить аутентификацию пользователя без передачи информации по сети. К протоколам семейства "запрос-ответ" относится, например, один из наиболее распространенных — протокол CHAP (Challenge-Handshake Authentication Protocol).

  • пользователь посылает серверу запрос на доступ, включающий его логин;
  • сервер генерирует случайное число и отправляет его пользователю;
  • пользователь шифрует полученное случайное число симметричным алгоритмом шифрования на своем уникальном ключе (см. "Современные алгоритмы шифрования", "BYTE/Россия" № 8'2003), результат зашифрования отправляется серверу;
  • сервер расшифровывает полученную информацию на том же ключе и сравнивает с исходным случайным числом. При совпадении чисел пользователь считается успешно аутентифицированным, поскольку признается владельцем уникального секретного ключа.
Рис. 2. Схема протокола аутентификации типа "запрос-ответ".

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

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

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

Читайте так же:
Гугл драйв на компьютер

Протоколы типа "запрос-ответ" легко "расширяются" до схемы взаимной аутентификации (рис. 3). В этом случае в запросе на аутентификацию пользователь (шаг 1) посылает свое случайное число (N1). Сервер на шаге 2, помимо своего случайного числа (N2), должен отправить еще и число N1, зашифрованное соответствующим ключом. Тогда перед выполнением шага 3 пользователь расшифровывает его и проверяет: совпадение расшифрованного числа с N1 указывает, что сервер обладает требуемым секретным ключом, т. е. это именно тот сервер, который нужен пользователю. Такая процедура аутентификации часто называется рукопожатием.

Рис. 3. Схема протокола взаимной аутентификации.

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

Заметим, что вместо симметричного шифрования в протоколах данного семейства может применяться и асимметричное шифрование, и электронная цифровая подпись. В таких случаях схему аутентификации легко расширить на неограниченное число пользователей, достаточно применить цифровые сертификаты в рамках инфраструктуры открытых ключей (см. "Открытые ключи — опасности и защита от них", "BYTE/Россия" № 7'2004).

Протокол Kerberos

Протокол Kerberos, достаточно гибкий и имеющий возможности тонкой настройки под конкретные применения, существует в нескольких версиях. Мы рассмотрим упрощенный механизм аутентификации, реализованный с помощью протокола Kerberos версии 5 (рис. 4):

Рис. 4. Схема протокола Kerberos.

Прежде всего стоит сказать, что при использовании Kerberos нельзя напрямую получить доступ к какому-либо целевому серверу. Чтобы запустить собственно процедуру аутентификации, необходимо обратиться к специальному серверу аутентификации с запросом, содержащим логин пользователя. Если сервер не находит автора запроса в своей базе данных, запрос отклоняется. В противном случае сервер аутентификации формирует случайный ключ, который будет использоваться для шифрования сеансов связи пользователя с еще одним специальным сервером системы: сервером предоставления билетов (Ticket-Granting Server, TGS). Данный случайный ключ (обозначим его Ku-tgs) сервер аутентификации зашифровывает на ключе пользователя (Kuser) и отправляет последнему. Дополнительная копия ключа Ku-tgs с рядом дополнительных параметров (называемая билетом) также отправляется пользователю зашифрованной на специальном ключе для связи серверов аутентификации и TGS (Ktgs). Пользователь не может расшифровать билет, который необходим для передачи серверу TGS на следующем шаге аутентификации.

Следующее действие пользователя — запрос к TGS, содержащий логин пользователя, имя сервера, к которому требуется получить доступ, и тот самый билет для TGS. Кроме того, в запросе всегда присутствует метка текущего времени, зашифрованная на ключе Ku-tgs. Метка времени нужна для предотвращения атак, выполняемых повтором перехваченных предыдущих запросов к серверу. Подчеркнем, что системное время всех компьютеров, участвующих в аутентификации по протоколу Kerberos, должно быть строго синхронизировано.

В случае успешной проверки билета сервер TGS генерирует еще один случайный ключ для шифрования сеансов связи между пользователем, желающим получить доступ, и целевым сервером (Ku-serv). Этот ключ шифруется на ключе Kuser и отправляется пользователю. Кроме того, аналогично шагу 2, копия ключа Ku-serv и необходимые целевому серверу параметры аутентификации (билет для доступа к целевому серверу) посылаются пользователю еще и в зашифрованном виде (на ключе для связи TGS и целевого сервера — Kserv).

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

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

Процедура аутентификации по протоколу Kerberos выглядит достаточно сложной. Однако не стоит забывать, что все запросы и зашифровывание их нужными ключами автоматически выполняет ПО, установленное на локальном компьютере пользователя. Вместе с тем необходимость установки достаточно сложного клиентского ПО — несомненный недостаток данного протокола. Впрочем, сегодня поддержка Kerberos встроена в наиболее распространенные ОС семейства Windows, начиная с Windows 2000, что нивелирует данный недостаток.

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

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

Выбор того или иного протокола зависит в первую очередь от важности информации, доступ к которой предоставляется по результатам аутентификации. Другой критерий — удобство использования. И здесь, как и везде, полезно соблюдать разумный баланс. Иногда, если нет особых требований к секретности процедуры аутентификации, вместо надежного (но непростого в реализации) протокола типа Kerberos лучше использовать "элементарный" парольный протокол РАР, простота и удобство применения которого часто перевешивают все его недостатки.

Другие статьи из раздела
  • Решение Fortinet для безопасности подключенных автомобилей
  • Решение для защиты критичных сегментов сетевой инфраструктуры
  • Решения HID Global для безопасности приложений Интернета вещей
  • Check Point отметила рост атак на корпоративные сети
  • Новые троянцы для Linux

Первый практический Форум «1С:Машиностроение 8»Внедренческий центр «Раздолье»
Первый практический Форум «1С:Машиностроение 8»
Внедренческий центр «Раздолье» 26 сентября 2008 г. успешно провел Первый практический Форум «1С:Машиностроение 8». Форум был посвящен новому …

МФУ Panasonic DP-MB545RU с возможностью печати в формате А3МФУ Panasonic DP-MB545RU с возможностью печати в формате А3
Хотите повысить эффективность работы в офисе? Вам поможет новое МФУ #Panasonic DP-MB545RU. Устройство осуществляет

RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэшаAdaptec by PMC
RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша
Опытные сетевые администраторы знают, что задействование в работе кэш-памяти RAID-контроллера дает серьезные преимущества в производительности …

Трехфазный ИБП Chloride от 200 до 1200 кВт: TrinergyChloride
Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy
Trinergy — новое решение на рынке ИБП, впервые с динамическим режимом работы, масштабируемостью до 9.6 МВт и КПД до 99%. Уникальное сочетание …

30 ноября 2021 г. | Он-лайн формат
Dell Technologies Forum 2021

Читайте так же:
Версия linux для слабых компьютеров

Что такое двухфакторная аутентификация

Школа хостинга Редактор: Дмитрий Сокол 2643 15 мин Аудио

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

Двухфакторная аутентификация (двухфакторная авторизация или 2FA) — это процесс подтверждения своей личности в интернет-сервисах не только при помощи логина и пароля, но и дополнительных средств:

  • специального кода безопасности, высылаемого на номер телефона;
  • телефонного звонка;
  • и т.д.

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

Способы реализации двухфакторной аутентификации

Код, отправляемый в SMS на телефон пользователя

Самый популярный способ двухфакторной авторизации — это “запрос кода безопасности”.

1. Пользователь вводит на сервисе логин и пароль.
2. После этого он получает специальный код безопасности по SMS или в любой из мессенджеров.
3. Код вводится в отдельное поле верификации.

Эту разновидность двухфакторной защиты используют для доступа к сервисам такие интернет-гиганты:

  • Google;
  • Facebook;
  • Microsoft.

Этот способ 2FA также поддерживают многие провайдеры хостинга.

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

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

Код, отправляемый на адрес электронной почты

1. Пользователь вводит на сервисе логин и пароль.
2. Код безопасности присылается ему на почту, а не на телефон.

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

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

Специальное программное обеспечение

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

Аналогичные приложения существуют также от Google (Google Authenticator) и Microsoft. Часть функционала аутентификатора встроена в приложение Facebook для смартфонов.

Физическое устройство для генерации кодов

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

Принцип работы устройства-токена:

1. Пользователь авторизуется на веб-сайте/в приложении с помощью логина-пароля.
2. Сервер проверяет учетные данные и, если они верны, генерирует специальный код (челлендж) для токена и отправляет его пользовательской программе, в данном случае, браузеру.
3. Браузер передает этот код токену, который может потребовать разные действия от пользователя, например, прикосновение пальцем к контактной площадке, ввод пин-кода, биометрическая проверка.
4. Токен возвращает программе ответ с подтверждением прохождения аутентификации, который передается на сервер.

Перспективные варианты на будущее

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

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

Двухфакторная аутентификация в качестве защиты учетной записи хостинга

Провайдеры услуг хостинга также взяли на вооружение двухфакторную аутентификацию.

Так, Reg.ru предоставляет возможность включить двухфакторную аутентификацию с получением кода подтверждения через SMS в личном кабинете. Необходимое условие — это привязка номера телефона к учетной записи пользователя. Получаемый код для подтверждения иначе называется “двухфакторным кодом аутентификации”.

Провайдер Beget предлагает два варианта двухфакторной аутентификации: по SMS (платная услуга) или по e-mail. Настройка опции происходит в личном кабинете.

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

Многие провайдеры в качестве панели управления хостингом используют популярную систему ISPmanager на виртуальном хостинге, VPS/VDS и выделенных серверах. В нее также встроена поддержка двухфакторной аутентификации, в меню — “Настройки пользователя”.

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

Как отключить двухфакторную аутентификацию на хостинге?

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

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

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

Защита сайта с помощью двухфакторной авторизации

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

Google Authenticator

Приложение Google Authenticator примечательно тем, что позволяет использовать 2FA не только для входа в сервисы Google, но и настроить владельцу web-сайта такую защиту для посетителей своего ресурса. Это требует навыков программирования и использования специальных библиотек. Например, для языка программирования PHP разработана библиотека GoogleAuthenticator.php.

Для популярной CMS WordPress существует специальный плагин Google Authenticator. С его помощью подключение двухфакторной аутентификации к сайту, созданному на базе этой CMS, становится легко и удобно.

Сервис E-Num

Сервис E-Num, который использует система платежей Webmoney, предлагает несколько вариантов интеграции двухфакторной аутентификации на сайт, например, через популярный протокол OAuth2.

Последовательность действий при авторизации с использованием системы E-NUM, согласно протоколу OAuth2, выглядит так:

1. Посетитель сайта запрашивает вход в защищенную зону.
2. Для предоставления доступа сайт требует пройти авторизацию, для чего перенаправляет его на E-NUM.
3. После успешной авторизации система E-NUM возвращает клиенту одноразовый код.
4. Браузер клиента передаёт код авторизации сайту.
5. Сайт, используя код авторизации, запрашивает у E-NUM временный токен доступа.
6. Этот токен используется в дальнейшем для обращения к методам API E-NUM, которые обеспечивают идентификацию клиента.

Читайте так же:
Добрые компьютерные игры для детей

Защита VPS/VDS при помощи двухфакторной аутентификации

Пользователям VPS/VDS также доступно применение двусторонней аутентификации для повышения безопасности своего сервера.

Для его использования:

1. Установите на сервер специальную библиотеку для системы авторизации PAM: libpam-google-authenticator.
2. Настройте библиотеки и конфигурации подсистемы SSH.
3. После этого вы сможете использовать 2FA через приложение для генерации кодов Google Authenticator, установленное на смартфоне.

Коды будут запрашиваться при подключении к серверу через SSH.

Подключение двухфакторной аутентификации пользователя

Рассмотрим подключение двухфакторной аутентификации на примере сервисов от компании Google.

1. Зайдите на сайт Google и откройте настройки своего аккаунта.
2. Зайдите в раздел «Безопасность».
3. Выберите пункт «Двухэтапная аутентификация».
4. Google попросит подтвердить, что это ваш аккаунт.
5. После ввода пароля откроется страница настроек двухфакторной аутентификации.

6. Google предложит привязать к системе номер телефона.
7. Введите номер своего телефона и получите на него код безопасности.
8. После подтверждения двухфакторная аутентификация настроена. При этом появится возможность выбрать способ, которым Google будет присылать код для аутентификации, например, SMS или голосовое сообщение.

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

Система аутентификации на базе протокола HTTP Digest. Усиление модуля.

У Basic есть один недостаток, а именно username и password передаются по сети открыто (clear text), base64 кодировка не может считаться защитой.

Аутентификация Digest

В этой статье будет рассмотрен алгоритм Digest аутентификации, решающей некоторые проблемы, имеющиеся у HTTP Basic Authentication. Например эта схема не передаёт password по сети открытым текстом. Официальное название схемы — "Digest Access Authentication".

Расширим нашу систему из предыдущей статьи.

К преимуществам Digest можно отнести следуещее:

  1. passwords не передаются открыто по сети
  2. способность защиты от повторяющихся атак (monitoring http nc value)
  3. способность создать защиту (monitoring nonce)
    • в определённый промежуток времени
    • от определённого client
    • от определённого request

Один сайт может одновременно использовать несколько систем защиты, например Basic и Digest

Пришло время рассмотреть работу алгоритма Digest аутентификации:

1. Первый запрос от User Agent к Http Server заголовок Authorization пустой — значит server должен возвратить запрос на аутентификацию. Например такой:

2. ответ сервера:

Разберём заголовок WWW-Authenticate (как вы заметили, он усложнился по сравнению с заголовком Basic):

realmСтрока, указывающая юзеру где он и какой пароль вводить например "registered_users@gotham.news.com".
nonceУникальная строка, которая генерируется на сервере в момент ответа 401. запрещено использовать кавычку, так как внутри заголовка строка в кавычках рекомендуется также закодировать её base64, например time-stamp H(time-stamp ":" ETag ":" private-key)
opaqueСтрока, которую юзер должен будет вернуть на сервер в неизменённом виде Рекомендуется закодировать base64
staletrue/false
Индикатор, который показывает, что если true — запрос был правильный, username-password тоже, nonce неправильный false или любое другое значение или отсутствие stale — неправильные username, password
algorithmoptional, MD5 = default
qopуказывает "quality of protection".
"auth" указывает authentication,
"auth-int" указывает authentication + integrity protection. могут быть оба через запятую

3. У юзера всплывает модальное окно, предлагающее ввести username и password (обратите внимание, окно отличается от Basic окна). Происходит запрос юзера для аутентификации:

Теперь разберём заголовок Authorization:

usernameимя юзера
realmсм. WWW-Authenticate
qopсм. WWW-Authenticate (должно совпадать с одним из списка qop WWW-Authenticate)
algorithmсм. WWW-Authenticate (должно совпадать)
opaqueсм. WWW-Authenticate (должно совпадать)
uriзапрос (например страница)
response32-character строка — именно c её помощью проверяется пароль.
nonce
nconce count — сколько раз был использован текущий nonce
cnonceуникальная строка, посылаемая браузером на сервер

4. Последовательность обработки запроса пользователя

  1. Проверяем, существует ли заголовок Authorization
  2. Проверяем, является ли он Digest
  3. Отсекаем слово Digest
  4. Берём username (обратите внимание — в заголовке отсутствует password — по крайней мере его не видно)
  5. проверяем базу данных с этим юзером, существует ли он — запоминаем его password из базы
  6. проверяем запрос по ролям против страниц с ролями, как мы уже делали в Basic.

Если что-то не так — переходим к пункту 6. Если всё ok — идём дальше (это ещё далеко не всё :))

5. Проверка пароля пользователя

  1. создаём строку A1 вида
    A1 = unq(username) : unq(realm) : passwd
  2. хешируем A1
    HA1 = MD5(A1)
  3. создаём строку A2 вида
    A2 = Http Method ":" digest-uri
  4. хешируем A2
    HA2 = MD5(A2)
  5. создаём строку GENRESPONSE вида
    GENRESPONSE = HA1 ":" nonce ":" nc ":" cnonce ":" qop ":" HA2
  6. хешируем GENRESPONSE
    HGENRESPONSE = MD5(GENRESPONSE)

если HGENRESPONSE равен response в заголовке Authorization запроса юзера и nonce в порядке — всё ok, нет — переходим к пункту 6

6. выдаём состояние ответа сервера 401, поднимающее модальное окно как в пункте 2 иначе говоря формируем WWW-Authenticate по типу Digest

HTTP Модуль AuthDigest

Ну что ж, вооружившись рассмотренными выше теоретическими выкладками напишем наш HttpModule, который воплотит Digest аутентификацию.

Всё. HttpModule готов. Подключим его к веб приложению: Для этого в файле web.config в разделе sytem.web пишем

отменяем встроенную аутентификацию

и сохраняем данные для Digest аутентификации (realm string, алгоритм, qop string, server opaque)

Алгоритм Digest аутентификации не претендует на решение всех задач, связанных с безопасностью в интернете. Эта схема не кодирует содержимое запроса-ответа. Цель Digest заключается в том, чтобы обеспечить систему аутентификации, такую же простую и удобную, как и Basic, но в которой бы отсутствовали недостатки, присущие Basic аутентификации. Тем не менее эта система гораздо сильнее, чем например CRAM-MD5, которая была предложена для LDAP, POP и IMAP(rfc 2195).

К коду прилагаются database scripts и упрощённый класс для работы с базой.

Аутентификация сервера что это

Стандартные возможности аутентификации Internet Information Server (IIS), анонимный доступ, методы аутентификации, учетная запись IUSR_

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

Однако в некоторых ситуациях анонимным доступом не обойтись. Обычно аутентификация требуется в двух случаях:

Читайте так же:
Графический процессор nvidia geforce gtx 1050

1) когда на Web -сервере находятся ресурсы, доступ к которым нужен не всем пользователям (проще говоря, чтобы задействовать систему разрешений);

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

Аутентификация в IIS , к сожалению, полностью основывается на системе безопасности Windows . Фактически мы можем предоставить доступ только тем пользователям, для которых у нас создана локальная учетная запись (или доменная учетная запись, если компьютер с IIS входит в домен). Конечно, по этой причине доступ на IIS со стандартными средствами можно предоставлять только пользователям локальной сети (или, например, очень ограниченному числу внешних партнеров). Рассчитывать на организацию системы аутентификации для пользователей из Интернета стандартными средствами не приходится (поскольку для каждого пользователя учетную запись Windows не создашь). Обычно для таких целей используются или самостоятельно созданные Web -приложения, или специальные надстройки на IIS , которые обеспечивают отдельную, независимую от Windows систему аутентификации. Ниже будет рассмотрены стандартные возможности аутентификации, а затем — дополнительные средства других производителей.

Настройку аутентификации стандартными методами предписывается производить из консоли Internet Information Services Manager -> свойства Web -сайта -> вкладка Directory Security -> кнопка Edit в группе Authentification and Access Control . При нажатии на эту кнопку открывается окно Authentification Method , в котором и производятся настройки параметров аутентификации. В этом окне вы можете:

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

О методах аутентификации необходимо рассказать подробнее:

  • IntegratedWindowsAuthentification — единственный метод (кроме анонимного доступа), доступный по умолчанию. При использовании этого метода используются те же хэши NTLM (или Kerberos — negotiate для Windows 2000/ XP /2003), что и при обычной аутентификации в Windows (например, при обращении к файлам на файл-сервере). Конечно, ни один броузер, кроме Internet Explorer , такой аутентификации не поддерживает. Необходимо отметить, что, если прав учетной записи IUSR недостаточно (или анонимный доступ вообще отключен) следующее, что делает Internet Explorer — отсылает NTLM -хэш (его версия зависит от версии операционной системы) текущей учетной записи на сервер IIS . Если аутентификация не прошла (или прошла, но у учетной записи не оказалось прав на Web -ресурс), то открывается всплывающее окно аутентификации, в котором пользователь имеет возможность ввести данные другой учетной записи;
  • DigestAuthentification — сравнительно новая технология (появилась только в Windows 2000/ IIS 5.0), основанная на открытых Интернет-стандартах (алгоритм хэширования MD 5 и RFC 2617). При использовании этого метода аутентификации сервер посылает специальную случайную последовательность символов — nonce — клиенту (для каждого сеанса она будет сгенерирована заново). Клиент принимает эту последовательность, на основе ее и своего пароля генерирует хэш по алгоритму MD 5 и пересылает ее серверу. Сервер, который производит такую же операцию и сравнивает полученные значения. Главной проблемой применения этого метода аутентификации является то, что IIS должен получить доступ к открытым паролям пользователей, которых по умолчанию нет и на контроллерах домена. Таким образом, чтобы этот метод аутентификации заработал, необходимо для учетных записей пользователей установить параметр " Store password using reversible encryption ", что обычно в защищенных сетях недопустимо.
  • BasicAuthentification — самый простой тип аутентификации, который поддерживается практически всеми броузерами. При этом имя пользователя и пароль посылаются почти открытым текстом (на самом деле они кодируются, во избежание попадания служебных символов, по алгоритму Base 64). Те менее, конечно, расшифровать эти данные не составит никакого труда — например, при помощи утилиты Base 64 Decoder (она умеет декодировать и некоторые другие форматы) из каталога прочее на компакт-диске. Поскольку передаются таким образом на самом деле имя и пароль учетной записи Windows , то последствия могут оказаться очень серьезными (если в сети запущен сниффер). Безопасно пользоваться этим методом аутентификации можно только при использовании SSL .
  • .NETPassportauthentification — возможность использовать для аутентификации централизованную систему . NET Passport от Microsoft . Не совсем понятно, зачем эта возможность помещена на графический интерфейс IIS Manager — использовать эту возможность могут только участники программы . NET Passport , фактически — очень ограниченный круг крупных Web -коммерсантов. Существует и множество других ограничений при использовании .NET Passport .

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

Еще несколько слов об служебных учетных записях и группах, имеющих отношение к IIS :

  • IUSR _имя_компьютера — об этой учетной записи уже говорилось, она предназначена для обеспечения анонимного доступа на сервер IIS и никаких дополнительных прав ей предоставлять не рекомендуется;
  • IWAM_имя_компьютера — еще одна гостевая учетная запись, которой не нужно давать лишние права. От имени этой учетной записи запускаются внешние процессы, порождаемые процессом INETINFO (то есть процессом Web -сервера). Иногда для работы Web 0-приложения этой учетной записи необходимо предоставить дополнительные права, например, на запись в каталог.
  • IIS _WPG — эта группа предназначена для предоставления прав в операционной системе приложениям CGI и ASP . NET , работающим на Web -сервере. Если у вас таких приложений нет, выдавать какие-либо разрешения этой группе не нужно.
  • ASPNET — как понятно из названия, эта учетная запись используется приложениями ASP . NET , работающими на сервере IIS . Если у вас не используется ASP . NET (не установлена как компонент IIS ), то этой учетной записи не будет. Этой учетной записи нужно предоставлять права, например, если приложению ASP . NET необходимо подключаться к SQL Server .

При помощи группы переключателей IP address and domain name restrictions можно также ограничить доступ к сайту по IP -адресам, целым IP -сетям или именам доменов DNS . Обычно такие возможности используются только в Интранет Web -серверах.

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector