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


1344

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

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

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

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

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

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

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

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

Спасибо всем

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

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

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


155
Я думаю, он знает, что это не хорошо. Он все еще ищет лучшее решение в соответствии с заявленными требованиями.
stefanw

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

20
@ Майкл Брукс - я хочу, чтобы вы знали, что я абсолютно согласен с CWE-257 и хотел бы просто цитировать это дословно каждый раз, когда меня просят сделать пароли, которые можно восстановить, в виде открытого текста. Однако на самом деле клиенты и пользователи редко интересуются правилами NIST и просто хотят, чтобы я это делал в любом случае. 90% времени я могу убедить их в обратном, но в те 10% случаев, когда я не могу, я пытаюсь определить лучший ход действий - в этих случаях CWE-257 - это пепел в моей руке (к сожалению).
Шейн

81
@AviD: «низкое значение» системы не имеет абсолютно никакого отношения к этой проблеме, потому что люди повторно используют свои пароли . Почему люди не могут понять этот простой факт? Если вы взломаете пароли в какой-либо системе с «низким значением», у вас, вероятно, будет несколько действительных паролей для других систем с «высоким значением».
Аарона

20
Также был упущен еще один момент, который я только что упомянул в комментарии к своему ответу: откуда вы знаете, что человек, запрашивающий эти требования, заслуживает доверия? Что, если оправдание «юзабилити» - это просто фасад, маскирующий реальное намерение украсть пароли в какой-то момент в будущем? Ваша наивность может стоить клиентам и акционерам миллионы. Сколько раз эксперты в области безопасности должны повторить это, прежде чем оно, наконец, проникнет: самые распространенные и самые серьезные угрозы безопасности всегда ВНУТРЕННИЕ.
Аарона

Ответы:


1037

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

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

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

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

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

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

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


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

197
Также вы можете составить полное предложение, например, <adjective> <имя существительное> <verb> <adverb>. Зеленый кот прыгает дико. есть списки для категорий. с 1024 вариантами для каждого у вас есть 40 битов энтропии.
Доминик Вебер

28
+1 за то, что рассматривал повторное использование пароля как критическую проблему, чтобы избежать его
lurscher 13.10.10

57
«Подумайте об этом - если пользователю нужно восстановить пароль, это потому, что он его забыл» - не обязательно правда! Я часто хочу получить свой пароль, потому что я на ноутбуке, и я ЗНАЮ, что на моей машине хранится мой пароль, или он записан где-то в безопасности, и я не хочу взламывать его, выдав новый ,
Иоахим

5
Вопрос с наибольшим количеством баллов на новом сайте IT Security SE касается достоверности этого вычисления энтропии. (Ну, технически, он имеет дело с XKCD что @Pieter связаны между собой .)
Попс

592

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

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

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

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

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

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

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

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


124
@ Aaronaught - Я думаю, что это справедливо и справедливо, но позвольте мне прокрутить это на вас. Вы работаете над проектом для компании в качестве сотрудника, и ваш начальник говорит: «Это требование нашей системы» (по любой причине). Вы уходите с работы, полной праведного негодования? Я знаю, что, когда я полностью контролирую ситуацию, я обязан нести ответственность, но если компания решает рискнуть в результате провала аудита или ответственности, я обязан пожертвовать своей работой, чтобы доказать свою точку зрения, или я стремлюсь получить ЛУЧШЕЕ и самый безопасный способ сделать то, что они говорят? Просто играю адвоката дьявола ..
Шейн

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

68
Разработчики всегда пытаются сказать, что наша работа намного сложнее, чем другие, потому что мы получаем требования к мусору, которые постоянно меняются. Ну, это прекрасный пример того, почему; наша профессия остро нуждается в позвоночнике. Наша профессия отчаянно должна иметь возможность сказать «нет, это неприемлемое требование, это не то, что я могу добросовестно развивать, вы можете быть моим клиентом / работодателем, но у меня есть профессиональные обязанности перед вашими клиентами и общественностью, и если вы хотите, чтобы это было сделано, то вам придется искать в другом месте. "
Ааронаут

