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

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

Например,

hash( md5([email protected]), p4ss\/\/0rD)

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

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

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

Ответ 1

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

Ответ 2

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

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

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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