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

11

Этот вопрос возник сегодня, когда мы обсуждали с коллегой страницу «Создать учетную запись» для веб-сайта, над которым мы работаем.

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

Я согласен с намерением, но у меня есть несколько опасений по этому поводу:

  • Так как мы генерируем пароль, мы имеем ответственность , чтобы убедиться , пароль достаточно силен
  • По моему опыту, когда пользователь сталкивается с непонятным паролем, пользователи, скорее всего, запишут его в сообщении
  • Пользователи, которые не записывают пароль, скорее всего, забудут его. Это означает, что им придется регулярно запрашивать новый пароль, и это никому не интересно

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

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

Dryr
источник
3
Я полагаю, кто-то должен сослаться на это: xkcd:
Надежность
@CandledOrange Обязательный XKCD ссылка
Dryr
11
Как потребитель, когда я использую ваш сайт и вы генерируете для меня пароль, это момент, когда я удаляю свою учетную запись.
Эрик Кинг,
4
Может быть, этот вопрос больше подходит для User Experience SE . Уже есть похожий вопрос с интересными ответами: избавитесь ли вы от поля пароля в форме регистрации .
insertusername здесь
19
Электронная почта не является безопасным каналом связи. Не отправляйте пароли по электронной почте. Токены, которые действительны только в течение короткого периода времени (например, 24 часа), могут быть в порядке. Вы не можете избежать паролей, но можете поощрять использование менеджеров паролей: специальное программное обеспечение, функции браузера «запомнить мой пароль» и физические ноутбуки - все это законные стратегии. Предоставление пароля не поощряет хорошие привычки безопасности. Кроме того, добавьте параметры входа в систему, такие как «Войти в Google», где вы не храните пароли. Используйте внешние платежные системы, чтобы мне не пришлось доверять вашему сайту мои платежные реквизиты.
Амон

Ответы:

11

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

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

Прямой подход более безопасен в том смысле, что соединение tls / ssl с вашим веб-сайтом гораздо сложнее перехватить, не заметив.

Christophe
источник
2
Обычно оба подхода используются вместе: введите адрес электронной почты и пароль, а затем получите письмо, содержащее ссылку для активации.
Mouviciel
@mouviciel да, на самом деле. Этот двухэтапный подход с паролем и ссылкой, кажется, является наиболее распространенным подходом, и, конечно, не без причины :-) Он безопаснее, потому что в целом ссылка активации используется только для активации, а не для входа в систему. Для ОП это потребует разработки логики для отправки ссылки активации и отслеживания активации в учетной записи.
Кристоф