36
@sfussenegger: вам не нужно знать фон. Это недопустимо. Вы предполагаете, что клиент заслуживает доверия на 100% - что, если он специально попросит об этом требовании, чтобы он мог позже уйти с паролями? Безопасность является одним из немногих предметов в разработке, которые высечены в камне. Есть некоторые вещи, которые вы просто не делаете, и хранение восстанавливаемых паролей - это десять из них.
Aaronaught

37
Хорошо, давайте сделаем оценку риска, прямо здесь и сейчас. «Если вы храните пароли в восстанавливаемой форме, вы создаете нетривиальный риск кражи паролей. Также вероятно, что по крайней мере некоторые пользователи будут использовать одни и те же пароли для своих адресов электронной почты и банковских счетов. Если пароли будут украдены и банковские счета истощены, это, вероятно, станет заголовком, никто никогда не будет иметь с вами дело снова, и вам, вероятно, будет предъявлен иск о существовании ». Можем ли мы сократить это дерьмо сейчас? Тот факт, что вы привели в это слово «нацисты», ясно показывает, что у вас нет чувства разума.
Aaronaught

206

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

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

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

34
-1 пароли никогда не должны быть «зашифрованы». Это нарушение CWE-257. Cwe.mitre.org/data/definitions/257.html
ладья

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

57
Правда, но не могли бы вы согласиться с тем, что с учетом требований это самый ответственный способ сделать это? Вы можете бить меня весь день своим CWE-257, это не изменит интересную проблему безопасного хранения и работы с учетными данными и возможности восстановления их в первоначальном виде, если это потребуется.
Stefanw

10
Агент восстановления Windows также является плохим примером, поскольку он имеет дело с реальным шифрованием, а не с управлением паролями. Ключ шифрования не совпадает с паролем; правила и практики, окружающие каждого, совершенно разные. Шифрование и аутентификация не совпадают. Шифрование для конфиденциальности - ключ используется для защиты данных . Аутентификация предназначена для идентификации , где ключом являются данные (это один из факторов в процессе аутентификации). Итак, повторяю, шифрование и аутентификация не совпадают. Вы не можете корректно применять принципы одного к другому.
Аарона

16
+1 В чем смысл одержимо настаивать на CWE-257? Это слабость (CWE), а не уязвимость (CVE). Сравнение восстанавливаемых паролей с переполнением буфера - это сравнение яблок и апельсинов. Просто убедитесь, что клиент понимает проблему (пусть он подпишет то, что говорит об этом - иначе он может ничего не вспомнить, если у него возникнут вопросы) и продолжайте. Кроме того, необходимые меры безопасности зависят от стоимости системы и потенциального риска атаки. Если успешный злоумышленник может отменить только некоторые подписки на новостную рассылку, нет причин спорить о каких-либо проблемах.
sfussenegger

133

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


2
Логи веб-сервера не учитываются в суде? Или в этом случае они будут считаться поддельными?
Винко Врсалович

10
@ Vinko Vrsalovic, Журналы веб-сервера НЕОБХОДИМО подсчитывать в суде, для этого вам необходимо доказать отсутствие отказа от авторства, подтверждение подлинности, цепочку доказательств и т.д.
AviD

7
Точно. Поставщик должен доказать, что только клиент мог выполнить эту транзакцию. Журнал веб-сервера не делает этого.
Маркиз Лорн

Так сказать, не все пароли нужны для «транзакций». Скажем, сайт предназначен для разработки списка закладок на веб-странице. В этом случае предел ответственности (который обычно указывается в Правилах и Условиях при регистрации на веб-сайте) равен нулю, потому что нет финансовой транзакции. Если на веб-сайте нет действий, влияющих на других пользователей, данные могут быть потеряны для взломанного пользователя. Компания защищена T & C.
Sablefoste

1
@Sablefoste На этом сайте. Если пользователь использует тот же пароль в другом месте, вы создаете риск утечки его личных учетных данных. Если вы никогда не будете заниматься практикой, вы не сможете вызвать проблемы.
Маркиз Лорн

94

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

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

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

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

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


