Как я должен этично подходить к хранению паролей пользователей для последующего извлечения открытого текста?

https://stackoverflow.com/questions/2283937

21-09-2019
|

Вопрос

Поскольку я продолжаю создавать все больше и больше веб-сайтов и веб-приложений, меня часто просят хранить пароли пользователей таким образом, чтобы их можно было восстановить, если / когда у пользователя возникнет проблема (либо отправить ссылку на забытый пароль по электронной почте, передать их по телефону и т.д.) Когда я могу, я яростно борюсь с этой практикой и делаю много ‘дополнительного’ программирования, чтобы сделать возможным сброс пароля и административную помощь без сохранения их фактического пароля.

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

В идеальном мире люди часто обновляли бы пароли и не дублировали бы их на множестве разных сайтов — к сожалению, я знаю МНОГИХ людей, у которых одинаковый пароль для работы / дома / электронной почты / банка, и они даже добровольно предоставили его мне, когда им понадобилась помощь.Я не хочу быть тем, кто несет ответственность за их финансовый крах, если мои процедуры безопасности базы данных по какой-то причине не сработают.

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

Дополнительная информация для получения вознаграждения

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

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

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

Спасибо всем

Это был забавный вопрос, вызвавший много споров, и мне он понравился.В конце концов, я выбрал ответ, который одновременно сохраняет безопасность пароля (мне не придется хранить обычный текст или восстанавливаемые пароли), но также позволяет указанной мной базе пользователей входить в систему без основных недостатков, которые я обнаружил при обычном восстановлении пароля.

Как всегда, было около 5 ответов, которые я хотел бы отметить как правильные по разным причинам, но мне пришлось выбрать лучший - все остальные получили оценку + 1.Спасибо всем!

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

Решение

Как насчет того, чтобы применить другой подход или взгляд на эту проблему?Спросите, почему пароль должен быть в открытом виде:если это так, чтобы пользователь мог получить пароль, то, строго говоря, вам не нужно восстанавливать установленный им пароль (они все равно не помнят, что это такое), вы должны иметь возможность дать им пароль, который они можешь использовать.

Думаю об этом:если пользователю нужно получить пароль, это потому, что он его забыл.В этом случае новый пароль так же хорош, как и старый.Но одним из недостатков распространенных механизмов сброса паролей, используемых сегодня, является то, что сгенерированные пароли, созданные в ходе операции сброса, обычно представляют собой набор случайных символов, поэтому пользователю сложно просто правильно их ввести, если он не скопирует-n- вставить.Это может стать проблемой для менее опытных пользователей компьютеров.

Одним из способов решения этой проблемы является предоставление автоматически генерируемых паролей, которые представляют собой более или менее текст на естественном языке.Хотя строки на естественном языке могут не обладать той энтропией, которую имеет строка случайных символов одинаковой длины, ничто не говорит о том, что ваш автоматически сгенерированный пароль должен состоять только из 8 (или 10, или 12) символов.Получите автоматически сгенерированную парольную фразу с высокой энтропией, соединив вместе несколько случайных слов (оставьте между ними пробел, чтобы их мог узнавать и набирать любой, кто умеет читать).Шесть случайных слов разной длины, вероятно, легче правильно и уверенно набрать, чем 10 случайных символов, и они также могут иметь более высокую энтропию.Например, энтропия 10-значного пароля, случайным образом составленного из прописных и строчных букв, цифр и 10 символов пунктуации (всего 72 действительных символа), будет иметь энтропию 61,7 бита.Используя словарь из 7776 слов (используемый Diceware), который можно случайно выбрать для парольной фразы из шести слов, энтропия парольной фразы будет равна 77,4 бита.См. Часто задаваемые вопросы о кубиках для получения дополнительной информации.

парольная фраза с энтропией около 77 бит:"признаюсь, проза бликовая таблица острого чутья"
пароль с энтропией около 74 бит:"К:&$R^tt~qkD"

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

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

Другие советы

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

Архитектор: Для здания такого размера и вместимости вам понадобятся пожарные выходы здесь, здесь и здесь.
Клиент: Нет, это слишком сложно и дорого в обслуживании, мне не нужны никакие боковые или задние двери.
Архитектор: Сэр, пожарные выходы не являются необязательными, они необходимы в соответствии с городским пожарным кодексом.
Клиент: Я плачу тебе не за то, чтобы ты спорил.Просто сделай то, о чем я просил.

Спрашивает ли тогда архитектор, как этично построить это здание без пожарных выходов?

В строительной и машиностроительной отрасли разговор, скорее всего, закончится примерно так:

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

