Главная » Разное » Регистрация в программе франкенкит что это такое

Регистрация в программе франкенкит что это такое


как получить QR-код-пропуск для выхода из дома / Программы, ПО, сайты / iXBT Live

Вчера в магазинах приложений App Store и Play Market появилась программа «Госуслуги СТОП коронавирус». Это случилось примерно одновременно с выступлением Сергея Собянина, в котором он объявил о скором введении пропускного режима в Москве. Я не буду рассуждать о правовом статусе этих пропусков и тех, кто будет их проверять. Я просто расскажу, как выглядит это приложение, чего хочет и что в нём можно сделать.

UPD: уже после публикации этого поста Собянин рассказал о пропусках в Москве, которые с 13 апреля можно будет получать на mos.ru. Возможно, пропуска от Госуслуг будут «несовместимы» с московской системой.

UPD2: да, Минкомсвязи подтвердило, что в Москве будет использоваться своя цифровая платформа. А вот на портале госуслуг Московской области указано использовать именно «Госуслуги СТОП Коронавирус».

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

Первый вопрос к сознательному гражданину: «Как сам?». Есть много разных вариантов, но поскольку я здоров (или я так думаю), мне подходят два варианта: «Я здоров и нахожусь на самоизоляции» и «Я здоров и хожу на работу». В редакцию я сейчас наведываюсь редко, но никогда не знаешь, что за логику заложили в программу чиновники, поэтому на всякий случай выбираю вариант с работой.

Дальше нужно ввести данные об удостоверении личности — в моём случае о паспорте — и месте проживания. Всё это подхватывается из профиля Госуслуг. Но я ещё ввёл-таки фактический адрес. Раньше я этот пункт не заполнял, потому что… ну, не было причин делиться с государством такими сведениями. Теперь пришлось заполнить, иначе сложно будет объяснять, почему я так далеко от места проживания («прописки»). Ещё один пункт анкеты — селфи.

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

Странно, в общем. Но сфотографировался. И паспорт, и он же рядом с моим лицом. Мне же делают предложение, от которого я не смогу отказаться.

Здесь же нужно подтвердить, что нет никаких симптомов ОРВИ. А потом подтвердить, что я ознакомлен с правилами изоляции и ответственностью за их нарушение. Но здесь речь о тех, кто недавно вернулся из-за границы, заболел сам или контактировал с заболевшими.

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

Во-первых, можно пройти самоопрос (много стало «само» в последнее время), где указываются температура, пульс и наличие симптомов ОРВИ. Ну и здесь же можно сменить статус на «Болею и лечусь дома», например.

Ниже есть справка по самым насущным вопросам касательно карантина.

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

Если выбрать «На работу», то почему-то не спрашивают адрес, куда буду ехать. Я знаю, что мой работодатель передавал сведения о количестве сотрудников, без которых предприятие не обойдется в «нерабочие дни». Да, количество, а не поименный список. Может быть, приложения обновят?

После этого появляется экран с фотографией, адресом проживания, временем и причиной выхода из дома, счетчиком времени и QR-кодом.

В последнем закодирована всего лишь ссылка такого вида: https://www.gosuslugi.ru/checksession/1?id=b3ffe5f1-4b26-4bed-8959-7d7130dd5926.

Пока «сессия выхода» активна (и минут пять после её завершения) по ссылке открывается такая страница. На ней почему-то указано планируемая длительность выхода (12 часов), но это опять-таки за меня напланировали.

После завершения сессии по этому URL сервер начинает выдавать HTTP-статус 204 — «No content».

Почему-то нет истории выходов. После нажатия «Остановить» не остаётся никаких следов вылазки.

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

Вот и всё. Не болейте!

Практика подготовки иностранных слов с озвучкой для запоминания в программе Anki

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

Предполагается, что читатель уже имеет представление о методике интервального повторения и знаком с Anki. Но если не знаком – пора знакомиться.

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

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

Вот мой рецепт:


  1. Регистрируемся на AnkiWeb
  2. Устанавливаем Anki
  3. Устанавливаем плагин AwesomeTTS
  4. Добавляем в браузере закладки:
    • гугл переводчик
    • гугл таблицы
    • мультитран
  5. Готовим карточки
  6. Синхронизируемся

Регистрация на AnkiWeb

