Хранение зашифрованных паролей

Question

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

Один из нас считает, что:

• Хранение паролей, зашифрованных с использованием открытого ключа, в дополнение к односторонней хэшированной версии - это нормально и может быть полезно для интеграции с другими системами аутентификации в будущем в случае слияния или приобретения.
• Только генеральный директор / технический директор будет иметь доступ к закрытому ключу, и он будет использоваться только при необходимости. Регулярная проверка подлинности по-прежнему будет выполняться с помощью хешированного пароля.
• У меня был / он делал это раньше в предыдущих компаниях, и есть много сайтов, которые делают это и ранее проходили аудит безопасности в компаниях из списка Fortune 500.
• Это обычная и общепринятая практика даже для финансовых учреждений, поэтому нет необходимости прямо указывать это в политике конфиденциальности.
• Такие сайты, как Mint.com, делают это.

Другой из нас придерживается следующей точки зрения:

• Хранение паролей, даже в зашифрованном виде, является ненужным риском для безопасности, и лучше вообще избегать подверженности этому риску.
• Если закрытый ключ попадет в чужие руки, пользователи, использующие один и тот же пароль на нескольких сайтах, рискуют подвергнуть риску все свои логины.
• Это нарушение доверия наших пользователей, и если эта практика будет реализована, они должны быть прямо проинформированы об этом.
• Это не отраслевая практика, и ни один крупный сайт (Google, Yahoo, Amazon и т. Д.) Не реализует это. Mint.com - особый случай, потому что они должны проходить аутентификацию на других сайтах от вашего имени. Кроме того, они хранят только пароли к вашим финансовым учреждениям, а не пароль к самому Mint.com.
• Это красный флаг в ревизиях.

Мысли? Комментарии? Вы работали в организации, которая внедрила эту практику?

Answer 1

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

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

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

Answer 2

хэш-паролей

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

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

Миграционная стратегия

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

Угрозы

Существует несколько способов атаковать зашифрованные пароли:

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

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

Смягчение

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

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

Answer 3

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

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

Answer 4

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

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

Если кто-то теряет свой пароль, вы просто меняете его и даете им. Если компании необходимо объединиться, она ДОЛЖНА сохранить хешированные пароли такими, какие они есть: безопасность превыше всего.

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

Answer 5

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

Если нет необходимости хранить пароль в обратимом зашифрованном формате, не .

Answer 6

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

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

Answer 7

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

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

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

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

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

Или, если выразить это в форме, понятной для программного обеспечения, YAGNI.

Answer 8

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

Оба метода неверны.

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

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

Идеальным решением является использование комбинации клиентских сертификатов SSL и серверных сертификатов. Если вы сделаете это правильно, обычная атака MITM / Phishing невозможна ; такая атака не может быть использована против учетных данных или сеанса. Кроме того, пользователи могут хранить свои клиентские сертификаты на криптографическом оборудовании, таком как смарт-карты, что позволяет им входить в систему на любом компьютере без риска потери своих учетных данных (хотя они по-прежнему будут уязвимы для перехвата сеансов). .

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

Answer 9

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

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

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

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

Answer 10

Если вы мелкий случай, как mint.com, то да, сделайте это. Mint хранит ваши пароли на нескольких других сайтах (ваш банк, кредитная карта, 401k и т. Д.), И когда вы входите в Mint, он переходит на все эти другие сайты, входит в систему с помощью скрипта, как вы, и возвращает ваши обновленные финансовые данные в один легко видимый централизованный сайт. Безопасна ли шляпа из фольги? Возможно нет. Я люблю это? Да.

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