Компьютерное программирование не может быть лицензированный профессия, но люди часто, кажется, удивляются, почему наша профессия не пользуется таким же уважением, как профессия строителя или инженера-механика - что ж, не будем искать дальше.Те профессии, к которым предъявляются мусорные (или откровенно опасные) требования, просто откажутся.Они знают, что это не повод говорить: "Ну, я сделал все, что мог, но он настоял, и я должен делать то, что он говорит". Они могут лишиться лицензии за это оправдание.

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

Не существует этичного или ответственного способа хранения паролей в восстанавливаемой форме.Точка.

Вы можете зашифровать пароль + соль с помощью открытого ключа.Для входов в систему просто проверьте, соответствует ли сохраненное значение значению, рассчитанному на основе пользовательского ввода + соль.Если наступит момент, когда пароль необходимо будет восстановить в открытом виде, вы можете расшифровать его вручную или полуавтоматически с помощью закрытого ключа.Закрытый ключ может храниться в другом месте и может быть дополнительно зашифрован симметрично (в этом случае для расшифровки пароля потребуется вмешательство человека).

Я думаю, что это действительно похоже на то, как Агент восстановления Windows работает.

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

Не сдавайся.Оружие, которое вы можете использовать, чтобы убедить своих клиентов, — это неоспоримость.Если вы можете восстановить пароли пользователей с помощью любого механизма, вы дали их У клиентов есть законный механизм неотказуемости, и они могут отказаться от любой транзакции, которая зависит от этого пароля, поскольку поставщик не может доказать, что он не восстанавливал пароль и не пропускал транзакцию через себя.Если пароли правильно хранятся в виде дайджестов, а не зашифрованного текста, это невозможно, следовательно, либо конечный клиент сам выполнил транзакцию, либо нарушил свою обязанность соблюдать осторожность в отношении паролей.пароль.В любом случае ответственность лежит исключительно на нем.Я работал над делами, где суммы исчислялись сотнями миллионов долларов.Это не то, что вы хотите ошибиться.

Вы не можете этично хранить пароли для последующего поиска в виде открытого текста.Это так просто.Даже Джон Скит не может этично хранить пароли для последующего поиска в виде открытого текста.Если ваши пользователи каким-то образом могут получить пароли в виде обычного текста, то, возможно, то же самое сможет сделать и хакер, обнаруживший уязвимость безопасности в вашем коде.И это не просто пароль одного пользователя, но все они.

Если у ваших клиентов есть проблемы с этим, скажите им, что хранение паролей с возможностью восстановления является нарушением закона.Во всяком случае, здесь, в Великобритании, Закон о защите данных 1998 года (в частности, Приложение 1, часть II, параграф 9) требует от контролеров данных использовать соответствующие технические меры для обеспечения безопасности персональных данных, принимая во внимание, среди прочего, вред, который может быть причинен, если данные будут скомпрометированы, что может быть значительным для пользователей, использующих пароли на разных сайтах.Если им все еще трудно осознать тот факт, что это проблема, укажите им на примеры из реальной жизни, например: Вот этот.

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

Вот пара сообщений в блоге, которые я написал на эту тему:

Обновлять: теперь мы начинаем видеть судебные иски и преследования против компаний, которые не могут должным образом защитить пароли своих пользователей.Пример: LinkedIn подали коллективный иск на 5 миллионов долларов; Sony оштрафовали на 250 тысяч фунтов за взлом данных PlayStation.Если я правильно помню, LinkedIn на самом деле шифровал пароли своих пользователей, но используемое им шифрование было слишком слабым, чтобы быть эффективным.

После прочтения этой части:

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

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

Мне остается только гадать, требует ли какое-либо из этих требований наличия системы восстанавливаемых паролей.Например:Тетя Мейбл звонит и говорит: "Ваша интернет-программа не работает, я не знаю свой пароль"."Хорошо, - говорит беспилотник из службы поддержки клиентов, - позвольте мне проверить несколько деталей, а затем я дам вам новый пароль.При следующем входе в систему он спросит вас, хотите ли вы сохранить этот пароль или изменить его на что-то, что вам будет легче запомнить ".

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

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

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

Майкл Брукс довольно громко высказался о CWE-257 - о том факте, что какой бы метод вы ни использовали, вы (администратор) все равно можете восстановить пароль.А как насчет этих вариантов:

