В декабре 2014 года я опубликовал статью «Реализовать ли вы пароль без входа? Это расширилось на статьях, таких как Пароли Джастина Бэлтропа Устаревшие и Бен Браун Пришло ли время для входа без пароля? Проект Passwordless для Node.js вдохновил других, включая опции для PHP и Ruby .
Я упоминал о рассмотрении аутентификации без пароля для клиентского проекта. Я рад сообщить, что он работает уже несколько месяцев и был откровением. Подробнее об этом в ближайшее время — но сначала давайте подведем итоги …
Что такое аутентификация без пароля?
Мы используем одни и те же методы аутентификации, разработанные на заре Интернета. К сожалению, пароли все чаще ломаются:
- Люди редко создают надежные пароли. Опросы показывают, что каждый десятый аккаунт использует что-то из двадцати самых популярных паролей. «123456» используется более чем на 4% счетов; «Пароль» остается вторым наиболее часто используемым.
- Люди используют один и тот же ужасный пароль на нескольких сайтах. Если вам случится взломать чей-то логин на Facebook, вы, вероятно, сможете получить доступ к его учетной записи PayPal. Ваш единственный пароль так же хорош, как и безопасность самой слабой системы, которую вы используете.
- Взломы корпораций становятся все более распространенными и привлекают внимание средств массовой информации. Это простой способ сделать себе имя, отомстить или потворствовать шантажу. Немногие компании готовы к актам кибертерроризма, и, несмотря на обычные заявления о «устойчивых изощренных атаках» , многие нарушения — это простые инъекции SQL, вызванные плохими методами разработки.
- С точки зрения кодирования, аутентификация утомительна и ошибки сделаны. Проверка учетных данных — это начало ваших проблем: вам нужно убедиться, что в безопасности нет взломов, хэш-строк с использованием надежных (и медленных) алгоритмов, разрешить пользователям сбрасывать забытые пароли и отвечать на звонки в службу поддержки от запутанных пользователей, которые, по-видимому, не могут запомнить или введите короткую строку правильно.
- Альтернативные решения, такие как биометрия или OAuth, зависят от аппаратного обеспечения или подходящих учетных записей социальных сетей. Немногие сайты реализуют это хорошо, и для некоторых пользователей все еще необходимо вернуться к методам электронной почты / пароля.
Предпосылка аутентификации без пароля состоит в том, что пароли не нужны, когда большинство пользователей имеют защищенные личные учетные записи, такие как электронная почта и SMS. Приложения могут использовать эти системы:
- Для входа пользователь посещает сайт и вводит идентификатор, например адрес электронной почты.
- Им отправляется сообщение со ссылкой; они нажимают на нее и входят в систему.
Другими словами, приложение создает случайный одноразовый пароль и шепчет его пользователю всякий раз, когда ему нужен доступ. Это похоже на процесс сброса вашего пароля — что многие пользователи делают каждый логин в любом случае! Электронная почта — очевидный выбор, но можно использовать любую другую службу обмена сообщениями, такую как SMS, Slack, Skype, обмен мгновенными сообщениями или даже прямые сообщения Twitter. Несколько вариантов могут быть предложены, если вы не хотите полагаться на одну систему.
Это немного сложнее за кулисами, чтобы гарантировать, что только один человек может использовать ссылку для входа. Общий процесс выглядит следующим образом:
- После ввода сервер проверяет, существует ли учетная запись для адреса электронной почты.
- Сервер создает два токена, такие как 24-символьные шестнадцатеричные GUID, и связывает оба с этой попыткой входа в систему. Первый токен отправляется обратно на устройство входа в систему — обычно в виде файла cookie браузера. Второй токен закодирован в ссылке, отправленной пользователю по электронной почте.
- При щелчке по ссылке сервер получит оба токена и проверит их по одной попытке входа в систему. При желании он может выполнить дополнительные проверки, чтобы убедиться, что ссылка была нажата в течение нескольких минут, а IP-адрес и строка агента пользователя браузера не изменились.
- Если все проверяется, запускается реальный сеанс и пользователь входит в систему. Если что-то не получается, все связанные токены могут быть признаны недействительными; невозможно использовать их снова.
Преимущества аутентификации без пароля:
- Это значительно проще для пользователей. Нет паролей для создания или хранения. Вам не нужна учетная запись социальной сети или стороннее программное обеспечение, кроме доступа к вашей системе обмена сообщениями. Невозможно зарегистрироваться без действительных учетных данных.
- Это более безопасно. Пароли не хранятся и взломать или угадать нечего. Даже если кто-то перехватит сообщение, у него будет только один из двух токенов, и он не сможет войти.
- Это рентабельно. Там меньше кода для разработки и развертывания. Код входа в основном обрабатывается другой службой с надежной защитой. Ваша служба поддержки избавлена от бесконечных проблем с паролями.
Где можно использовать аутентификацию без пароля?
Вход в систему занимает немного больше времени, но также и использование менеджера паролей! Аутентификация без пароля может быть предложена для приложений, которые имеют достаточно длительные периоды ожидания сеанса или когда пользователям нужен только нечастый доступ. Торговые сайты, социальные сети, форумы, системы продажи билетов и управления контентом — хорошие примеры использования.
Было бы странно использовать проверку подлинности без пароля в системе обмена сообщениями, поскольку для входа в систему вам потребуется другая! Также вы не хотите, чтобы ваш банк зависел исключительно от AOL в отношении их безопасности, хотя вторичные процессы идентификации могут дополнить его.
Без пароля можно рассмотреть, если вы создаете новое приложение. Однако обновление существующего приложения многими пользователями, имеющими пароли, является более проблематичным. Я предлагаю параллельно выполнять аутентификацию без пароля, а не переключаться на новый процесс входа в систему в одночасье. Предложите его на выбор — особенно пользователям, которые сбрасывают свой пароль — и оцените его использование через несколько месяцев, чтобы определить, является ли он жизнеспособным.
Тест в реальном мире
Я реализовал проверку подлинности без пароля в новом приложении, используемом клиентом для нескольких сотен внутренних сотрудников и внешних клиентов. Около половины пользователей обладают хорошими ИТ-навыками и имеют ежедневный доступ, поэтому их сеансы редко заканчиваются. Другая половина в основном менеджеры, которые входят в систему один или два раза в месяц — многие забывают или набирают пароли.
Самая большая проблема: клиенты должны быть убеждены .
«Без пароля» звучит небезопасно, и мало кто видел его в других местах. Мне повезло: у клиента был один технически подкованный руководитель проекта, который понимал концепцию. Даже тогда я согласился добавить пароли, если что-то не получится.
С этого момента было просто плыть. По техническим причинам мне пришлось интегрировать собственную реализацию, а не полагаться на стороннюю библиотеку. Это заняло менее одного дня, и не было необходимости в обычном управлении паролями, хэшировании и сбросе ерунды, которую мы обычно разрабатываем и тестируем.
Самый большой бонус: пользователи понимают аутентификацию без пароля . Процесс прост, но лучше всего предоставить простые инструкции на всех этапах. Например:
- Ссылка для входа была отправлена вам по электронной почте. Пожалуйста, проверьте папку со спамом, если она не пришла.
- Пожалуйста, нажмите на эту ссылку, чтобы войти … У вас есть 10 минут, чтобы открыть эту ссылку в том же браузере.
Никто не был смущен. Никто не боролся. Никто не хвалил систему, но никто не жаловался; люди приняли процесс, и он не стал им мешать. Количество связанных с паролем проблем входа в систему сократилось с трех или четырех в неделю до нуля.
Вывод
Я не могу утверждать, что аутентификация без пароля работает повсюду, но опыт был в основном положительным. Я новообращенный. Все мои приложения будут без пароля. Некоторые клиенты могут быть недовольны, но я просто добавлю в форму логина пустое поле пароля и проигнорирую его!
Вы внедрили аутентификацию без пароля? Это был хороший или плохой опыт?