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

Ответ 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? Возможно нет. Мне нравится это? Да.

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