Зашифруйте пароль с помощью Кого-то другого открытый ключ - какой-то внешний авторитет.Таким образом, вы не сможете восстановить его лично, и пользователю придется обратиться к этому внешнему органу и попросить восстановить свой пароль.
Зашифруйте пароль, используя ключ, созданный на основе второй парольной фразы.Выполняйте это шифрование на стороне клиента и никогда не передавайте его на сервер в открытом виде.Затем, чтобы восстановиться, снова выполните расшифровку на стороне клиента, повторно сгенерировав ключ на основе входных данных.По общему признанию, этот подход в основном использует второй пароль, но вы всегда можете попросить их записать его или использовать старый подход с секретным вопросом.

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

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

Выигрывает ли пользователь от того, что ему высылают пароль по электронной почте?Нет.Они получают больше пользы от одноразовой ссылки для сброса пароля, которая, как мы надеемся, позволит им выбрать нужный пароль. будет помни.
Получает ли пользователь выгоду от отображения своего пароля на экране?Нет, по той же причине, что и вышеописанная;они должны выбрать новый пароль.
Выигрывает ли пользователь от того, что сотрудник службы поддержки сообщает ему пароль?НЕТ;опять же, если сотрудник службы поддержки сочтет запрос пользователя на ввод пароля надлежащим образом аутентифицированным, пользователю будет выгоднее получить новый пароль и возможность его изменить.Кроме того, телефонная поддержка обходится дороже, чем автоматический сброс пароля, так что компания также не выигрывает.

Похоже, что единственные, кто может извлечь выгоду из восстанавливаемых паролей, - это те, у кого злонамеренный умысел или сторонники некачественных API, которые требуют обмена паролями сторонних разработчиков (пожалуйста, никогда не используйте указанные API!).Возможно, вы сможете выиграть свой спор, правдиво заявив своим клиентам, что компания не получает никаких выгод, а только обязательства, храня восстанавливаемые пароли.

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

Разрешите пользователю использовать свой адрес электронной почты в качестве имени пользователя.Я видел бесчисленное множество случаев, когда пользователь забывал свое имя пользователя, но лишь немногие забывали свой адрес электронной почты.
Предложите OpenID и позвольте третьей стороне оплатить расходы, связанные с забывчивостью пользователя.
Ослабьте ограничения по паролю.Я уверен, что все мы были невероятно раздражены, когда какой-нибудь веб-сайт не разрешал использовать предпочитаемый вами пароль из-за бесполезных требований вроде "вы не можете использовать специальные символы", или "ваш пароль слишком длинный", или "ваш пароль должен начинаться с буквы". Кроме того, если простота использования вызывает большую озабоченность, чем надежность пароля, вы могли бы ослабить даже не глупые требования, разрешив более короткие пароли или не требуя сочетания классов символов.При ослаблении ограничений пользователи с большей вероятностью будут использовать пароль, который они не забудут.
Срок действия паролей не истекает.
Разрешить пользователю повторно использовать старый пароль.
Разрешите пользователю самому выбрать вопрос о сбросе пароля.

Но если вы по какой-то причине (и, пожалуйста, сообщите нам причину) действительно, действительно, действительно если вам необходимо иметь возможность восстанавливать пароль, вы могли бы защитить пользователя от потенциальной компрометации других его онлайн-аккаунтов, предоставив ему систему аутентификации без использования пароля.Поскольку люди уже знакомы с системами имени пользователя / пароля и они представляют собой хорошо отработанное решение, это было бы последним средством, но, несомненно, существует множество творческих альтернатив паролям:

Позвольте пользователю выбрать цифровой PIN-код, предпочтительно не 4-значный, и предпочтительно только в том случае, если защищены от попыток грубой силы.
Попросите пользователя выбрать вопрос с коротким ответом, ответ на который известен только ему, который никогда не изменится, который он всегда будет помнить и который не возражает, чтобы об этом узнали другие люди.
Попросите пользователя ввести имя пользователя, а затем нарисуйте легко запоминающуюся фигуру с достаточным количеством перестановок для защиты от угадывания (см. это изящное фото о том, как G1 делает это для разблокировки телефона).
Для детского веб-сайта вы могли бы автоматически сгенерировать нечеткое существо на основе имени пользователя (что-то вроде идентификатора) и попросить пользователя присвоить существу секретное имя.Затем им может быть предложено ввести секретное имя существа для входа в систему.

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

Важно помнить, что истинный опыт в области безопасности заключается в поиске подходящих компромиссов, а НЕ в догматичном изложении "Лучших практик", о которых каждый может прочитать в Интернете.

