Найкращий спосіб реалізації "забутого пароля"? [зачинено]

Я шукаю найкращий метод для реалізації функції "забутий пароль".

У мене виходить дві ідеї:

1. Коли користувач натискає забутий пароль, користувачеві потрібно ввести ім'я користувача, електронну пошту та, можливо, дату народження чи прізвище. Потім повідомлення з тимчасовим паролем буде надіслано на рахунок електронної пошти користувача. Користувач використовує тимчасовий пароль для входу та скидає свій пароль.

2. Аналогічно, але електронний лист міститиме посилання, щоб дозволити користувачу скинути свій пароль.

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

Оновлення: переглянуто у травні 2013 року для кращого підходу

1. Користувач вводить своє ім'я користувача та натискає "забутий пароль". Я також рекомендую можливість ввести адресу електронної пошти замість імені користувача, оскільки імена користувачів іноді теж забуваються.
2. Система має таблицю password_change_requestsз колонами ID, Timeі UserID. Коли новий користувач натискає кнопку, в таблиці створюється запис. У Timeколонці міститься час, коли користувач натискав кнопку «Забули пароль». Це IDрядок. Створюється довга випадкова рядок (скажімо, GUID), а потім хеширується як пароль (що є окремою темою саме по собі). Потім цей хеш використовується як "ідентифікатор" в таблиці.
3. Система надсилає користувачеві електронний лист, який містить посилання в ньому. Посилання також містить початковий рядок ідентифікатора (до хешування). Посилання буде виглядати приблизно так: http://www.mysite.com/forgotpassword.jsp?ID=01234567890ABCDEF. Сторінка Forgotpassword.jsp повинна мати можливість відновити параметр ідентифікатора. Вибачте, я не знаю Java, тому не можу бути більш конкретним.
4. Коли користувач натискає посилання в електронній пошті, він переміщується на вашу сторінку. Сторінка отримує IDURL-адресу, знову хеширує її та перевіряє таблицю. Якщо такий запис є і не перевищує, скажімо, 24 годин, користувачеві надається запит на введення нового пароля .
5. Користувач вводить новий пароль, натискає ОК, і всі живуть щасливо після… до наступного разу!

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

1. Користувач переходить на сторінку "забув мій пароль" і вводить своє ім'я користувача або електронну пошту (що б не було унікальним), щоб подати запит на скидання пароля.

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

3. Знайдіть обліковий запис користувача. Збережіть тимчасовий пароль (зазвичай GUID) та часову позначку проти запису рахунку. Надішліть користувачеві електронний лист із тимчасовим паролем.

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

5. Подивіться на запис користувача, і якщо поточний час знаходиться в межах визначеного часового обмеження (наприклад, 1 година) часової позначки, збереженої на кроці 2, тоді хеш і збережіть новий пароль. (Очевидно, лише якщо тимчасові паролі відповідають!). Видаліть тимчасовий GUID та часову позначку.

Головне тут полягає в тому, що користувачеві надсилається електронний лист тимчасового пароля, який дозволить їм змінити свій пароль. Первісно збережений пароль (його слід хеш!) Ніколи не змінюється на тимчасовий пароль у випадку, якщо користувач його запам'ятав.

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

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

У своїй статті Трой Хант відзначає кілька чудових моментів - все, що ви хотіли знати про створення функції безпечного скидання пароля . Найбільш релевантні уривки:

[T] ось два загальних підходу:

1. Створіть новий пароль на сервері та надішліть його електронною поштою
2. Надішліть унікальну URL-адресу електронною поштою, яка полегшить процес скидання

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

...

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

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

...

Що ми хочемо зробити, це створити унікальний маркер, який можна надіслати електронною поштою як частину URL-адреси скидання, а потім відповідати запису на сервері поряд з обліковим записом користувача, підтверджуючи, що власник облікового запису електронної пошти справді намагається скинути пароль. Наприклад, маркер може бути "3ce7854015cd38c862cb9e14a1ae552b" і зберігається в таблиці поряд з ідентифікатором користувача, який виконує скидання, і тим часом, коли генерується маркер (більше про це за мить). Коли електронний лист надсилається, він містить таку URL-адресу, як "Скинути /? Id = 3ce7854015cd38c862cb9e14a1ae552b", і коли користувач завантажує це, сторінка перевіряє наявність токена і, отже, підтверджує особу користувача та дозволяє пароль бути зміненим.

...

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

...

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

Він робить ще багато хороших моментів щодо уникнення витоків інформації, CAPTCHA, двофакторної аутентифікації та, звичайно, основних найкращих практик, таких як хешування паролів. Я думаю, що важливо відзначити, що я не погоджуюся з Троєю щодо корисності питань безпеки, віддаючи перевагу скептицизму Брюса Шнейера до цієї практики :

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

Я піду:

1. Запитайте у користувача електронну пошту, перевірити електронну пошту зареєстровано
2. Створіть GUID та надішліть його на цей електронний лист
3. Ще не скидайте пароль
4. Користувач натискає посилання, а потім повинен ввести новий пропуск
5. Скиньте пароль лише після того, як користувач перебуває на вашому сайті та натиснув кнопку скидання після введення нового пропуску.
6. Зробіть цей GUID терміном дії протягом короткого періоду часу, щоб зробити його більш безпечним.

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

Утримуйтесь від надсилання будь-якої особистої інформації, наприклад паролів та інформації про доходи електронною поштою, оскільки вона може стати ВЕЛИКОЮ ВІДМОВНОЮ для вас та вашої організації, якщо така інформація була виточена або викрадена. Подумайте про безпеку серйозно. Просто потрібно один інцидент, щоб усі цегли впали.

Щодо пошуку пароля, уважно ознайомтеся з найкращими практиками забутого пароля .

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

Редагувати: оновлене посилання

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

• Відображення половини тимчасового пароля, коли особистість користувача підтверджена (питання безпеки, адреса електронної пошти тощо), а інша половина надсилається до облікового запису електронної пошти. Якщо обліковий запис електронної пошти було порушено, малоймовірно, що той самий чоловік також встиг здійснити атаку "посередник". (Побачено на шлюзі уряду Великобританії)

• Підтвердження ідентичності електронною поштою та іншим носієм - наприклад, кодом, надісланим через текст на зареєстрований мобільний телефон. (Побачено на eBay / PayPal)

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

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

(Якщо база даних не зламана, але тоді нічого не є безпечним).

Ось три дуже хороших посилання, які надають інформацію про скидання паролів:

1. http://jtauber.com/blog/2006/03/20/account_management_patterns/

2. (Не дозволяйте користувачам підтверджувати за допомогою GET): http://www.artima.com/forums/flat.jsp?forum=106&thread=152805&start=15&msRange=15

3. http://fishbowl.pastiche.org/archives/docs/PasswordRecovery.pdf

Сподіваюся, що це допомагає. Вони напевно допомогли мені зрозуміти проблему.

Я б застосував унікальні адреси електронної пошти для всіх облікових записів.

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

Обліковий запис електронної пошти користувача є найслабшим посиланням у цьому сценарії.

Ніколи не надсилайте користувачеві пароль. Навіть якщо воно генерується автоматично. Найкращий підхід (рекомендується та використовується ДАНС та іншими):

1. На сторінці забутого пароля запитайте електронну пошту / ідентифікатор користувача та НОВИЙ пароль від користувача.
2. Надішліть посилання на збережений електронний лист для цього облікового запису за допомогою посилання для активації.
3. Коли користувач натисне на це посилання, увімкніть новий пароль.

Якщо він не натисне посилання протягом 24 годин або більше, відключіть його (щоб він більше не змінював пароль).

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