Как хеширование и соляция паролей делают приложение безопасным?

Question

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

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

Или я что-то упустил?

Answer 1

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

Answer 2

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

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

Соление - это решение связанной проблемы. Если вы знаете, что кто-то использует хеш паролей, скажем, ABCDEF, то вы можете попробовать вычислить хэши для всех возможных паролей. Рано или поздно вы можете обнаружить, что hash ('dog') = ABCDEF, поэтому вы знаете их пароль. Это занимает очень много времени, но этот процесс можно ускорить, используя предварительно созданные «словари», где для заданного хэша вы можете найти соответствующий пароль. Однако соление означает, что хэшированный текст не является простым английским словом или простой комбинацией слов. Например, в приведенном выше случае хэшированный текст - это не «собака», а «somecrazymadeuptextdog». Это означает, что любой легкодоступный словарь бесполезен, так как вероятность того, что он содержит хэш для этого текста, намного меньше, чем вероятность того, что он содержит хэш для «собаки». Эта вероятность становится еще ниже, если соль представляет собой случайную буквенно-цифровую строку .

Answer 3

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

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

Answer 4

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

Пароль является собственностью ваших пользователей. Вы должны держать это в безопасности.

Answer 5

В этой статье подробно рассматриваются положительные аспекты хеширования и посылки ваших паролей:

http://www.developerfusion.com/article/4679/you-want-salt-with-that/

Answer 6

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

Да, это случилось. С данными кредитной карты тоже.

Да, очень вероятно, что это случится снова.

Answer 7

«Если кто-то неавторизованный проник в базу данных, не слишком ли поздно беспокоиться о паролях?»

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

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

Например, сохраните свои учетные данные на сервере LDAP.

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

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

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

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

Хешированные пароли являются частью рабочей политики безопасности.

Answer 8

В дополнение к тому, что уже было сказано относительно засолки, есть еще одна проблема, которую решает засолка:

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

Затем, если удастся получить пароль foo (например, с помощью социальной инженерии), пароль bar также известен.

Кроме того, если соль везде одинакова, можно создать словарь, посвященный этой конкретной соли, а затем провести атаку грубой силой, используя этот «соленый» словарь.

Answer 9

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

Цепь настолько сильна, насколько слабее ее звено

Хеширование паролей только укрепляет одно звено цепи. Так что вам придется сделать больше, чем это.

Answer 10

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

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

Это еще одна причина засолки:)