Ключи доступа быстро становятся более безопасной, простой и быстрой альтернативой паролям, предлагая повышенную безопасность и удобство для пользователя. Чтобы полностью реализовать потенциал ключей доступа, необходимо тщательно продумать пользовательский опыт, связанный с их управлением. В этом документе изложены рекомендации и дополнительные функции для проектирования интуитивно понятной, безопасной и надежной системы управления ключами доступа.
Управление несколькими ключами доступа
Позвольте пользователям добавлять несколько паролей и использовать более одного поставщика. Но не позволяйте им добавлять более одного пароля для одной и той же учетной записи с одним и тем же поставщиком . Если пользователь теряет доступ к одному поставщику, например, когда платформа не поддерживает его, или пользователь теряет к нему доступ, он все равно может войти с другим паролем от другого поставщика. Такая настройка снижает риск блокировки учетной записи. Убедитесь, что ваша база данных поддерживает хранение нескольких паролей для одного пользователя.
Отображение списка зарегистрированных паролей
Ваш веб-сайт или приложение должны отображать зарегистрированные пароли в списке с ключевыми данными, чтобы помочь пользователям эффективно управлять ими. Этот снимок экрана иллюстрирует, как может выглядеть такая выделенная страница управления паролем. Он показывает, как пользователь может создавать пароли на нескольких платформах, и предоставляет централизованное место для управления ими.
Вот некоторые общие сведения и функции, которые могут отображаться на веб-сайтах и в приложениях о ключе доступа:
- Имя ключа доступа : Отображение имени ключа доступа, которое было указано при регистрации. В идеале это имя соответствует поставщику ключа доступа, на котором он был создан, на основе AAGUID . Если соответствующий поставщик ключа доступа не найден, то имя после информации об устройстве на основе строки агента пользователя должно быть приемлемым.
- Логотип поставщика ключа доступа : Отображение логотипа поставщика ключа доступа. Это помогает пользователю идентифицировать ключ доступа, которым он хочет управлять.
- Отметка времени создания и последнего использования ключа доступа : запись и отображение отметки времени создания ключа доступа и отметки времени последнего использования также может помочь пользователю идентифицировать ключ доступа, которым он хочет управлять.
- Индикатор отсутствия синхронизации : ключи доступа синхронизируются по умолчанию, но возможности синхронизации поставщиков ключей доступа все еще развиваются. Это распространенная путаница, когда ключ доступа не синхронизируется, несмотря на ожидания пользователя. Демонстрация неспособности ключа доступа к синхронизации может помочь пользователям прояснить эту путаницу.
- Кнопка удаления : Разрешить пользователям удалять ключ доступа. Подробнее см. в разделе Разрешить удаление ключа доступа .
- Кнопка «Изменить» : многие пользователи ценят возможность переименовывать ключ доступа. Например, когда есть несколько ключей доступа от одного поставщика ключей доступа, но с разными учетными записями поставщика. Представьте себе сохранение нескольких ключей доступа в разных учетных записях Google. Разрешив пользователю переименовывать ключ доступа, он может изменить его на имя, которое ему нравится.
- Браузер, ОС или IP-адрес последнего входа : необязательное предоставление сведений о последнем входе помогает пользователю идентифицировать подозрительные входы. Браузер, ОС или IP-адрес (или местоположение), используемые для входа, могут быть полезной информацией.
Разрешить удаление ключа доступа
Разрешить пользователям удалять ключ доступа. Это помогает им навести порядок в списке, например, когда пользователь переключается на новое устройство, но связанный с ним ключ доступа привязан к старому устройству. Это также полезно, когда злоумышленник захватывает учетную запись пользователя и создает ключ доступа для будущего использования.
Сообщить об обновлении списка паролей
Удаление ключа доступа удаляет его учетную запись и открытый ключ из базы данных сервера. Таким образом, ключ доступа исчезнет из списка зарегистрированных ключей доступа, и пользователю будет казаться, что он удален. Однако на самом деле он удаляется только с сервера, а ключ доступа, сохраненный у поставщика ключа доступа, все еще остается, что может вызвать путаницу. В следующий раз, когда пользователь попытается войти в систему, удаленный ключ доступа все еще будет отображаться как вариант входа. Но аутентификация с ним не удастся, поскольку соответствующий открытый ключ уже удален с сервера.
Чтобы избежать путаницы, важно поддерживать согласованность ключа доступа у поставщика ключа доступа и открытого ключа на сервере. Этого можно добиться , передав обновленный список ключей доступа поставщику ключа доступа . Если браузер и поставщик ключа доступа поддерживают API Signal, они могут обновить список ключей доступа и удалить ненужные ключи доступа. Если они не поддерживают API, предложите пользователю удалить ключ доступа вручную.
Удалить последний пароль
Если пользователь попытается удалить свой последний оставшийся ключ доступа для данной учетной записи, убедитесь, что он понимает, что ему придется войти с помощью другого варианта с большим количеством помех и потенциально меньшей защитой. Если это его единственный способ входа на ваш сайт, он не сможет войти снова. Сообщите пользователям, как они могут войти в систему в следующий раз, например, используя резервный метод, если он доступен, или предложите им зарегистрировать другой ключ доступа перед продолжением. Это хороший шанс собрать отзывы о том, почему они решили не использовать ключ доступа.
Разрешить создание новых паролей
Хотя есть возможность создавать пароли на протяжении всего пути пользователя (например, сразу после входа в систему), крайне важно иметь центральный узел, куда пользователи всегда могут перейти, чтобы создать новые пароли, удалить пароли и управлять паролями. Экран управления паролями — лучшее место для этого.
Чтобы создать поток пользователя ключа доступа, следуйте руководству разработчика Создание ключа доступа для входа без пароля . Для расширенной безопасности рассмотрите возможность разрешить пользователям создавать ключ доступа на аппаратном токене безопасности. Вы можете ожидать, что пользователи, которые готовы управлять ключами доступа, будут более осведомленными или опытными, поэтому разрешение им создавать ключ доступа на их ключе безопасности обеспечивает повышенную гибкость.
Чтобы разрешить сохранение паролей на аппаратном токене безопасности, оставьте authenticatorSelection.authenticatorAttachment неустановленным вместо того, чтобы устанавливать его на "platform" в запросе на создание паролей. Таким образом, браузер принимает как платформенные (устройство), так и перемещаемые аутентификаторы (ключ безопасности) без существенного отличия пользовательского опыта от разрешения только аутентификатора платформы. Возможность создания ключа безопасности на ключе безопасности отображается как вторичная опция.
Контрольный список
- Разрешить пользователям управлять ключами доступа на странице управления ключами доступа.
- Поддержка регистрации нескольких ключей доступа.
- Разрешите пользователям добавлять новые и гибкие типы паролей на странице управления.
- Отобразить имя ключа доступа.
- Укажите, является ли ключ доступа синхронизируемым или нет.
- Разрешить пользователям удалять открытый ключ с сервера.
- Сигнализировать списку паролей, когда связанный с ним открытый ключ удаляется с сервера.
Другие руководства по UX
- Общие руководства по ключам доступа UX
- Руководства по Android