Таким образом, я предлагаю другое решение:
В зависимости от ценности системы, а также ТОЛЬКО ЕСЛИ система имеет соответствующую низкую стоимость и не содержит "дорогих" активов (включая саму идентификационную информацию)., И существуют действительные бизнес-требования, которые делают надлежащий процесс невозможным (или достаточно сложным / дорогостоящим)., И клиент ознакомлен со всеми предостережениями...
Тогда было бы уместно просто разрешить обратимое шифрование, без каких-либо специальных препятствий для перехода.
Я останавливаюсь на том, чтобы сказать, что вообще не стоит беспокоиться о шифровании, потому что оно очень простое / дешевое в реализации (даже с учетом управления пассивными ключами), и оно обеспечивает некоторую защиту (больше, чем затраты на его реализацию).Кроме того, стоит посмотреть, как предоставить пользователю оригинальный пароль, будь то по электронной почте, при отображении на экране и т.д.
Поскольку здесь предполагается, что значение украденного пароля (даже в совокупности) довольно низкое, любое из этих решений может быть допустимым.

Поскольку в разных сообщениях и отдельных темах комментариев идет оживленная дискуссия, на самом деле НЕСКОЛЬКО оживленных дискуссий, я добавлю некоторые пояснения и отвечу на некоторые из очень хороших моментов, которые были подняты в другом месте здесь.

Для начала, я думаю, всем присутствующим здесь ясно, что разрешение восстанавливать исходный пароль пользователя - плохая практика и, как правило, не очень хорошая идея.Это нисколько не оспаривается...
Далее, я подчеркну, что во многих, нет, в БОЛЬШИНСТВЕ ситуаций - это действительно неправильно, даже мерзкий, противный И уродливый.

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

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

Знаете, это забавно - я всегда считал себя одним из фанатиков безопасности, и каким-то образом я нахожусь на противоположной стороне от этих так называемых "Экспертов по безопасности"...Ну, правда в том, что - поскольку я фанатик и настоящий эксперт по безопасности в реальной жизни - я не верю в разглагольствование догмы "Наилучшей практики" (или CWES) БЕЗ этого крайне важного анализ рисков.
"Остерегайтесь фанатиков безопасности, которые быстро применяют все, что есть у них на поясе с инструментами, не зная, от какой на самом деле проблемы они защищаются.Большая безопасность не обязательно означает хорошую защищенность ".
Анализ рисков и настоящие фанатики безопасности указали бы на более разумный компромисс, основанный на ценности и риске, основанный на риске, потенциальных потерях, возможных угрозах, дополнительных мерах по смягчению последствий и т.д.Любой "Эксперт по безопасности", который не может указать на обоснованный анализ рисков в качестве основы для своих рекомендаций или поддержать логические компромиссы, но вместо этого предпочитает излагать догмы и CWES, даже не понимая, как выполнить анализ рисков, - это не что иное, как хакеры по безопасности, и их опыт не стоит туалетной бумаги, на которой они его напечатали.

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

Но прежде чем мы поговорим о соответствующих компромиссах, на которые следует пойти в ЭТОЙ СИТУАЦИИ, давайте взглянем на очевидные риски (очевидные, поскольку у нас нет всей исходной информации об этой ситуации, мы все выдвигаем гипотезы - поскольку вопрос в том, какая гипотетическая ситуация может возникнуть ...)
Давайте предположим, что система с НИЗКОЙ СТОИМОСТЬЮ, но не настолько тривиальная, чтобы к ней был открытый доступ - владелец системы хочет предотвратить случайное олицетворение, но "высокая" безопасность не так важна, как простота использования.(Да, это законный компромисс - принять риск того, что любой опытный разработчик скриптов может взломать сайт...Погоди, разве АПТ сейчас не в моде?..)
Просто для примера, допустим, я создаю простое место для сбора большой семьи, позволяя всем провести мозговой штурм по поводу того, куда мы хотим отправиться в поход в этом году.Я меньше беспокоюсь о каком-нибудь анонимном хакере или даже о кузене Фреде, который постоянно предлагает вернуться на озеро Вантанаманабикилики, чем о том, что тетя Эрма не сможет войти в систему, когда ей это нужно.Так вот, тетя Эрма, будучи физиком-ядерщиком, не очень хорошо запоминает пароли и вообще не умеет пользоваться компьютерами...Поэтому я хочу устранить все возможные трения для нее.Опять же, я НЕ беспокоюсь о взломах, я просто не хочу глупых ошибок при неправильном входе в систему - я хочу знать, кто приходит и чего они хотят.

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

