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

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

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

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

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

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

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

security passwords

— Dryr
источник

Я полагаю, кто-то должен сослаться на это: xkcd:

— Надежность

@CandledOrange Обязательный XKCD ссылка

— Dryr

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

— Эрик Кинг,

Может быть, этот вопрос больше подходит для User Experience SE . Уже есть похожий вопрос с интересными ответами: избавитесь ли вы от поля пароля в форме регистрации .

— insertusername здесь

Электронная почта не является безопасным каналом связи. Не отправляйте пароли по электронной почте. Токены, которые действительны только в течение короткого периода времени (например, 24 часа), могут быть в порядке. Вы не можете избежать паролей, но можете поощрять использование менеджеров паролей: специальное программное обеспечение, функции браузера «запомнить мой пароль» и физические ноутбуки - все это законные стратегии. Предоставление пароля не поощряет хорошие привычки безопасности. Кроме того, добавьте параметры входа в систему, такие как «Войти в Google», где вы не храните пароли. Используйте внешние платежные системы, чтобы мне не пришлось доверять вашему сайту мои платежные реквизиты.

— Амон

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

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

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

— Christophe
источник

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

— Mouviciel

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

— Кристоф