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

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

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

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

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

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

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

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

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

спасибо всем

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

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

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

26 ответов


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

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

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

  • парольная фраза С примерно 77 битами энтропии: "признай прозу flare table острым чутьем"

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

анализ рисков.
"Остерегайтесь фанатика безопасности, который быстро применяет все в своем поясе инструментов, не зная, от чего на самом деле они защищаются. Большая безопасность не обязательно означает хорошую безопасность."
Анализ рисков и истинные фанатики безопасности укажут на более разумный, основанный на ценности/риске компромисс, основанный на риске, потенциальных потерях, возможных угрозах, дополнительных смягчениях и т. д. Любой "эксперт по безопасности", который не может указать на обоснованный анализ рисков в качестве основы для своих рекомендаций или поддержать логические компромиссы, но вместо этого предпочел бы извергать догмы и CWEs, даже не понимая, как выполнять анализ рисков, не что иное, как хаки безопасности, и их опыт не стоит туалетной бумаги, на которой они ее напечатали.

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

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

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

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

Хммм.

вам ничего здесь не кажется странным?

надо.

давайте начнем с того, что Защита системы ядерных ракет не моя ответственность, Я просто сайт семейный пикник, твою мать (для моей семьи). Так чья же это ответственность? МММ... Как насчет системы ядерных ракет? Да.
Во-вторых, если бы я хотел украсть чей-то пароль (кто-то, кто, как известно, неоднократно использует один и тот же пароль между защищенными сайтами и не очень безопасными), зачем мне беспокоиться о взломе вашего сайта? Или борется с симметричным шифрованием? Goshdarnitall, я могу просто put up мой собственный простой сайт, пользователи подписываются на получение очень важных новостей о том, что они хотят... Puffo Presto, я "украл" их пароли.

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

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


Как насчет дома?

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

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

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


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

таким образом, шаги будут:

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

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


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


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

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

  • зашифровать с: openssl_encrypt(строки данных , string $метод , строку $пароль)
  • данные arg:
    • конфиденциальная информация (например, пароль пользователя)
    • сериализовать при необходимости, например, если информация представляет собой массив данных, таких как несколько конфиденциальных данных
  • пароль arg: используйте информацию, которую знает только пользователь:
    • номерной знак пользователя
    • номер социального обеспечения
    • пользователь телефона номер
    • имя матери пользователей
    • случайная строка, отправленная по электронной почте и / или sms во время регистрации
  • метод arg:
    • выберите один метод шифрования, например "aes-256-cbc"
  • никогда хранить информацию, используемую в аргументе "пароль" в базе данных (или любом месте в системе)

при необходимости для повторного использования этих данных просто используйте функция "openssl_decrypt ()" и попросите пользователя ответить. Е. Г.: " для получения пароля ответьте на вопрос: какой у вас номер мобильного телефона?"

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

PS 2: для информация о кредитной карте, например "покупка одним щелчком мыши", я использую пароль для входа. Этот пароль хэшируется в базе данных (sha1, md5 и т. д.), Но во время входа в систему я храню простой текстовый пароль в сеансе или в непостоянном (т. е. в памяти) защищенном файле cookie. Этот простой пароль никогда не остается в базе данных, действительно, он всегда остается в памяти, уничтожается в конце раздела. Когда пользователь нажимает на кнопку "One click buying", система использует этот пароль. Если пользователь вошел в систему с сервисом, как facebook, twitter и т. д., Затем я снова запрашиваю пароль во время покупки (хорошо, это не полностью "по щелчку") или затем использую некоторые данные службы, которую пользователь использовал для входа в систему (например, идентификатор facebook).


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

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

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

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

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


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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

никто и никогда не должен быть в состоянии восстановить пароли.

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

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

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


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


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

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

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


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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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


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

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

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

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


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

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

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