Регистрация не хитрая, но она дает возможность использования Anki на разных устройствах. Я пользуюсь Android-версией Anki для запоминания и PC-версией для создания новых карточек. Можно и не устанавливать приложение на смартфон, потому что заучивать карточки можно прямо на сайте под своим аккаунтом.

Адрес сайта: https://ankiweb.net/


Установка Anki

Качаем и устанавливаем Anki для PC. На момент написания статьи последней версией является 2.1.

Далее:


  1. Запускаем Anki и добавляем нового пользователя.


  2. Нажимаем Sync в главном окне программы и вводим данные вашего аккаунта:


Теперь прогресс обучения будет синхронизироваться с AnkiWeb.


Установка плагина AwesomeTTS

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

Итак:


  1. Переходим на страницу плагина
  2. В Anki выбираем: Tools → Add-ons → Get Add-ons… и вводим ID плагина:
  3. Перезапускаем Anki.

Добавляем в браузере закладки


  1. Из всех переводчиков мне более удобен продукт от гугл.
  2. Как дополнительный словарь я использую мультитран.
  3. Для импорта новых слова в Anki мы будем использовать гугл таблицы, поэтому нужно создать у себя в аккаунте таблицу: в первой колонке (это важно) будет иностранный вариант по возможности с примером в контексте, во второй – перевод.

Готовим карточки


Выписываем незнакомые слова

Пользуемся методом “корректорского зрения” для быстрого извлечения непонятных слов из иностранного текста с целью их запоминания.

Суть метода:


  1. Читаете очень быстро иностранный текст.
  2. Помечаете слова, значение которых вам не ясно.
  3. Выписываете эти слова, переводите в контексте и заучиваете (на этом этапе как раз используется Anki).
  4. Затем читаете текст еще раз, но уже с пониманием всех слов, потому что см. п.3.

Может быть метод как-то и называется по-другому (в комментариях подскажите), но думаю суть ясна.


Перевод

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

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

Перевод заносим в гугл-таблицу. Вот пример наполнения:

Теперь сохраняем таблицу в TSV: Файл → Скачать → TSV

Этот файл нужно импортировать в колоду Anki.


Импорт новых слов в Anki

Запускаем Anki, File → Import. Выбираем файл. Загружаем в колоду Default со следующими настройками:

У меня колода Default всегда содержит новые слова, к которым я еще не добавил озвучку.


Озвучка

Google Cloud Text-to-speech – это специализированный сервис, позволяющий качественно перевести текст в речевой вариант. Чтобы его использовать в Anki, нужно сгенерировать либо свой API ключ, либо тот, который предлагает автор плагина AwesomeTTS в документации (см. раздел API KEY).

В Anki кликаем по Browse, выбираем колоду Default, выделяем все импортированные карточки и выбираем из меню AwesomeTTS → Add audio to selected…

В появившемся окне выбираем сохраненный ранее профиль с сервисом Google Text-to-speech. Проверяем, что источник для озвучки и поле для вставки озвучки равны Front, и нажимаем Generate:

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

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


Синхронизация

Я использую Anki на PC для создания и группировки карточек по темам, т.к. это наиболее удобно делать именно в этой версии.

Заучиваю карточки в приложении для Android.

Выше я уже показал, как настроить синхронизацию Anki для PC с AnkiWeb.

После установки приложения для Android настройка синхронизации происходит еще проще.

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


Хотелки

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

SIP-регистрация, транк, софтфон и другие страшные слова облачных АТС / Voximplant corporate blog / Habr

Айти — необъятная отрасль знаний. Бывает, что пятнадцать лет делаешь разный софт, под разные операционки, на разных языках программирования. Вроде много всего знаешь. А потом шаг в сторону — а там Нарния SIP, RTP, SDP и PBX. Последние несколько месяцев я плотно занимаюсь голосовой телефонией и периодически ловлю себя на мысли, что для новичков эта область документирована не особо хорошо. Ну а если по какой-то теме еще не написано десять статей “xxx с нуля”, то это прекрасный повод написать Хабрапост для широкого круга читателей. Сегодня я расскажу небольшую, но интересную часть теорикрафта: как облачные системы телефонии взаимодействуют друг с другом и с телекомами. На примере VoxImplant, конечно же.