Выдавать себя за пользователей?Нет, я уже пошел на этот риск, это неинтересно.
Злой администратор?Ну, может быть...Но опять же, меня не волнует, может ли кто-то выдавать себя за другого пользователя, ВНУТРЕННЕГО или нет...и в любом случае вредоносный администратор получит ваш пароль несмотря ни на что - если ваш админ испортился, игра в любом случае окончена.
Еще один поднятый вопрос заключается в том, что идентификационные данные фактически являются общими для нескольких систем.Ах!Это очень интересный риск, который требует более пристального изучения.
Позвольте мне начать с утверждения, что это не настоящее идентичность это общее, скорее всего, доказательство, или учетные данные для аутентификации.Хорошо, поскольку общий пароль фактически позволит мне войти в другую систему (скажем, в мой банковский счет или gmail), это фактически тот же идентификатор, так что это просто семантика...За исключением этого это не так.В этом сценарии идентификация управляется отдельно каждой системой (хотя могут существовать сторонние системы идентификации, такие как OAuth - тем не менее, они отделены от идентификации в этой системе - подробнее об этом позже).
Таким образом, основной риск здесь заключается в том, что пользователь добровольно введет свой (один и тот же) пароль в несколько разных систем - и теперь я (администратор) или любой другой хакер моего сайта будем иметь доступ к паролям тети Эрмы от сайта ядерных ракет.

Хммм.

Вам что-нибудь здесь не кажется странным?

Так и должно быть.

Давайте начнем с того факта, что защита ракетно-ядерной системы - это это не моя ответственность, Я просто создаю сайт для семейных прогулок frakkin (для МОЕЙ семьи).Так чья же это ответственность?Эммм...Как насчет ракетно-ядерной системы?Да.
Во-вторых, если бы я хотел украсть чей-то пароль (кто-то, кто, как известно, неоднократно использует один и тот же пароль между защищенными сайтами и не очень безопасными) - зачем бы мне беспокоиться о взломе вашего сайта?Или у вас проблемы с симметричным шифрованием?Черт возьми, я могу просто смириться мой собственный простой веб-сайт, попросите пользователей зарегистрироваться, чтобы получать ОЧЕНЬ ВАЖНЫЕ НОВОСТИ обо всем, что они хотят...Вуаля, я "украл" их пароли.

Да, обучение пользователей всегда возвращается, чтобы задеть нас за живое, не так ли?
И ты ничего не можешь с этим поделать...Даже если бы вы хэшировали их пароли на своем сайте и делали все остальное, что может придумать TSA, вы добавили защиту к их паролю НИ НА ЙОТУ, если они собираются продолжать беспорядочно вставлять свои пароли на каждый сайт, на который натыкаются.ДАЖЕ не утруждай себя попытками.

Скажем по - другому, У вас нет их паролей, так что перестань пытаться вести себя так, как ты это делаешь.

Итак, мои дорогие эксперты по безопасности, как обычно спрашивала пожилая леди у Венди: "ГДЕ риск?"

Еще несколько замечаний в ответ на некоторые вопросы, поднятые выше:

CWE - это не закон, не нормативное положение и даже не стандарт.Это коллекция общие недостатки, т. е.обратная "Лучшим практикам".
Проблема общей идентичности является актуальной проблемой, но ее неправильно понимают (или искажают) здешние скептики.Речь идет о совместном использовании идентификационных данных само по себе (!), а НЕ о взломе паролей в малоценных системах.Если вы делитесь паролем между системой с низкой стоимостью и системой с высокой стоимостью, проблема уже существует!
Кстати, предыдущий пункт действительно указывал бы на ПРОТИВ использование OAuth и т.п. как для этих малоценных систем, так и для высокоценных банковских систем.
Я знаю, что это был всего лишь пример, но (к сожалению) системы ФБР на самом деле не самые защищенные в мире.Не совсем такие, как серверы your cat's blog, но и не превосходят некоторые более безопасные банки.
Разделение знаний, или двойной контроль, над ключами шифрования происходит НЕ только в армии, фактически PCI-DSS сейчас требует это в основном от всех продавцов, так что на самом деле это уже не так далеко (ЕСЛИ ценность это оправдывает).
Всем тем, кто жалуется, что подобные вопросы - это то, из-за чего профессия разработчика выглядит такой плохой:именно подобные ответы заставляют профессию охранника выглядеть еще хуже.Опять же, анализ рисков, ориентированный на бизнес, - это то, что требуется, иначе вы сделаете себя бесполезным.В дополнение к тому, что я был неправ.
Я думаю, именно поэтому не стоит просто брать обычного разработчика и перекладывать на него больше обязанностей по обеспечению безопасности, не обучая мыслить по-другому и искать правильные компромиссы.Без обид, для тех из вас, кто здесь присутствует, я полностью за это, но необходимо больше тренироваться.