8
@jimmycakes - это хорошая вещь для системы с низким уровнем безопасности, но если вы храните какие-либо данные высокой ценности, вы должны предположить, что электронная почта людей уже взломана и что отправка им прямой ссылки входа в систему ставит под угрозу вашу систему. +1 за ответ на мой вопрос с возможной альтернативой, но указав на недостаток в логике в целом. Я не хочу, чтобы Payppal отправлял прямую ссылку для входа. Это может показаться параноиком, но я всегда предполагаю, что мой почтовый ящик поврежден - это делает меня честным. ;)
Шейн

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

1
Игнорирование банка или PayPal, у которых не будет установленного вами ограничения; Если вы предполагаете, что их электронная почта скомпрометирована, как возможен любой онлайн-метод? Если вы отправите сгенерированный пароль по электронной почте, насколько это будет безопаснее?
Питер Коултон

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

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

55

Прочитав эту часть:

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

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

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

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

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

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


4
@john - я думаю, что это вполне жизнеспособное решение. Приготовьтесь к тому, чтобы разжечь внутренние угрозы! Знаете, если бы я делал это с промежуточным сбросом пароля (техник устанавливает пароль вручную как временную меру и приказывает Мейбл ввести 1234 в качестве ее пароля), то это, вероятно, будет хорошо работать в системе, не содержащей важных данных. Если бы это была среда с высокой степенью безопасности, то у нас возникла бы проблема, когда служба Cust могла бы установить пароль главного управляющего на 1234 и войти в систему напрямую. Идеального решения не существует, но оно работает во многих случаях. (+1)
Шейн

5
Я только заметил этот ответ. @Shane, я не понимаю, почему ты предсказал разгорание из-за "внутренних угроз". Возможность сменить пароль не является заметной слабостью; проблема заключается в возможности найти пароль, который, вероятно, будет использоваться для других служб - ее электронной почты, ее банка, ее сайтов онлайн-покупок, в которых хранится информация о ее СЦ. Эта слабость здесь не проявляется; если Боб сбрасывает пароль Мейбл и сообщает его по телефону, это не дает ему доступа ни к одной из ее других учетных записей. Я бы, однако, форсировал, а не «предлагал» сброс пароля при входе в систему.
Aaronaught

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

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

4
Код, предоставленный службой поддержки, не обязательно должен быть новым паролем. Это может быть просто одноразовый код, который разблокирует функцию сброса пароля.
kgilpin

42

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

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

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


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

27

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

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

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

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

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

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

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

Я ответил на комментарии здесь, внизу в моем ответе, так как они были довольно продолжительными - я думаю, что важно проанализировать анализ и обсуждение поднятых вопросов. stackoverflow.com/questions/2283937/…
AviD

Получает ли пользователь выгоду от того, что его пароль отображается на экране? На мой взгляд - определенно да! Каждый раз, когда я получаю непонятный пароль из предоставленного Интернета, я благодарю Apple, что могу сделать его видимым, чтобы мне не приходилось повторять его 100 раз с болью. Я представляю, как будет чувствовать себя инвалид.
Дмитрий Зайцев

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

@Jacob: больше энтропии?
Александр Щебликин

25

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

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

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


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

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

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

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

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

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

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

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

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

Хммм.

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

Должно.

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

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

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

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

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

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

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

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

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


5
Пароли, которыми обмениваются ваши малоценные сайты с «нет» дорогими активами и Facebook / GMail / вашим банком, являются дорогостоящим активом, даже на малоценных сайтах.
jammycakes

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

7
Извините, но сама личность является ценным активом, и точка. Нет исключений, нет оправданий. Независимо от того, насколько маленьким и незначительным вы считаете свой сайт. И общий пароль является идентификатором, если он позволяет хакеру войти в учетные записи Facebook ваших пользователей, учетные записи Gmail, банковские счета и т. Д. Это не имеет ничего общего с семантикой, но все это связано с последствиями. Просто спросите любого, кто подвергся хакерской атаке, такой как эта: theregister.co.uk/2009/08/24/4chan_pwns_christians
jammycakes