Основная часть взаимодействия происходит через связку протоколов и стандартов, условно называемых SIP-телефонией. Протокол SIP похож на HTTP: тот же plain text, заголовки, тела запросов, ответы. Но вместо запроса веб-страниц, протокол SIP контролирует голосовые и видеозвонки. Несмотря на 200-страничный RFC, сам протокол весьма лаконичный: он позволяет участникам регистрировать “телефоны”, инициировать звонок, отвечать на него и завершать звонок, а также предлагает несколько сервисных функций. Остальное выполняется через другие протоколы: параметры звонка передаются в теле SIP-сообщений, но кодированы они по протоколу SDP; cам звонок осуществляется по протоколу RTP или в шифрованном виде по SRTP.


Наиболее простой вариант взаимодействия, широко применяемый телекомами, — это транк. Вообще SIP trunking — это подключение абонентов не по телефонному кабелю, а через интернет по протоколу SIP. Но этот термин прижился и для коммуникаций типа “телеком-телеком” или “телеком-облако”. В создании транка участвуют обе взаимодействующие стороны. Вначале IP-адреса телекома добавляются в белый список на стороне облака VoxImplant: это позволит телекому совершать SIP-звонки к облаку без авторизации. Затем клиент связывается с телекомом и информирует его, что входящие звонки необходимо “приземлять” в облако. При этом используется SIP URI, соответствующий аккаунту и приложению пользователя, которое с помощью JavaScript-кода информирует облако, что с этими звонками делать дальше.

[email protected]

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


Если транк — это подключение от телекома в облако, то SIP-регистрация подключается в обратном направлении. Протокол SIP использует сообщение REGISTER, которое информирует сервер о том, что некое абонентское устройство (например, софтфон — программная реализация SIP-клиента) готово принимать звонки. Чтобы облако могло выступать в роли такого устройства, клиенту необходимо получить у телекома SIP-адреса, логины и пароли для своих номеров и добавить эту информацию в админку VoxImpant.

В противоположность транку, SIP-регистрация работает в обе стороны: имея логины и пароли, облако как принимает, так и совершает звонки по указанным номерам. Важное концептуальное отличие заключается в том, что SIP-регистрация — это часть протокола SIP (регулярно отправляемое сообщение REGISTER), в то время как транк — это просто практика использования SIP-решений.


Голая теория без практики мертва, поэтому в качестве примера я покажу, как подключить к VoxImplant номера телефонов популярного облачного решения Mango Office. Первое, что нужно сделать, — это получить SIP-информацию о номерах, которая доступна в разделе Сотрудники и группы в личном кабинете Mango Office, как описано в этой инструкции.

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

Более сложный пример — это настройка транка от Asterisk к облаку VoxImplant. Со стороны нашего облака нужно всего лишь добавить IP-адреса Asterisk в белый список (см. рисунок выше). А вот со стороны Asterisk конфигурация транка выглядит следующим образом:

[voximplant] type=friend host=testapp.testuser.voximplant.com secret=asterisk-pass-for-vox fromdomain=testapp.testuser.voximplant.com fromuser=asterisk remotesecret=vox-pass-for-asterisk

Учитывая возможность подстановки номера, с точки зрения клиента SIP-регистрация ничем не отличается от транка. Однако сотрудники телекомов не всегда готовы настраивать транк, а для многих облачных АТС это в принципе технически не предусмотрено. При этом SIP-регистрация позволяет интегрироваться с любым SIP-совместимым сервисом, будь то крупный провайдер телекоммуникационных услуг, инсталляция Asterisk или закрытый облачный сервис.

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

Обзор способов и протоколов аутентификации в веб-приложениях / DataArt corporate blog / Habr

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

  • Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
  • Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
  • Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

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

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

Аутентификация по паролю

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

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

HTTP authentication

Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:
  1. Сервер, при обращении неавторизованного клиента к защищенному ресурсу, отсылает HTTP статус “401 Unauthorized” и добавляет заголовок “WWW-Authenticate” с указанием схемы и параметров аутентификации.
  2. Браузер, при получении такого ответа, автоматически показывает диалог ввода username и password. Пользователь вводит детали своей учетной записи.
  3. Во всех последующих запросах к этому веб-сайту браузер автоматически добавляет HTTP заголовок “Authorization”, в котором передаются данные пользователя для аутентификации сервером.
  4. Сервер аутентифицирует пользователя по данным из этого заголовка. Решение о предоставлении доступа (авторизация) производится отдельно на основании роли пользователя, ACL или других данных учетной записи.

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

  1. Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.

    Пример HTTP аутентификации с использованием Basic схемы.
  2. Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.
  3. NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде. Эта схема не является стандартом HTTP, но поддерживается большинством браузеров и веб-серверов. Преимущественно используется для аутентификации пользователей Windows Active Directory в веб-приложениях. Уязвима к pass-the-hash-атакам.
  4. Negotiate — еще одна схема из семейства Windows authentication, которая позволяет клиенту выбрать между NTLM и Kerberos аутентификацией. Kerberos — более безопасный протокол, основанный на принципе Single Sign-On. Однако он может функционировать, только если и клиент, и сервер находятся в зоне intranet и являются частью домена Windows.