Фух.Какой длинный пост...
Но чтобы ответить на ваш первоначальный вопрос, @Shane:

Объясните клиенту, как правильно что-то делать.
Если он все еще настаивает, объясните еще что-нибудь, настаивайте, спорьте.Закатите истерику, если понадобится.
Объясните ему БИЗНЕС-РИСК.Детали хороши, цифры лучше, обычно лучше всего использовать живую демонстрацию.
ЕСЛИ ОН ВСЕ еще настаивает И приводит веские деловые причины - вам пора принять решение:
Является ли этот сайт малоценным или вообще не имеет ценности?Действительно ли это обоснованный бизнес-кейс?Достаточно ли это хорошо для тебя?Есть ли какие-либо другие риски, которые вы могли бы рассмотреть, которые перевесили бы веские деловые причины?(И, конечно, ЯВЛЯЕТСЯ ли клиент НЕ вредоносным сайтом, но это так).
Если это так, просто продолжайте.Внедрение необходимого процесса не стоит затраченных усилий, трений и утраченного использования (в данной гипотетической ситуации).Любое другое решение (опять же, в данной ситуации) является плохим компромиссом.

Итак, итог и фактический ответ - зашифруйте его с помощью простого симметричного алгоритма, защитите ключ шифрования надежными списками управления доступом и, предпочтительно, DPAPI или тому подобным, задокументируйте это и попросите клиента (кого-то достаточно старшего, чтобы принять это решение) подписать его.

Как насчет приюта на полпути?

Храните пароли с надежным шифрованием и не допускайте сброса.

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

Вы можете «продать» это как безопасный механизм сброса паролей.

Единственный способ позволить пользователю восстановить свой первоначальный пароль — это зашифруйте его собственным открытым ключом пользователя. Только этот пользователь сможет расшифровать свой пароль.

Итак, шаги будут такими:

Пользователь регистрируется на вашем сайте (разумеется, через SSL), не устанавливая пароль.Войдите в систему автоматически или укажите временный пароль.
Вы предлагаете сохранить их открытый ключ PGP для будущего восстановления пароля.
Они загружают свой публичный ключ PGP.
Вы просите их установить новый пароль.
Они сообщают свой пароль.
Вы хешируете пароль, используя лучший доступный алгоритм хеширования паролей (например,бкрипт).Используйте это при проверке следующего входа в систему.
Вы шифруете пароль открытым ключом и храните его отдельно.

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

Я думаю, что настоящий вопрос, который вы должны задать себе:«Как я могу лучше убеждать людей?»

У меня такая же проблема.И в то же время я всегда думаю, что кто-то взломает мою систему, это вопрос не «если», а «когда».

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

зашифровать с помощью: openssl_encrypt(строка $data, строка $метод, строка $пароль)
- Руководство по PHP.
аргумент данных:
- конфиденциальная информация (например,пароль пользователя)
- сериализовать при необходимости, например.если информация представляет собой массив данных, например, множественную конфиденциальную информацию
аргумент пароля:используйте информацию, которую знает только пользователь, например:
- номерной знак пользователя
- номер социального страхования
- номер телефона пользователя
- материнское имя пользователя
- случайная строка, отправленная по электронной почте и/или по SMS во время регистрации
метод аргумент:
- выберите один метод шифрования, например «aes-256-cbc»
НИКОГДА хранить информацию, используемую в аргументе «пароль», в базе данных (или в любом другом месте системы)

При необходимости получить эти данные просто используйте функцию «openssl_decrypt()» и спросите у пользователя ответ.Например.: «Чтобы получить пароль, ответьте на вопрос:Какой твой номер телефона?"

PS 1:никогда не используйте в качестве пароля данные, хранящиеся в базе данных.Если вам необходимо сохранить номер мобильного телефона пользователя, никогда не используйте эту информацию для кодирования данных.Всегда используйте информацию, которую знает только пользователь или которую трудно узнать кому-то, кто не является его родственником.

PS 2:для информации о кредитной карте, например «покупка в один клик», я использую пароль для входа.Этот пароль хешируется в базе данных (sha1, md5 и т. д.), но во время входа в систему я сохраняю пароль в виде открытого текста в сеансе или в непостоянном (т. е.в памяти) безопасный файл cookie.Этот простой пароль никогда не остается в базе данных, он всегда остается в памяти и уничтожается в конце раздела.Когда пользователь нажимает кнопку «Покупка в один клик», система использует этот пароль.Если пользователь вошел в систему с помощью такой службы, как Facebook, Twitter и т. д., то я снова запрашиваю пароль во время покупки (хорошо, это не полностью «по клику») или затем использую некоторые данные службы, которую пользователь использовал для входа в систему. (например, идентификатор Facebook).

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

