Під час створення облікового запису краще сформувати пароль автоматично та надіслати його користувачеві чи дозволити користувачеві створити свій власний пароль?

Це питання виникло сьогодні під час обговорення з колегою про сторінку "створити обліковий запис" для веб-сайту, над яким ми працюємо.

Думка мого колеги полягає в тому, що ми повинні зробити реєстрацію максимально швидкою та безпроблемною, тому нам слід просто попросити у користувача його електронну пошту та подбати про інше.

Я погоджуюся з наміром, але у мене є кілька проблем:

Так як ми генеруємо пароль, ми маємо відповідальність , щоб переконатися , пароль достатньо сильний
На моєму досвіді, стикаючись з нерозбірливим паролем, користувачі, ймовірно, записують його у свій пост
Користувачі, які не записують пароль, мають велику ймовірність забути його. Це означає, що їм доведеться регулярно запитувати новий пароль, і це нікому не цікаво

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

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

security passwords

— Сушарка
джерело

Я припускаю, що хтось повинен посилатися на це: xkcd: Сила пароля

— candied_orange

@CandledOrange Обов'язкове посилання XKCD

— Dryr

Як споживач, момент, коли я використовую ваш сайт, і ви генеруєте для мене пароль, - це момент, коли я видаляю свій обліковий запис.

— Ерік Кінг

Можливо, це питання більше підходить для User Experience SE . Вже є подібне запитання з цікавими відповідями: чи не позбудетеся ви поля пароля у формі реєстрації .

— insertusernamehere

Електронні листи не є захищеним каналом зв'язку. Не надсилайте паролі електронною поштою. Токени, які дійсні лише короткий час (наприклад, 24 години), можуть бути нормальними. Ви не можете уникнути паролів, але ви можете заохотити використання менеджерів паролів: спеціальне програмне забезпечення, функції браузера "запам'ятати мій пароль", а фізичні ноутбуки - це все законна стратегія. Надання пароля не заохочує хороших звичок безпеки. Крім того, застосуйте параметри входу, як-от "увійти в Google", де ви не зберігаєте паролі. Використовуйте зовнішні процесори платежів, щоб мені не довелося довіряти вашому сайту мої платіжні дані.

— амон

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

Однак канал електронної пошти, як відомо, не є небезпечним. Це означає, що пароль можна було перехопити. Таким чином, цей підхід слід розглядати лише в тому випадку, якщо згенерований пароль використовується лише один раз, при першому вході в систему, і якщо це гарантується, що користувач повинен його змінити.

Прямий підхід є більш безпечним, в тому сенсі, що підключення tls / ssl до вашого веб-сайту набагато складніше перехопити, не помітивши.

— Крістоф
джерело

Зазвичай обидва підходи використовуються разом: введіть електронну пошту та пароль, а потім отримайте електронний лист із посиланням на активацію.

— mouviciel

@mouviciel так, en effet. Цей двоступеневий підхід із паролем та посиланням здається найпоширенішим підходом, що застосовується, і звичайно не без підстав :-) Це безпечніше, оскільки загалом посилання активації використовується лише для активації, а не для входу. Для ОП це потребує розробки логіки для надсилання посилання активації та відстеження активації на рахунок.

— Крістоф