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

Ответ 1

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

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

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

• кодовая фраза с примерно 77 битами энтропии: "допускайте острый талант прозаической таблицы факелов"

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

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

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

Ответ 2

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

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

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

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

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

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

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

Существует неэтичный или ответственный способ хранения паролей в восстанавливаемой форме. Период.

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

Если у ваших клиентов возникла проблема с этим, сообщите им, что сохранение паролей является, безусловно, противоречащим закону. Здесь, во всяком случае, в Великобритании, в Законе о защите данных 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 фактически шифровал пароли своих пользователей, но используемое шифрование было слишком слабым, чтобы быть эффективным.

Ответ 6

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

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

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

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

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

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

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

Ответ 9

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

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

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

Поскольку происходит оживленная дискуссия, на самом деле ОБЩИЕ оживленные дискуссии, в разных постах и ​​отдельных потоках комментариев, я добавлю некоторые пояснения и отвечу на некоторые из очень хороших моментов, которые были подняты в другом месте здесь.

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

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

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

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

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

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

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

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

Хммм.

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

Это должно быть.

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

Да, обучение пользователей всегда возвращается, чтобы укусить нас в хини, не так ли?
И вы ничего не можете с этим поделать... Даже если вы хотите хэшировать свои пароли на своем сайте и делать все, о чем TSA может подумать, вы добавили защиту их паролю NOT ONE WHIT, если они будут продолжать неразборчиво придерживая свои пароли на каждом сайте, на котором они сталкиваются. Не смей думать.

Другими словами, У вас нет своих паролей, поэтому перестаньте пытаться действовать так, как вы.

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

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

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

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

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

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

Ответ 10

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

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

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

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

Ответ 11

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

Итак, шаги:

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

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

Ответ 12

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

Ответ 13

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

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

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

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

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

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

Ответ 14

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

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

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

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

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

Ответ 18

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 19

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

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

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

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

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

Ответ 20

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

Ответ 21

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

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

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

Ответ 22

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

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

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

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

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

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

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

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

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

Ответ 23

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

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

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

Ответ 24

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

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

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

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

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

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

Ответ 25

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

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

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

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

Ответ 26

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

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

В принципе, сделайте засоленный/хешированный пароль также "простым текстовым" паролем.