Какова цена утечки чьего-либо пароля?Какова стоимость олицетворения в данной системе?Для компьютеров ФБР цена может оказаться огромной.Для одноразового пятистраничного веб-сайта Боба стоимость может быть незначительной.Профессионал предлагает варианты своим клиентам и, когда дело доходит до безопасности, описывает преимущества и риски любого внедрения.Это вдвойне справедливо, если клиент запрашивает что-то, что может подвергнуть его риску из-за несоблюдения отраслевых стандартов.Если клиент специально запрашивает двустороннее шифрование, я бы позаботился о том, чтобы вы задокументировали свои возражения, но это не должно помешать вам реализовать его наилучшим известным вам способом.В конце концов, это деньги клиента.Да, вам следует настаивать на использовании односторонних хэшей, но говорить, что это абсолютно единственный выбор, а все остальное неэтично, — это полная чушь.

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

Насколько мне известно, не существует закона (в том числе Закона о защите данных в Великобритании), в котором бы конкретно говорилось, что пароли должны храниться с использованием односторонних хэшей.Единственное требование в любом из этих законов заключается в том, что разумный принимаются меры по обеспечению безопасности.Если доступ к базе данных ограничен, даже пароли в виде открытого текста могут юридически подпадать под такое ограничение.

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

Сделайте ответ на секретный вопрос пользователя частью ключа шифрования и не храните ответ на секретный вопрос в виде обычного текста (вместо этого хэшируйте его).

Я внедряю системы многофакторной аутентификации, поэтому для меня естественно думать, что вы можете либо сбросить, либо восстановить пароль, временно используя на один фактор меньше для аутентификации пользователя только для рабочего процесса сброса/воссоздания.В частности, использование OTP (одноразовых паролей) в качестве некоторых дополнительных факторов снижает большую часть риска, если временной интервал для предлагаемого рабочего процесса мал.Мы с большим успехом внедрили программные генераторы OTP для смартфонов (которые большинство пользователей уже носят с собой целый день).Прежде чем появиться жалобы на коммерческую подключаемую версию, я хочу сказать, что мы можем снизить риски, связанные с возможностью легкого восстановления или сброса паролей, когда они не являются единственным фактором, используемым для аутентификации пользователя.Я признаю, что в сценариях повторного использования паролей между сайтами ситуация все еще не очень хороша, поскольку пользователь будет настаивать на использовании исходного пароля, потому что он/она хочет открыть и другие сайты, но вы можете попытаться доставить восстановленный пароль в самый безопасный способ (htpps и незаметное отображение в html).

Извините, но пока у вас есть способ расшифровать их пароль, он не будет безопасным.Боритесь с этим ожесточенно, и если вы проиграете, CYA.

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

Q1.Каковы фактические причины, по которым пользователь настаивает на том, чтобы иметь доступ к обычному текстовому сохраненному паролю?Почему это имеет такую большую ценность?

Информация о том, что пользователи старше или молоды, на самом деле не дает ответа на этот вопрос.Но как можно принять бизнес-решение без должного понимания озабоченности клиента?

Теперь, почему это имеет значение?Потому что, если реальной причиной запросов клиентов является система, которую крайне сложно использовать, то, возможно, устранение точной причины решило бы реальную проблему?

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

Еще один вопрос, который я видел заданным:

Вопрос 2.Если пользователь изначально не помнит пароль, то почему старый пароль имеет значение?

И вот возможный ответ.Если у вас есть кошка по имени "мяумиау", и вы использовали ее имя в качестве пароля, но забыли, что вы это сделали, вы бы предпочли, чтобы вам напомнили, что это было, или, скорее, отправили что-то вроде "#zy * RW (ew"?

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

Я просто пытаюсь понять причину.Но какова бы ни была причина, это причина, а не то, что должно быть устранено.

Как пользователь, я хочу, чтобы все было просто!Я не хочу много работать!

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

Я знаю, что это небезопасно, но какое мне дело до того, что кто-то получит доступ к моей "учетной записи"?Да, он тоже может читать новости!

Хранит ли сайт мою "личную" информацию?Новости, которые я прочитал сегодня?Тогда это проблема сайта, а не моя!Показывает ли сайт личную информацию аутентифицированному пользователю?Тогда не показывайте это на первом месте!

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

Итак, подводя итог, я считаю, что проблема заключается не в том, как "безопасно" хранить обычные текстовые пароли (что, как мы знаем, невозможно), а скорее в том, как решить реальную проблему клиентов.