Стоит отметить, что при использовании HTTP-аутентификации у пользователя нет стандартной возможности выйти из веб-приложения, кроме как закрыть все окна браузера.
Forms authentication

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

Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.


Пример forms authentication.

Приложение может создать session token двумя способами:

  1. Как идентификатор аутентифицированной сессии пользователя, которая хранится в памяти сервера или в базе данных. Сессия должна содержать всю необходимую информацию о пользователе для возможности авторизации его запросов.
  2. Как зашифрованный и/или подписанный объект, содержащий данные о пользователе, а также период действия. Этот подход позволяет реализовать stateless-архитектуру сервера, однако требует механизма обновления сессионного токена по истечении срока действия. Несколько стандартных форматов таких токенов рассматриваются в секции «Аутентификация по токенам».

Необходимо понимать, что перехват session token зачастую дает аналогичный уровень доступа, что и знание username/password. Поэтому все коммуникации между клиентом и сервером в случае forms authentication должны производиться только по защищенному соединению HTTPS.
Другие протоколы аутентификации по паролю

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

Существует всего несколько мест, где можно передать username и password в HTTP запросах:

  1. URL query — считается небезопасным вариантом, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.
  2. Request body — безопасный вариант, но он применим только для запросов, содержащих тело сообщения (такие как POST, PUT, PATCH).
  3. HTTP header —оптимальный вариант, при этом могут использоваться и стандартный заголовок Authorization (например, с Basic-схемой), и другие произвольные заголовки.
Распространенные уязвимости и ошибки реализации
Аутентификации по паролю считается не очень надежным способом, так как пароль часто можно подобрать, а пользователи склонны использовать простые и одинаковые пароли в разных системах, либо записывать их на клочках бумаги. Если злоумышленник смог выяснить пароль, то пользователь зачастую об этом не узнает. Кроме того, разработчики приложений могут допустить ряд концептуальных ошибок, упрощающих взлом учетных записей.

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

  • Веб-приложение позволяет пользователям создавать простые пароли.
  • Веб-приложение не защищено от возможности перебора паролей (brute-force attacks).
  • Веб-приложение само генерирует и распространяет пароли пользователям, однако не требует смены пароля после первого входа (т.е. текущий пароль где-то записан).
  • Веб-приложение допускает передачу паролей по незащищенному HTTP-соединению, либо в строке URL.
  • Веб-приложение не использует безопасные хэш-функции для хранения паролей пользователей.
  • Веб-приложение не предоставляет пользователям возможность изменения пароля либо не нотифицирует пользователей об изменении их паролей.
  • Веб-приложение использует уязвимую функцию восстановления пароля, которую можно использовать для получения несанкционированного доступа к другим учетным записям.
  • Веб-приложение не требует повторной аутентификации пользователя для важных действий: смена пароля, изменения адреса доставки товаров и т. п.
  • Веб-приложение создает session tokens таким образом, что они могут быть подобраны или предсказаны для других пользователей.
  • Веб-приложение допускает передачу session tokens по незащищенному HTTP-соединению, либо в строке URL.
  • Веб-приложение уязвимо для session fixation-атак (т. е. не заменяет session token при переходе анонимной сессии пользователя в аутентифицированную).
  • Веб-приложение не устанавливает флаги HttpOnly и Secure для browser cookies, содержащих session tokens.
  • Веб-приложение не уничтожает сессии пользователя после короткого периода неактивности либо не предоставляет функцию выхода из аутентифицированной сессии.
Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.


Использование сертификата для аутентификации.

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

  1. Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
  2. Сертификат должен быть действительным на текущую дату (проверка срока действия).
  3. Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).


Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

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

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

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

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

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

  1. Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
  2. Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
  3. Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.


Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.

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

Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.


Пример применения аутентификации по ключу.

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

С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.


