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

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

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

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

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

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

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

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

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

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

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

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

Хеш-пароли

Хранить пароли в обратимой форме необязательно и опасно.

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

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

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

Угрозы

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

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

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

Снижение риска

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

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

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

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

The argument in favor of storing them seems to be that it might simplify integration in the case of a merger or acquisition. Every other statement in that side of the argument is no more than a justification: either "this is why it's not so bad" or "other people are doing it".

How much is it worth to be able to do automatic conversions that a client may not want done in event of merger or acquisition? How often do you anticipate mergers and/or acquisitions? Why would it be all that difficult to use the hashed passwords as they are, or to ask your customers to explicitly go along with the changes?

It looks like a very thin reason to me.

On the other side, when you store passwords in recoverable form there's always a danger that they'll get out. If you don't, there isn't; you can't reveal what you don't know. This is a serious risk. The CEO/CTO might be careless or dishonest. There might be a flaw in the encryption. There would certainly be a backup of the private key somewhere, and that could get out.

In short, in order to even consider storing passwords in recoverable form, I'd want a good reason. I don't think potential convenience in implementing a conversion that might or might not be required by a possible business maneuver qualifies.

Or, to put it in a form that software people might understand, YAGNI.

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

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

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

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

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

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

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

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

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

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

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

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

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