2
@Jacob, в каком мире ваш клиент будет привлечен к ответственности, потому что учетные записи Эрмы в других системах были скомпрометированы? Даже учитывая грубую небрежность со стороны вашего клиента (что НЕ является данностью, как я разработал), и кроме того факта, что НЕТ СПОСОБА доказать, что другая система была нарушена из-за вашей, не существует никакого юридического права требовать любую форму ущерба от одной системы в другой системе. Это будет выброшено из суда с предубеждением, а истец будет признан неуважительным. Тем не менее, Эрма может быть виноват в нарушении многочисленных Условий предоставления услуг ...
AviD

5
@ Джейкоб, это очень неправильно. Просто потому, что пароль один и тот же (что явно нарушает ваши ToS и их политику безопасности), они не имеют юридической силы для их сопоставления. Это даже за исключением того факта, что доказать это было бы почти невозможно. Кроме того, я также укажу, что нет НИКАКОГО ЗАКОНА, который требует от случайной компании не применять слабые правила безопасности, если только не действуют конкретные правила. И вдобавок ко всему, пароли зашифрованы (!), Поэтому слабость еще далеко не забыта.
AviD

21

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

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

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

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


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

Вы всегда можете рассказать своему клиенту о риске попадания их БД в злые руки и о том, что они украдут пароли ... Существует множество примеров.
Одед

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

4
-1 пароли никогда не должны быть «зашифрованы». Это нарушение CWE-257 cwe.mitre.org/data/definitions/257.html
ладья

34
@ Майкл Брукс: Нет необходимости понижать голос и копировать один и тот же комментарий снова и снова; мы все знаем, что это плохая практика. Шейн заявил, что ему не хватает рычагов в этом вопросе, и поэтому предлагаются следующие лучшие вещи.
Йоханнес Горсет

13

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

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

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

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


5
У большинства пользователей нет ключа PGP (у меня его еще нет; после 20 лет работы в отрасли я никогда не чувствовал в этом необходимости), и его получение не является легким процессом. Кроме того, закрытый ключ на самом деле просто прокси для реального пароля в любом случае. Другими словами, это пароль для пароля; это черепахи вниз.
Роберт Харви

1
@RobertHarvey Цель состоит в том, чтобы позволить пользователю восстановить свой пароль, не позволяя сотрудникам сайта или любым хакерам получить доступ к нему. Требуя, чтобы процесс поиска происходил на собственном компьютере пользователя, вы применяете это. Вполне могут быть альтернативы PGP, которые могли бы достичь того же. Черепахи могут быть полностью внизу (возможно, некоторые слоны по пути), но я не вижу другого пути. Для населения в целом (маловероятно, что на него будут нацелены индивидуально) хранение ваших паролей на бумажке и невозможность извлечь их из службы, будет более безопасным, чем мы в настоящее время
Николас Шенкс

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

Вы можете просто сгенерировать один и дать его пользователю.
My1

@RobertHarvey Возможно, вы правы, что это «не простой процесс», но это может быть дополнительная услуга для опытных пользователей, которую обычные пользователи могут игнорировать. Что касается аргумента о том, что PK является «паролем для пароля», помните, что теоретически это может быть так для многих паролей; Вы можете использовать разные пароли для разных сервисов и шифровать их все с помощью одного и того же ключа. Тогда ПК будет более ценным, чем просто один пароль. Возможно, это абстрактно сопоставимо с менеджером паролей (?). Мне не сразу ясно, какие последствия это может иметь, хотя ...
Кьяртан

12

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


4
@ sneg - Ну, я очень убедительный парень, но иногда это босс, а иногда и клиент, поэтому у меня не всегда есть рычаги, которые мне нужны, чтобы убедить их так или иначе. Я буду практиковаться в зеркале еще немного ..;)
Шейн

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

7
@ z-boss - Очевидно, вы не работали с некоторыми жесткими головами, с которыми я имел удовольствие работать. Иногда не имеет значения, покрыт ли ваш язык золотом, и вы можете перепрограммировать Google Chrome за один день (что, возможно, действительно может сделать его полезным), они все равно не сдвинутся с места.
Шейн

