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

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

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

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

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

Дополнительная информация для Bounty

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

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

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

Спасибо всем

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

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

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

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

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

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

• ключевая фраза с приблизительно 77 битами энтропии: «признайте, что стол с прозаической вспышкой острый талант»

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

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

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

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

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

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

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

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

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

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

Нет этического или ответственного способа хранить пароли в восстанавливаемой форме. Период.

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

Я думаю, что это на самом деле похоже на то, как работает агент восстановления 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 и пусть сторонний платит за расходы на забвение пользователя.
• Ослабить ограничения на пароль. Я уверен, что все мы были невероятно раздражены, когда какой-то веб-сайт не позволяет ваш предпочитаемый пароль из-за бесполезных требований, таких как «вы не можете использовать специальные символы» или «ваш пароль слишком длинный» или «ваш пароль должен начаться» с письмом. " Кроме того, если простота использования важнее, чем надежность пароля, вы могли бы ослабить даже не глупые требования, допустив более короткие пароли или не требуя сочетания классов символов. С ослабленными ограничениями пользователи будут чаще использовать пароль, который они не забудут.
• Не истекайте пароли.
• Разрешить пользователю повторно использовать старый пароль.
• Разрешить пользователю самостоятельно выбирать вопрос для сброса пароля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хммм.

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

Должно.

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

Да, обучение пользователей всегда возвращается, чтобы укусить нас в hienie, не так ли?
И с этим ничего не поделаешь ... Даже если вы БЫЛИ хешировать свои пароли на своем сайте и делаете все остальное, что может придумать АСП, вы добавили защиту к их паролю, а НЕ ОДНОМУ , если они собираются сохранить беспорядочно вставляя свои пароли в каждый сайт, на который они наталкиваются. Даже не пытайтесь.

Иными словами, вы не владеете их паролями , поэтому перестаньте пытаться вести себя, как вы.

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

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

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

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

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

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

Как насчет дома на полпути?

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

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

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

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

Так что шаги будут:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другой вопрос, который я видел, задал:

• Q2. Если пользователь не запоминает пароль в первую очередь, почему старый пароль имеет значение?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Как только пользователь зарегистрирован, он получает полный доступ (как обычный сайт). Регистрация должна включать электронную почту.
2. Если данные или действия необходимы , и пользователь не помнит свой пароль, они все равно могут выполнить действие, нажав на специальную « напишите мне для разрешения кнопки», рядом с обычной « представить кнопку».
3. Затем запрос отправляется на электронную почту с гиперссылкой, спрашивающей, хотят ли они, чтобы действие было выполнено. Это похоже на ссылку электронной почты для сброса пароля, но вместо сброса пароля выполняется одноразовое действие .
4. Затем пользователь нажимает «Да», и это подтверждает, что данные должны быть показаны или действие должно быть выполнено, данные раскрыты и т. Д.

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

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

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

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

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