Featured

Опыт применения технологии Рутокен для регистрации и авторизации пользователей в системе (часть 1)

Хороший денек! Желаю поделиться своим опытом по этой теме.

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

В данном примере употребляется Рутокен ЭЦП 2.0.

Для работы с сиим Рутокеном нужно установить драйвер на windows.

Для windows, установка 1-го только драйвера, обеспечивает установку всего, что необходимо, чтоб ОС увидела ваш Рутокен и с ним можно было работать.

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

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

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

В данном примере рассмотрена мысль реализации метода авторизации юзера в системе с внедрением схемы chеllange-response.

Сущность идеи в последующем:

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

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

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

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

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

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

    Если возвратиться к нашей задачке, то решение кажется естественным. Необходимо каким-то образом создать собственный удостоверяющий центр. Но перед сиим необходимо разобраться, а на основании чего же удостоверяющий центр должен выдавать сертификат юзеру, ведь он о нем ничего не понимает. (К примеру его имя, фамилия и т.д.) Есть таковая штука, которая именуется запрос на сертификат. Подробнее про этот эталон можно взглянуть, к примеру, на википедии ru.wikipedia.org/wiki/PKCS
    Мы будем применять версию 1.7 — PKCS#10.

    Опишем метод формирования сертификата на Рутокене (первоисточник — документация):

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

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

    Источник

    Zeen is a next generation WordPress theme. It’s powerful, beautifully designed and comes with everything you need to engage your visitors and increase conversions.

    Ещё
    Важность растяжки: преимущества стретчинга для здоровья, риски и советы от тренера