Каждое десятилетие мы становимся свидетелями появления действительно революционного технологического прорыва. Я помню после OpenID в середине 00-х, читая некоторые из ранних постов в блогах, и в конце концов наблюдая, как OAuth вытеснил его. Это значительно упроститло способ входа большинства пользователей на веб-сайты. 

Интересно, мы сейчас наблюдаем такой момент с протоколом простого, быстрого и надежного входа (SQRL)?

SQRL - это децентрализованный протокол входа в систему и аутентификации, выпущенный исследователем безопасности Стивом Гибсоном. Это протокол, который работает как комбинация OAuth и менеджера паролей. Как и OAuth, он включает процесс входа в систему с помощью 1 кнопки (или QR-кода), просто нажмите на ссылку «authenticate with sqrl», и вы в системе. Как и менеджер паролей, это приложение живет на вашем телефоне, компьютере или в браузере.

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

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

Краткий список преимуществ

Подход на стороне клиента имеет несколько уникальных преимуществ и устраняет многие проблемы с текущей схемой имени пользователя / пароля:

Сервер не хранит ваш пароль (нулевая защита). 

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

Сервер не знает, кто вы.

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

На практике, я могу попросить вас указать имя пользователя, но из-за псевдонима SQRL у сайта не будет возможности узнать, что «ohryan» также является @ohryan. в Твиттере.

Вы не можете быть отслежены.

Поскольку SQRL генерирует уникальные открытые ключи для каждого домена, протокол не разрешает межсайтовое отслеживание таким же образом, как OAuth.

Ваша личность не может быть взломана

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

Открытый стандарт

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

Некоторые проблемы

На мой взгляд, у SQRL есть одна действительно большая проблема и несколько более мелких проблем.

Основная проблема: нет механизма деавторизации

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

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

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

Фишинг как бы тривиален

SQRL зависит от возможности пользователя сканировать произвольные QR-коды, чтобы получить доступ к сайту. Можно представить себе сценарий, в котором плохой актер может выдать себя за ваш банк, создаст поддельный SQRL QR-код на www.mybankk.com , надеясь, что вы не заметите орфографическую ошибку, а затем впоследствии запросите банковскую информацию.

Дело в том, что OAuth уязвим для такой же попытки фишинга. Можно подделать весь процесс «входа в Google», и если пользователь не будет обращать пристальное внимание на доменное имя, то он будет не в курсе подделки.

Насколько мне известно, такие попытки фишинга никогда не осуществлялись против OpenID или OAuth (хотя я могу ошибаться).

Новая парадигма

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