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