Hypersign (HID) - решение для аутентификации

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

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

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

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

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

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

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

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

Facebook узнает, путешествуете ли вы с помощью MakeMyTrip или покупаете что-то на Amazon!

и это становится еще одной проблемой конфиденциальности для пользователя.

Почему социальный вход не используется на предприятиях?

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

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

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

Постановка задачи

Подводя итог, можно выделить две стороны:

Перспектива конечного пользователя

  • Контроль: конечный пользователь не может контролировать свои данные. Хотя имена пользователей и пароли указаны, фактические данные хранятся у IDP, что дает им возможность использовать их не по назначению.
  • Согласие: эти IDP часто не принимают согласия пользователя перед тем, как поделиться своими данными. т.е. случай Cambridge analytica.
  • Отслеживание: IDP может даже отслеживать, где и что делает пользователь.

Перспектива поставщика услуг:

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

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

Дело не в том, что мы можем полностью удалить IDP (это то, что мы имели право? Когда у нас не было SSO). Роль IPD имеет решающее значение, поскольку они проверяют данные, и в результате поставщик услуг получает предварительно проверенные данные, поэтому как поставщику услуг, так и пользователю не нужно снова проходить процесс проверки. Но вот вопрос:

«Разумно ли подумать о решении, в котором IDP не хранит никаких пользовательских данных (следовательно, действует как сервер без сохранения состояния), но поставщик услуг (или проверяющая сторона) получает проверенные данные непосредственно от конечного пользователя?»

Hypersign (HID)

Хотя вышеупомянутый вопрос кажется нереальным, но только для разговора, представьте, если это так, что произойдет?

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

Hypersign - это протокол аутентификации, сохраняющий конфиденциальность для предприятия. Он использует такие технологии, как PKI и блокчейн, чтобы предоставить конечным пользователям возможность контролировать свои данные, а поставщикам услуг - возможность проверять учетные данные, не обращаясь к поставщику удостоверений. Кроме того, Hypersign можно легко интегрировать с существующими системами IAM, такими как Okta, Auth0 и Keycloak, для обеспечения аутентификации без пароля. 

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

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

Superhero.com реализует Hypersign

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

Что такое superhero.com?

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

Архитектура

Здесь,

  • Сервер Superhero становится IDP, который проверяет данные пользователя и выдает SuperheroAuthCredential.
  • Мобильный кошелек Superhero становится пользовательским агентом, в котором хранится SuperheroAuthCredential.
  • Website1 и Website2 - поставщики услуг, которые проверяют учетные данные.

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

Путешествие пользователя

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

  • ГЛАВНАЯ СТРАНИЦА

  • СТРАНИЦА ПРОФИЛЯ

Сервер Superhero проверяет данные пользователя, например, отправляя электронное письмо или отправляя OTP по телефону, в зависимости от того, какие данные необходимо проверить. На этом этапе сервер Superhero действует как сервер без гражданства - означает , что он не хранитuser data. На основе этих данных сервер Superhero выдает SuperheroAuthCredentialпользователю по электронной почте документ с криптографической подписью (называемый ).

Конечный пользователь загружает SuperheroAuthCredentialиз своей электронной почты в мобильное приложение, сканируя QR-код. Кроме того, конечный пользователь может просматривать подробные сведения об учетных данных в самом приложении.

  • СТРАНИЦА СПИСОК УЧЕТНЫХ ДАННЫХ

  • УЧЕТНАЯ ИНФОРМАЦИЯ

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

  • ПЕРЕД ВХОДОМ

  • ПОСЛЕ ВХОДА

Заключение

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