Пример аутентификации по ключу доступа, переданного в HTTP заголовке.

Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.

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

Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:

  1. Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
  2. Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
  3. Клиент аутентифицируется в SP-приложении при помощи этого токена.


Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.


Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

  1. Токен был выдан доверенным identity provider приложением (проверка поля issuer).
  2. Токен предназначается текущему SP-приложению (проверка поля audience).
  3. Срок действия токена еще не истек (проверка поля expiration date).
  4. Токен подлинный и не был изменен (проверка подписи).

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

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:
  1. Simple Web Token (SWT) — наиболее простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form. Стандарт определяет несколько зарезервированных имен: Issuer, Audience, ExpiresOn и HMACSHA256. Токен подписывается с помощью симметричного ключа, таким образом оба IP- и SP-приложения должны иметь этот ключ для возможности создания/проверки токена.

    Пример SWT токена (после декодирования).

    Issuer=http://auth.myservice.com&
    Audience=http://myservice.com&
    ExpiresOn=1435937883&
    UserName=John Smith&
    UserRole=Admin&
    HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w

  2. JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.

    Пример подписанного JWT токена (после декодирования 1 и 2 блоков).

    { «alg»: «HS256», «typ»: «JWT» }.
    { «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }.
    S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY
  3. Security Assertion Markup Language (SAML) — определяет токены (SAML assertions) в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений (statements) о пользователе. Подпись SAML-токенов осуществляется при помощи ассиметричной криптографии. Кроме того, в отличие от предыдущих форматов, SAML-токены содержат механизм для подтверждения владения токеном, что позволяет предотвратить перехват токенов через man-in-the-middle-атаки при использовании незащищенных соединений.
Стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

  1. Assertions — собственный формат SAML токенов в XML формате.
  2. Protocols — набор поддерживаемых сообщений между участниками, среди которых — запрос на создание нового токена, получение существующих токенов, выход из системы (logout), управление идентификаторами пользователей, и другие.
  3. Bindings — механизмы передачи сообщений через различные транспортные протоколы. Поддерживаются такие способы, как HTTP Redirect, HTTP POST, HTTP Artifact (ссылка на сообщения), SAML SOAP, SAML URI (адрес получения сообщения) и другие.
  4. Profiles — типичные сценарии использования стандарта, определяющие набор assertions, protocols и bindings необходимых для их реализации, что позволяет достичь лучшей совместимости. Web Browser SSO — один из примеров таких профилей.

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

Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:

В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):

После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).

Стандарты WS-Trust и WS-Federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

  • Формат и способы обмена метаданными о сервисах.
  • Функцию единого выхода из всех систем (single sign-out).
  • Сервис атрибутов, предоставляющий дополнительную информацию о пользователе.
  • Сервис псевдонимов, позволяющий создавать альтернативные имена пользователей.
  • Поддержку пассивных клиентов (браузеров) посредством перенаправления.

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Стандарты OAuth и OpenID Connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

> Попросить пользователя указать данные своей учетной записи? — плохой вариант.
> Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

  1. Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
  2. Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
  3. Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).


Взаимодействие компонентов в стандарте OAuth.

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

  1. Authorization Code — этот грант пользователь может получить от сервера авторизации после успешной аутентификации и подтверждения согласия на предоставление доступа. Такой способ наиболее часто используется в веб-приложениях. Процесс получения гранта очень похож на механизм аутентификации пассивных клиентов в SAML и WS-Federation.
  2. Implicit — применяется, когда у приложения нет возможности безопасно получить токен от сервера авторизации (например, JavaScript-приложение в браузере). В этом случае грант представляет собой токен, полученный от сервера авторизации, а шаг № 2 исключается из сценария выше.
  3. Resource Owner Password Credentials — грант представляет собой пару username/password пользователя. Может применяться, если приложение является «интерфейсом» для сервера ресурсов (например, приложение — мобильный клиент для Gmail).
  4. Client Credentials — в этом случае нет никакого пользователя, а приложение получает доступ к своим ресурсам при помощи своих ключей доступа (исключается шаг № 1).

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

  1. Зачастую API сервера ресурсов включает операцию, предоставляющую информацию о самом пользователе (например, /me в Facebook API). Приложение может выполнять эту операцию каждый раз после получения токена для идентификации клиента. Такой метод иногда называют псевдо-аутентификацией.
  2. Использовать стандарт OpenID Connect, разработанный как слой учетных данных поверх OAuth (опубликован в 2014 г.). В соответствии с этим стандартом, сервер авторизации предоставляет дополнительный identity token на шаге № 2. Этот токен в формате JWT будет содержать набор определенных полей (claims) с информацией о пользователе.

Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.

Заключение

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

Способ

Основное применение

Протоколы

По паролю

Аутентификация пользователей

HTTP, Forms

По сертификатам

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

SSL/TLS

По одноразовым паролям

Дополнительная аутентификация пользователей (для достижения two-factor authentication)

Forms

По ключам доступа

Аутентификация сервисов и приложений

-

По токенам

Делегированная аутентификация пользователей; делегированная авторизация приложений

SAML, WS-Federation, OAuth, OpenID Connect

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

Автор: Дмитрий Выростков, Solutions Architect в DataArt.

Честный ЗНАК - Регистрация в системе / Пошаговая инструкция

Честный Знак Регистрация

Зарегистрироваться не сложно, прочитав следующую информацию. Регистрация в системе Честный Знак занимает не много времени. Национальная Система Цифровой Маркировки Честный ЗНАК уже функционирует в экспериментальном режиме.

Оформить Электронную подпись

Регистрация «Под Ключ»+эл.подпись

Продавать не маркированные пачки сигарет в рознице можно до 1 июля 2020 года. С 1 июля 2020 года будет прекращен оборот немаркированной табачной продукции и будут

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

Участвовать в эксперименте

 

Шаг 1: Подать заявку на регистрацию

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

Шаг 2: Получить электронную подпись

Получить усиленную квалификационную электронную подпись. После оправки заявки на регистрацию на электронную почту придёт подробная инструкция по созданию УКЭП (Усиленной Квалификационной Электронной Подписи). Данную инструкцию вы можете скачать и изучить сейчас. Скачать инструкцию по созданию УКЭП.

УКЭП можно оформить во всех областных центрах и крупных городах. Все аккредитованные удостоверяете центры в РФ, их адреса и телефоны (список центров на сайте).

Оформить Электронную подпись

Подробней про плагин и поддерживает ли ваш компьютер эту систему в видео ниже.

Шаг 3: Сертификат УКЭП Честный Знак

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

Можно свободно скачать и изучить официальную инструкцию по ссылке выше. Далее идёт её краткое содержание:

  1. Установка программного обеспечения КриптоПро CSP.  Дистрибутив программы можно скачать с официального сайта https://www.cryptopro.ru/products Далее установить его. После перезагрузить компьютер.
  2. Для хранения ключей электронной подписи используйте носитель (токен), для него может потребоваться драйвер.
  3. Скачать корневой сертификат ПАК «Головной удостоверяющий центр» по ссылке http://pra-vo.gov.ru/uc/resourses_uc.html и установить его.
  4. Установить Сертификат. Пуск — Панель Управления — Сервис, затем нажать кнопку «Посмотреть сертификаты в контейнере» — «Обзор» — выбрать нужный — далее — установить.
  5. Установить плагин для браузера Криптонабор-ПРО по ссылке https://www.cryptopro.ru/products/cades/plugin После установки — перезагрузите браузер.
  6. Вход в личный кабинет Честный Знак по ссылке http://ismotp.crptech.ru или кнопке ниже.

Участвовать в эксперименте

Регистрация «Под Ключ»+эл.подпись

Шаг 4: Вход в личный кабинет

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

Если при входе появляется ошибка:

 

Значит не установлен корневой сертификат ГУЦ (указанный выше в пункте 3):

Затем необходимо следовать инструкциям «Мастера импорта сертификатов». На этапе импорта необходимо указать место хранения сертификатов «Доверенные корневые центры сертификации».

 

Шаг 5: Функции личного кабинета

После успешного входа в личный кабинет Честного Знака вам будут доступны все его функции, по маркировке, логистики и продажах товаров. ОГРНИП нужно указать по запросу в процессе регистрации.

Получить консультацию Честного ЗНАКа о дальнейшей работе в системе, необходимом оборудовании и ПО. В личном кабинете указаны все инструкции, согласно которым можно принять участие в эксперименте Национальная Система Цифровой Маркировки — «Честный ЗНАК».

Инструкция магазину для запуска продаж сигарет с маркировкой

После изучения процесса регистрации можно можно перейти на официальный сайт Честного Знака, что бы начать регистрацию:

Участвовать в эксперименте

Оформить Электронную подпись

Регистрация «Под Ключ»+эл.подпись

Смотрите также