11

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

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

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

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

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

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


9

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

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

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

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

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


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

4
Опять же, вы полностью пропускаете оценку риска. Чтобы использовать ваш аргумент, вы не можете остановиться только на односторонних хешах. Вы также должны включать требования к сложности, длину пароля, ограничения на повторное использование пароля и так далее. Утверждение о том, что пользователи будут использовать тупые пароли или повторное использование паролей, не является достаточным бизнес-оправданием, если система неактуальна и, честно говоря, я ответил на вопрос. Краткий ответ: настаивайте на использовании стандартной реализации, документируйте свои возражения, если вас отвергли, и продолжайте.
Томас,

7
И снова вы повторяете слух, что все это не имеет значения для системы с низкой стоимостью! Значение пароля пользователя не имеет ничего общего со значением учетной записи пользователя в вашей системе. Это секрет , который вы всегда должны хранить. Я хотел бы дать еще один -1 за комментарий, демонстрирующий, что вы все еще не понимаете проблем здесь.
Aaronaught

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

7
Единственное, что здесь ясно, это то, что весь ваш аргумент является не чем иным, как ошибкой Slippery Slope и что вы пытаетесь подбросить читателей модными словами типа «оценка риска», чтобы скрыть этот факт. Будьте уверены, что любая система, которую использует «ФБР», будет гораздо более безопасной, чем хеш bcrypt и минимальная длина пароля. Если требование стандартных систем аутентификации делает меня «фанатиком безопасности», то я думаю, что я фанатик; лично мне больно знать, что есть люди, готовые пожертвовать МОЕЙ безопасностью ради денег. Это неэтично .
Aaronaught

8

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


Пользователь может по-разному ответить и на вопрос. Некоторые вопросы требуют более длинных ответов, которые легко перефразировать позже.
Monoman

5
Вопросы безопасности - плохая идея. Как вы заставили свою маму сменить девичью фамилию, когда информация была взломана? Также см. « Техническая безопасность» Питера Гутмана .
2013 г.

7

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


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

@Aaronaught То, что я сказал, это то, что если вы «обязаны» иметь восстанавливаемые пароли, риск, связанный с ним, ниже, если он не является единственным фактором аутентификации, и конечному пользователю также легче, если этот рабочий процесс использует факторы, которые он / она уже обладает и имеет текущий доступ к нему, чем пытается вспомнить, вероятно, также забытые «секретные ответы» или использует ограниченные по времени ссылки или временные пароли, которые отправляются по небезопасным каналам (если вы не используете S-MIME с клиентскими сертификатами или PGP, оба несут расходы, особенно на управление правильной ассоциацией и истечением / заменой)
Monoman

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

5

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


5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


4

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

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

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

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

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


GUID - плохая идея, она не достаточно случайна и легко поддается грубому обращению. есть другие проблемы с этим, см. stackoverflow.com/questions/664673/…
AviD

3

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


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

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

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

3

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

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

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


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

1
Вы полностью упустили мою точку зрения. Если вам действительно не нужен пароль, не собирайте его. Разработчики часто зацикливаются на способе мышления «мы так и делаем». Иногда это помогает отбросить предвзятые представления.
Anopres

2

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

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

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

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

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

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

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

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

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


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

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

Мне любопытно, я думал, что Linux по умолчанию имеет учетную запись суперпользователя с доступом на уровне root? Разве это не «главный ключ» для доступа ко всем файлам в системе?
JonnyBoats

@JonnyBoats Да, это так. Вот почему современные Unix, такие как Mac OS X, отключают учетную запись root.
Николас Шенкс

@NicholasShanks: Отключить учетную запись root или отключить интерактивный вход в систему под учетной записью root? Там еще много кода работает с неограниченными разрешениями.
Бен Фойгт

2

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

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

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


1

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

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

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

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

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

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


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

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

1

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

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

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

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


1

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

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

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


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

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

Понимаю. Я не прочитал вопрос полностью. Использование сравнения с постоянным временем все еще необходимо для предотвращения тривиального разрушения всей системы.
Artjom B.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.