Обработка утерянных/забытых паролей:

Никто и никогда не должен иметь возможности восстанавливать пароли.

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

Страница за ссылкой проверяет, что параметр guid действительно существует (возможно, с некоторой логикой тайм-аута), и запрашивает у пользователя новый пароль.

Если вам нужно, чтобы пользователи горячей линии помогали, добавьте несколько ролей в свою модель предоставления грантов и разрешите роли горячей линии временно входить в систему как идентифицированный пользователь.Регистрируйте все такие входы на горячую линию.Например, Bugzilla предлагает такую функцию олицетворения администраторам.

А как насчет отправки пароля в открытом виде по электронной почте при регистрации, прежде чем он будет зашифрован и потерян?Я видел, как это делают многие веб-сайты, и получить этот пароль из электронной почты пользователя более безопасно, чем оставлять его на своем сервере/компьютере.

Если вы не можете просто отказаться от требования хранить восстанавливаемые пароли, как насчет этого в качестве контраргумента?

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

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

Пользователи Действительно нужно восстановиться (напр.скажите) какой пароль они забыли, или им просто нужно иметь возможность войти в систему?Если им действительно нужен пароль для входа в систему, почему бы не создать процедуру, которая просто меняет старый пароль (каким бы он ни был) на новый пароль, который сотрудник службы поддержки может передать человеку, потерявшему свой пароль?

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

Другая возможность — иметь два одновременных пароля, разрешающих доступ к учетной записи.Один из них — это «обычный» пароль, которым управляет пользователь, а другой — это скелетный/главный ключ, который известен только сотрудникам службы поддержки и является одинаковым для всех пользователей.Таким образом, когда у пользователя возникает проблема, сотрудник службы поддержки может войти в учетную запись с помощью главного ключа и помочь пользователю сменить пароль на любой другой.Излишне говорить, что все входы в систему с помощью мастер-ключа также должны регистрироваться системой.В качестве дополнительной меры всякий раз, когда используется главный ключ, вы также можете проверить учетные данные сотрудников службы поддержки.

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

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

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

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

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

Но опять же, если бы у клиента этого бедняги было хорошее руководство, они бы вообще не просили такое решение, ставящее под угрозу безопасность, не так ли?

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

Если вы никогда не увидите пароль в открытом виде, то вопрос о его восстановлении не возникает.

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

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

Храните неизвлекаемое шифрование пароля в БД сайта (назовем его «pass-a»), как это делают нормальные люди :)
при каждом новом пользователе (или смене пароля) сохраняйте простую копию пароля в удаленной базе данных.используйте идентификатор сервера, идентификатор пользователя и «pass-a» в качестве составного ключа для этого пароля.вы даже можете использовать двунаправленное шифрование пароля, чтобы лучше спать по ночам.

теперь для того, чтобы кто-то получил и пароль, и его контекст (идентификатор сайта + идентификатор пользователя + «pass-a»), он должен:

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

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

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

Другой вариант, который вы, возможно, не рассматривали, - разрешить действия по электронной почте.Это немного громоздко, но я реализовал это для клиента, которому нужны были пользователи "вне" их системы для просмотра (только для чтения) определенных частей системы.Например:

Как только пользователь зарегистрирован, у него есть полный доступ (как к обычному веб-сайту ).При регистрации необходимо указать адрес электронной почты.
Если необходимые сведения или действие, и пользователю не помните свой пароль, они все еще могут выполнять действия по нажав на специальном "напишите мне по электронной почте для получения разрешения" кнопка, прямо рядом с обычной"Отправить" кнопка.
Затем запрос отправляется по электронной почте с гиперссылкой, спрашивающей, хотят ли они, чтобы это действие было выполнено.Это похоже на ссылку для сброса пароля по электронной почте, но вместо сброса пароля она выполняет следующее одноразовая акция.
Затем пользователь нажимает "Да", и это подтверждает, что данные должны быть показаны, или действие должно быть выполнено, данные раскрыты и т.д.

Как вы упомянули в комментариях, это не сработает, если электронное письмо скомпрометировано, но оно адресует комментарий @joachim о нежелании сбросить пароль.В конце концов, им придется воспользоваться сбросом пароля, но они могут сделать это в более удобное время или с помощью администратора или друга, по мере необходимости.

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

Соль и хеширование пароля пользователя как обычно.При входе пользователя в систему разрешите как пароль пользователя (после соли/хеширования), так и то, что пользователь буквально ввел, чтобы оно совпадало.

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

По сути, сделайте соленый/хешированный пароль также паролем «простого текста».

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow