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

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

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

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

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

Додаткова інформація для Bounty

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

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

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

Дякую всім

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

Як завжди було близько 5 відповідей, які я хотів би відзначити правильними з різних причин, але мені довелося вибрати найкращу - всі інші отримали +1. Дякую всім!

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

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

Подумайте про це: якщо користувачеві потрібно завантажити пароль, це тому, що він його забув. У такому випадку новий пароль такий же хороший, як і старий. Але один з недоліків поширених сьогодні механізмів скидання паролів полягає в тому, що генеровані паролі, що створюються в процесі операції скидання, - це, як правило, купа випадкових символів, тому користувачеві їх важко просто ввести правильно, якщо вони не копіюють n-n- пасти. Це може бути проблемою для менш кмітливих користувачів комп'ютерів.

Один із способів вирішити цю проблему - надати автоматично створені паролі, що представляють собою більш-менш природний текст. Хоча в рядках природної мови може не бути ентропії, яку має рядок випадкових символів однакової довжини, нічого не говорить про те, що у створеному автоматично створеному паролі потрібно мати лише 8 (або 10 або 12) символів. Отримайте авто-генеровану парольну фразу з високою ентропією, з'єднавши кілька випадкових слів (залиште пробіл між ними, щоб вони все ще були впізнавані та вводилися будь-хто, хто вміє читати). Шість випадкових слів різної довжини, напевно, простіше правильно ввести і впевнено, ніж 10 випадкових символів, і вони можуть мати і більшу ентропію. Наприклад, ентропія пароля з 10 символів, обраного випадковим чином з великого, нижнього регістру, цифри та 10 пунктуаційних символів (загалом 72 дійсних символів) мали б ентропію 61,7 біт. Використовуючи словник з 7776 слів (як використовує програмне забезпечення), який може бути випадковим чином обраний для шестисловної парольної фрази, ця парольна фраза матиме ентропію 77,4 біт. ДивітьсяПоширені питання щодо програмного забезпечення для програмного забезпечення для додаткової інформації.

• парольну фразу з приблизно 77 бітами ентропії: "визнати прозаїчний спалах таблиці гострого чуття"

• пароль із приблизно 74 бітами ентропії: "K: & $ R ^ tt ~ qkD"

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

Я розумію аргументи, що є захищені паролем активи, які насправді не мають високого рівня цінності, тому порушення пароля може не бути кінцем світу. Наприклад, я, мабуть, не хвилювався б, якщо 80% паролів, які я використовую на різних веб-сайтах, були порушені: все, що може статися, це те, що хтось спам або публікує під моїм іменем деякий час. Це не було б чудово, але це не так, як вони б увірвалися на мій банківський рахунок. Однак, враховуючи той факт, що багато людей використовують той самий пароль для своїх веб-форумів, як і для своїх банківських рахунків (і, можливо, бази даних національної безпеки), я вважаю, що було б найкраще обробляти навіть ці низькі значення паролів як не -відновлюваний.

Уявіть, що хтось замовив будувати велику будівлю - бар, скажімо так, - і відбувається така розмова:

Архітектор: Для будівлі такого розміру та місткості вам знадобляться пожежні виходи тут, тут і тут.
Клієнт: Ні, це занадто складно і дорого в обслуговуванні, я не хочу ні бічних, ні задніх дверей.
Архітектор: Пане, пожежні виходи не є необов'язковими, вони потрібні згідно з пожежним кодом міста.
Клієнт: Я не плачу вам сперечатися. Просто роби те, що я попросив.

Тоді архітектор запитує, як етично будувати цю будівлю без пожежних виходів?

У будівництві та машинобудуванні розмова, швидше за все, закінчиться так:

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

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

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

Не існує етичного чи відповідального способу зберігання паролів у відновлюваному вигляді. Період.

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

Я думаю, це насправді схоже на те, як працює агент відновлення Windows .

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

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

Ви не можете етично зберігати паролі для подальшого пошуку в простому тексті. Це так просто. Навіть Джон Скіт не може етично зберігати паролі для подальшого пошуку в простому тексті. Якщо ваші користувачі можуть отримати паролі в простому тексті якимось чином або іншим способом, то, можливо, теж може хакер, який виявить у вашому коді вразливість безпеки. І це не лише один пароль користувача, а всі вони.

Якщо у ваших клієнтів із цим проблеми, скажіть їм, що зберігання паролів може бути відносно закону. Тут, у Великобританії, в будь-якому випадку Закон про захист даних 1998 року (зокрема, Додаток 1, частина II, пункт 9) вимагає від контролерів даних застосовувати відповідні технічні заходи для збереження персональних даних, враховуючи, крім іншого, шкода, яка може бути заподіяна, якщо дані будуть порушені - що може бути значним для користувачів, які діляться паролями між сайтами. Якщо у них все ще виникають проблеми з вирішенням того, що це проблема, вкажіть їх на приклади реального світу, наприклад, цей .

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

Ось кілька публікацій у блозі, які я написав на цю тему:

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

Оновлення: зараз ми починаємо розглядати судові позови та судові переслідування проти компаній, які не захищають паролі своїх користувачів належним чином. Приклад: LinkedIn завдав судового позову про 5 мільйонів доларів США ; Компанія Sony оштрафувала 250 000 фунтів стерлінгів за хакерські дані PlayStation . Якщо я пригадую правильно, LinkedIn насправді шифрував паролі своїх користувачів, але шифрування, яке він використовував, було занадто слабким, щоб бути ефективним.

Прочитавши цю частину:

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

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

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

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

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

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

Майкл Брукс був досить голосним щодо CWE-257 - про те, що яким би методом ви не користувалися, ви (адміністратор) все одно можете відновити пароль. То як щодо цих варіантів:

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

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

У відповідь на це запитання було багато дискусій щодо проблем безпеки користувачів, але я хотів би додати згадки про переваги. Поки що я не бачив жодної законної переваги щодо збереження відновленого пароля в системі. Врахуйте це:

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

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

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

• Дозвольте користувачеві використовувати свою електронну адресу для свого імені. Я бачив незліченну кількість випадків, коли користувач забуває своє ім’я користувача, але мало хто забуває свою електронну адресу.
• Запропонуйте OpenID та дозвольте сторонній оплаті витрат на забудьку користувача.
• Легко зніміть обмеження пароля. Я впевнений, що ми всі були дуже роздратовані, коли якийсь веб-сайт не дозволяє вибрати потрібний пароль через непотрібні вимоги, такі як "ви не можете використовувати спеціальні символи" або "ваш пароль занадто довгий" або "ваш пароль повинен починатися з листом ». Крім того, якщо простота використання викликає більшу стурбованість, ніж надійність пароля, ви можете послабити навіть нерозумні вимоги, дозволяючи скорочувати паролі або не вимагати поєднання класів символів. З послабленими обмеженнями користувачі з більшою ймовірністю будуть використовувати пароль, який вони не забудуть.
• Не термін дії паролів.
• Дозвольте користувачеві повторно використовувати старий пароль.
• Дозвольте користувачеві вибрати власне запитання про скидання пароля.

Але якщо вам з якихось причин (і, будь ласка, скажіть нам причину) справді, дійсно, дійсно потрібно дійсно мати можливість відновити пароль, ви можете захистити користувача від потенційного компрометації інших облікових записів в Інтернеті, надавши їм не паролі, заснована на системі аутентифікації. Оскільки люди вже знайомі із системами імені користувача / пароля, і вони є добре вправленим рішенням, це було б в крайньому випадку, але, безумовно, існує маса креативних альтернатив паролям:

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

Відповідно до коментаря, який я виголосив на запитання:
один важливий момент був майже затьмарений майже всіма ... Моя початкова реакція була дуже схожа на @Michael Brooks, поки я не зрозумів, як @stefanw, що питання тут порушено вимоги , але це те, що вони є.
Але тоді мені сталося, що це може бути навіть не так! Тут відсутня точка - невимовна вартість активів програми. Простіше кажучи, для системи з низьким значенням цілком захищений механізм аутентифікації, що включає весь процес, буде надмірним і неправильним вибором безпеки.
Очевидно, що для банку "найкращі практики" є обов'язковими, і немає ніякого способу етичного порушення CWE-257. Але легко подумати про системи низької вартості, де це просто не варто (але простий пароль все-таки потрібен).

Важливо пам’ятати, справжня експертиза безпеки полягає у пошуку відповідних вигод, а не в догматичному розливі «найкращих практик», які кожен може читати в Інтернеті.

Як такий, я пропоную інше рішення:
Залежно від вартості системи та ТІЛЬКО ЯКЩО система належним чином має низьку вартість без «дорогого» активу (сама ідентифікація, включена), І є дійсні бізнес-вимоги, які роблять належний процес неможливо (або досить складно / дорого), І клієнт усвідомлює всі застереження ...
Тоді може бути доречним просто дозволити реверсивне шифрування, без спеціальних обручів, щоб проскочити через них.
Я зупиняюсь лише кажу, що взагалі не заважати шифруванню, тому що це дуже просто / дешево реалізувати (навіть з огляду на пропускне управління ключами), і це НЕЧЕМУ захищає (більше, ніж витрати на його реалізацію). Крім того, варто переглянути, як надати користувачеві оригінальний пароль, будь то електронною поштою, відображенням на екрані тощо.
Оскільки тут припущення, що значення викраденого пароля (навіть у сукупності) досить низьке, будь-яке з ці рішення можуть бути дійсними.

Оскільки триває жвава дискусія, насправді РІЗНОВІ жваві дискусії, у різних публікаціях та окремих темах коментарів я додам деякі пояснення та відповім на деякі дуже хороші моменти, які були порушені в інших місцях тут.

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

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

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

Знаєте, це смішно - я завжди вважав себе одним із фанатиків із безпеки, і я якось перебуваю на протилежному боці тих так званих "експертів з безпеки" ... Ну, правда - бо я фанатик, і справжній експерт із безпеки в реальному житті - я не вірю в розслідування догм (або найкращих практик) БЕЗ цього найважливішого аналізу ризиків .
"Остерігайтеся ревника безпеки, який швидко застосує все до пояса інструментів, не знаючи, перед чим захищається справжня проблема. Більше безпеки не обов'язково прирівнюється до доброї безпеки".
Аналіз ризиків та справжні фанатики безпеки вказували б на розумніший компроміс на основі вартості / ризику, заснований на ризику, потенційній втраті, можливих загрозах, додаткових пом'якшеннях тощо. Будь-який "експерт з питань безпеки", який не може вказати на обґрунтований аналіз ризику як на Основа для їхніх рекомендацій або підтримка логічних ходів, але натомість вважають за краще носити догми та КВС, навіть не розуміючи, як проводити аналіз ризику, - це нічого, однак Хаки безпеки, і їхня експертиза не варта туалетного паперу, на який вони надрукували.

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

Але перш ніж ми поговоримо про відповідні компроміси, які слід здійснити у цій СИТУАЦІЇ, давайте подивимось на очевидні ризики (очевидні, оскільки у нас немає всієї основної інформації щодо цієї ситуації, ми всі гіпотезуємо - оскільки питання полягає в тому, що гіпотетично ситуація може виникнути ...)
Припустимо, система НИЗЬКОЇ ЦІННОСТІ, але не настільки дрібна, що це доступ для громадськості - власник системи хоче запобігти випадковій себе, але "висока" безпека не настільки важлива, як простота використання. (Так, це законний компроміс з ACCEPT ризиком того, що будь-який досвідчений сценарій-малюк може зламати сайт ... Зачекайте, зараз APT не в моді ...?)
Наприклад, скажімо, я влаштовую простий сайт для великого сімейного зібрання, що дозволяє кожному замислитись над тим, куди ми хочемо поїхати в цю подорож у цьому році. Мене менше турбує якийсь анонімний хакер або навіть двоюрідний брат Фред, що притискається до неодноразових пропозицій повернутися до озера Вантанамананабікілікі, так як я про тетку Ерма, яка не зможе ввійти, коли їй потрібно. Тепер, тітка Ерма, будучи фізиком-ядерником, не дуже добре запам’ятовує паролі чи взагалі навіть не користується комп’ютерами… Тому я хочу зняти всі можливі для неї тертя. Знову ж таки, я НЕ турбуюся про хаки, я просто не хочу дурних помилок неправильного входу - я хочу знати, хто йде, і що вони хочуть.

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

• Виявляє себе за користувачів? Ні, я вже прийняв цей ризик, не цікаво.
• Злий адміністратор? Ну, можливо ... Але знову ж, мені байдуже, чи хтось може себе представити іншому користувачеві, ВНУТРІШНІЙ чи ні ... і все одно злий адміністратор отримає ваш пароль, незважаючи ні на що - якщо ваш адміністратор пішов погано, його гра все одно.
• Ще одне питання, яке було порушено, - це те, що особистість насправді ділиться між кількома системами. Ах! Це дуже цікавий ризик, який потребує уважного огляду.
  Дозвольте мені почати з твердження , що це не реальні особистості Thats загальні, швидше за доказ , або засвідчення справжності. Гаразд, оскільки загальний пароль фактично дозволить мені ввійти до іншої системи (скажімо, мого банківського рахунку чи gmail), це фактично однакова ідентичність, тому це просто семантика ... За винятком того, що це не так . У цьому сценарії ідентичність керується окремо кожною системою (хоча можуть бути сторонні системи ідентифікаторів, такі як OAuth - все-таки її відокремленість від ідентичності в цій системі - докладніше про це пізніше).
  Таким чином, основна суть ризику тут полягає в тому, що користувач охоче вводить свій (той самий) пароль у кілька різних систем - і тепер я (адміністратор) або будь-який інший хакер мого сайту отримаю доступ до паролів тітки Ерми для сайт ядерної ракети.

Хммм.

Вам щось тут здається?

Це повинно.

Почнемо з того, що захист системи ядерних ракет не є моєю відповідальністю , я просто будую майданчик для виїздів із сімейства фракінових (для моєї родини MY). То чия відповідальність це? Гм ... А як щодо системи ядерних ракет? Дух.
По-друге, якщо я хотів вкрасти чийсь пароль (той, хто, як відомо, неодноразово використовує один і той же пароль між захищеними сайтами, а не дуже захищеними) - чому б мені не хотілося зламати ваш сайт? Або бореться з вашим симетричним шифруванням? Goshdarnitall, я можу просто створити власний простий веб-сайт , дозволити користувачам підписатися, щоб отримувати ДУЖЕ ВАЖЛИВІ НОВИнки про все, що вони хочуть ... Puffo Presto, я "вкрав" їх паролі.

Так, освіта користувачів завжди повертається, щоб вкусити нас в hienie, чи не так?
І ви нічого не можете з цим зробити ... Навіть якщо ви МОЖЕТЕ хешувати свої паролі на своєму сайті, і робити все інше, про що може придумати TSA, ви додали захист до свого пароля НЕ ОДНО , ЩО вони збираються зберегти безладно вставляти свої паролі на кожен сайт, на який вони стикаються. НЕ ДАЙТЕ НЕ СПІВИТИ спробу.

Інакше кажучи, ви не володієте своїми паролями , тому перестаньте намагатися діяти так, як ви.

Отже, мої шановні експерти з питань безпеки, як стара жінка давала запитання у Венді: "ДЕ РИЗИК?"

Ще кілька моментів у відповіді на деякі питання, підняті вище:

• CWE не є законом, не регулюванням, ані стандартом. Це сукупність загальних слабких місць , тобто зворотного "Кращих практик".
• Питання спільної ідентичності є актуальною проблемою, але неправильно зрозумілою (або неправильно представленою) з боку наявних тут. Це питання обміну ідентичністю само по собі (!), А не про зламання паролів на малоцінних системах. Якщо ви ділитесь паролем між малоцінною та високоцінною системою, проблема вже є!
• До речі, попередній пункт насправді вказував би ПРОТИ на використання OAuth тощо, як для цих малоцінних систем, так і для високоцінних банківських систем.
• Я знаю, що це був лише приклад, але (на жаль) системи ФБР насправді не є найбільш захищеними. Не зовсім як сервери блогу вашої кішки, але вони не перевершують деякі більш безпечні банки.
• Розділене знання або подвійне управління ключами шифрування НЕ відбувається тільки у військових, адже PCI-DSS тепер вимагає цього в основному від усіх продавців, тому його вже не так далеко (якщо значення це виправдовує).
• Для всіх тих, хто скаржиться, що подібні питання - це те, що професія розробника виглядає так погано: саме такі відповіді роблять професію безпеки ще гіршою. Знову ж, аналіз ризиків, орієнтований на бізнес - це те, що потрібно, інакше ви робите себе марними. Крім того, що помиляюся.
• Я думаю, саме тому не годиться просто брати звичайного розробника і кидати на нього більше обов'язків з безпеки, не навчаючись думати інакше і шукати правильні компроміси. Без образи, для тих, хто ви тут, я все за це - але більше навчання в порядку.

Вау. Який довгий пост ...
Але щоб відповісти на ваше первісне запитання, @Shane:

• Поясніть замовнику правильний спосіб робити речі.
• Якщо він все ж наполягає, поясніть ще дещо, наполягайте, сперечайтесь. Киньте істерику, якщо потрібно.
• Поясніть БІЗНЕС-РИЗИК йому. Деталі хороші, цифри кращі, демонстрація в прямому ефірі, як правило, найкраща.
• ЯКЩО ВИНАГАЄ наполягати та наводити вагомі ділові причини - саме час надати вам судовий виклик:
  чи цей веб-сайт недоцільний? Це справді ділова справа? Це досить добре для вас? Чи немає інших ризиків, які ви можете врахувати, які переважали б діючі причини бізнесу? (І звичайно, клієнт НЕ шкідливий сайт, але це так.
  Якщо так, просто йдіть прямо вперед. Не варто витрачати зусиль, тертя та втраченого використання (у цій гіпотетичній ситуації), щоб встановити необхідний процес. Будь-яке інше рішення (знову ж таки, у цій ситуації) - це поганий компроміс.

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

Як щодо будинку на півдорозі?

Зберігайте паролі із сильним шифруванням та не вмикайте скидання.

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

Ви можете "продати" це як захищений механізм скидання паролів.

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

Тож кроки були б:

1. Користувач реєструється на вашому сайті (звичайно над SSL), ще не встановивши пароль. Авторизуйте їх автоматично або введіть тимчасовий пароль.
2. Ви пропонуєте зберегти їх відкритий ключ PGP для подальшого пошуку пароля.
3. Вони завантажують свій відкритий PGP-ключ.
4. Ви просите їх встановити новий пароль.
5. Вони подають свій пароль.
6. Ви хеште пароль, використовуючи найкращий доступний алгоритм хешування паролів (наприклад, bcrypt). Використовуйте це під час перевірки наступного входу.
7. Ви шифруєте пароль відкритим ключем і зберігаєте його окремо.

Якщо користувач запитає свій пароль, ви відповісте зашифрованим (не хешованим) паролем. Якщо користувач не бажає мати можливість отримати свій пароль у майбутньому (він зможе відновити його лише до створеного сервісом), кроки 3 та 7 можна пропустити.

Я думаю, що справжнє питання, яке ви повинні задати собі, таке: "Як я можу краще переконати людей?"

У мене те саме питання. І в той же спосіб я завжди думаю, що хтось зламає мою систему, це не питання "якщо", а "коли".

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

• шифрувати за допомогою: openssl_encrypt (рядок $ data, метод $ $, рядок $ пароль)
  • PHP керівництво .
• аргументи даних :
  • конфіденційна інформація (наприклад, пароль користувача)
  • серіалізувати, якщо це необхідно, наприклад, якщо інформація є масивом даних, як декілька чутливої ​​інформації
• аргумент пароля : використовуйте інформацію, яку знає лише користувач:
  • номерний знак користувача
  • номер соціального страхування
  • номер телефону користувача
  • ім'я матері користувача
  • випадкова рядок, що надсилається електронною поштою та / або SMS-повідомленнями під час реєстрації
• метод arg :
  • виберіть один метод шифрування, наприклад "aes-256-cbc"
• НІКОЛИ не зберігайте інформацію, використану в аргументі "пароль", в базі даних (або в будь-якому місці в системі)

У разі необхідності відновлення цих даних просто скористайтеся функцією "openssl_decrypt ()" і попросіть у користувача відповідь. Наприклад: "Щоб отримати пароль, дайте відповідь на питання: Який номер вашого мобільного телефону?"

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

PS 2 : для інформації про кредитні картки, наприклад "покупка одним клацанням", я використовую пароль для входу. Цей пароль хеширується в базі даних (sha1, md5 і т. Д.), Але під час входу я зберігаю звичайний текстовий пароль у сеансі або в непостійному (тобто в пам'яті) захищеному файлі cookie. Цей звичайний пароль ніколи не залишається в базі даних, адже він завжди залишається в пам'яті, знищеному в кінці розділу. Коли користувач натискає кнопку "одним клацанням покупки", система використовує цей пароль. Якщо користувач увійшов у систему за допомогою такої послуги, як facebook, щебетати тощо, я підкажую пароль ще раз під час покупки (нормально, це не повністю "натискання") або потім використовую деякі дані служби, яку користувач використовував для входу (як ідентифікатор facebook).

Забезпечення облікових даних не є двійковою операцією: безпечно / незахищено. Безпека полягає в оцінці ризику і вимірюється на континуумі. Фанатики з безпеки ненавидять думати таким чином, але потворна правда полягає в тому, що нічого не є абсолютно безпечним. Штриховані паролі із суворими вимогами до пароля, зразки ДНК та сканування сітківки є більш безпечними, але ціною розвитку та досвіду користувача. Паролі прямого тексту набагато менш безпечні, але їх дешевше реалізувати (але їх слід уникати). Зрештою, це зводиться до аналізу витрат / вигод від порушення. Ви реалізуєте безпеку на основі цінності даних, що захищаються, та її часового значення.

Яка вартість того, щоб чийсь пароль вийшов на природу? Яка вартість себеособлення в даній системі? Для комп'ютерів ФБР вартість може бути величезною. Для одноразового п'ятисторінкового веб-сайту Боба вартість може бути незначною. Професіонал надає варіанти своїм клієнтам, а якщо стосується безпеки, викладає переваги та ризики будь-якої реалізації. Це вдвічі, якщо клієнт вимагає чогось, що може поставити їх під загрозу через недотримання галузевих стандартів. Якщо клієнт спеціально вимагає двостороннього шифрування, я б гарантував, що ви задокументуєте свої заперечення, але це не заважатиме вам реалізувати найкращим чином. Зрештою, це гроші клієнта. так,

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

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

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

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

Я реалізую багатофакторні системи аутентифікації для життя, тому для мене цілком природно думати, що ви можете або скинути, або відновити пароль, тимчасово використовуючи один менший фактор для автентифікації користувача лише для робочого процесу скидання / відпочинку. Зокрема, використання OTP (одноразових паролів) як деяких додаткових факторів зменшує значну частину ризику, якщо вікно часу не вистачає для запропонованого робочого процесу. Ми з великим успіхом реалізували програмні генератори OTP для смартфонів (які більшість користувачів уже носять із собою). Перш ніж з’являться скарги на комерційний плагін, я говорю про те, що ми можемо знизити ризики збереження паролів, які можна легко отримати або скинути, коли вони не є єдиним фактором, який використовується для автентифікації користувача.

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

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

• Q1. Які фактичні причини користувач наполягає на доступі до простого тексту, що зберігається паролем? Чому вона має таку велику цінність?

Інформація про те, що користувачі старші чи молоді, насправді не відповідає на це запитання. Але як бізнес-рішення можна прийняти без належного розуміння стурбованості клієнта?

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

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

Ще одне запитання, яке я бачив:

• Q2. Якщо користувач не пам’ятає пароль в першу чергу, чому старий пароль має значення?

І ось тут можлива відповідь. Якщо у вас кішка називається "miaumiau" і використовувала її ім'я як пароль, але ви це забули, чи хотіли б вам нагадати, що це таке, або, швидше, надіслали щось на кшталт "# zy * RW (ew"?)

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

Я просто намагаюся зрозуміти причину. Але якою б не була причина, це не причина, яку потрібно вирішити.

Як користувач, я хочу, щоб речі були простими! Я не хочу важко працювати!

Якщо я заходжу на сайт новин, щоб прочитати газети, я хочу набрати 1111 як пароль і пройти все !!!

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

Чи зберігає сайт мою "приватну" інформацію? Новини, які я читаю сьогодні? Тоді це проблема сайту, а не моя! Чи показує сайт приватну інформацію автентифікованому користувачеві? Тоді не показуйте це в першу чергу!

Це лише для того, щоб продемонструвати ставлення користувача до проблеми.

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

Поводження з втраченими / забутими паролями:

Ніхто не повинен мати можливість відновити паролі.

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

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

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

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

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

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

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

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

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

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

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

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

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

Через огляд та нагляд всі оператори знали, що якщо вони зловживають привілеєм відкрити конверт, вони підлягають негайному звільненню та можливому кримінальному переслідуванню.

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

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

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

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

Також я розумію (з Інтернету), що (нібито) деякі алгоритми, такі як MD5, вже не вважаються безпечними. Я не можу сам судити про це, але це щось, що слід враховувати.

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

Зберігайте незакріплене шифрування пароля в БД сайту (давайте назвемо його "pass-a"), як це роблять звичайні люди :)
на кожного нового користувача (або зміну пароля) зберігайте звичайну копію пароля у віддаленій БД. використовувати ідентифікатор сервера, ідентифікатор користувача та "pass-a" як складовий ключ для цього пароля. ви навіть можете використовувати двонаправлене шифрування пароля, щоб краще спати вночі.

Тепер для того, щоб хтось отримав і пароль, і його контекст (id сайту + ідентифікатор користувача + "pass-a"), він повинен:

1. зламати БД веб-сайту, щоб отримати пару ("pass-a", ідентифікатор користувача).
2. отримати ідентифікатор веб-сайту з якогось конфігураційного файла
3. знайти і зламати в БД віддалених паролів.

ви можете контролювати доступність служби пошуку паролів (виставляти її лише як захищену веб-службу, дозволяти лише певну кількість завантажень паролів на день, робити це вручну тощо) і навіть додатково стягувати плату за цю "спеціальну систему безпеки".
Сервер БД пошуку паролів досить прихований, оскільки він не обслуговує багато функцій і може бути краще захищений (ви можете налаштувати дозволи, процеси та послуги щільно).

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

Ще один варіант, який ви, можливо, не розглядали, - це дозволити дії електронною поштою. Це трохи громіздко, але я реалізував це для клієнта, якому потрібні користувачі «поза» своєї системи для перегляду (лише читання) певних частин системи. Наприклад:

1. Після реєстрації користувача він отримує повний доступ (як звичайний веб-сайт). Реєстрація повинна містити електронний лист.
2. Якщо потрібні дані або дія, і користувач не пам’ятає свій пароль, він все одно може виконати дію, натиснувши спеціальну кнопку « надіслати мені електронну пошту для дозволу », прямо біля звичайної кнопки « надіслати ».
3. Потім запит надсилається на електронний лист із гіперпосиланням із запитом, чи хочуть вони виконати дію. Це схоже на посилання електронної пошти для скидання пароля, але замість скидання пароля воно виконує разову дію .
4. Потім користувач натискає "Так", і він підтверджує, що дані повинні бути показані або дія, виконувати дані, виявити дані тощо.

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

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

Засоліть хеш-код користувача як звичайний. Під час входу користувача дозвольте пароль користувача (після засолювання / хешування), а також дозвольте збігу того, що користувач буквально ввів.

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

В основному, зробіть сольовий / хешований пароль також паролем "звичайний текст".