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

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

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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

Хэш-пароли

Сохранение паролей в обратимой форме не является необходимым и рискованным.

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

Стратегия миграции

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

Угрозы

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

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

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

Смягчение

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Мне кажется очень тонкой причиной.

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

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

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

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

Ответ 10

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

Ответ 11

Если вы похожи на mint.com, да, сделайте это. Монетный двор хранит ваши пароли на нескольких других сайтах (ваш банк, кредитная карта, 401k и т.д.), А когда вы входите в Mint, он переходит на все остальные сайты, регистрируется через script, как вы, и отбрасывает обновленные финансовые данные в один удобный для просмотра централизованный сайт. Защищена ли она от tinfoil-hat? Возможно нет. Мне нравится это? Да.

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