Соление: разумно ли использовать имя пользователя?

Question

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

Например,

hash( md5(johnny_381@example.com), p4ss\/\/0rD)

против

hash( md5(some_UUID_value), p4ss\/\/0rD)

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

Может кто-нибудь просветить меня здесь?

Answer 1

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

Answer 2

Если вы используете имя пользователя в качестве пароля и существует множество экземпляров вашего приложения, люди могут создавать радужные таблицы для конкретных пользователей, таких как «admin» или «system», как это происходит в случае с базами данных Oracle или с полным списком общих имена, как они сделали для WPA (CowPatty)

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

Answer 3

Я не вижу проблемы с использованием имени пользователя в качестве значения соли.

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

Если вы посмотрите на таблицу aspnet_Membership провайдера членства asp.net, вы увидите, что они сохранили поля пароля, пароля и имени пользователя практически в одной записи. Таким образом, с этой точки зрения нет никакой разницы в безопасности при использовании только имени пользователя для соли.

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

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

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

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

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

Answer 4

Я знаю, что это старый вопрос, но для тех, кто ищет решение, основанное на этом вопросе.

Если вы используете производную соль (в отличие от случайной соли), источник соли должен быть усилен с помощью ключевой функции деривации, такой как PBKDF2.

Таким образом, если ваше имя пользователя "theunhandledexception", передайте его через PBKDF2 для x итераций, чтобы сгенерировать 32-битное значение (или любую необходимую вам длину).

Сделайте x псевдослучайным (в отличие от четных чисел, таких как 1000) и передайте статическую соль сайта для PBKDF2, и вы сделаете крайне маловероятным, что соль вашего имени пользователя будет соответствовать соли имени любого другого сайта.

Answer 5

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

Относительно того, является ли такая профилактика хорошей или плохой вещью, кто знает.

Answer 6

Этот метод был сочтен достаточно безопасным для рабочей группы, которая создала дайджест-аутентификацию HTTP, которая работает с хэшем строки «username: realm: password».

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

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

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

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

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