Соление: действительно ли разумно использовать имя пользователя?
Я обсуждаю имена пользователей использования как средство посолить пароли, вместо того, чтобы хранить случайную строку наряду с именами. Мое выравнивание состоит в том, что цель соли состоит в том, чтобы предотвратить таблицы радуги, поэтому что делает это реалистично менее безопасным, чем другой набор данных там?
Например,
hash( md5(johnny_381@example.com), p4ss\/\/0rD)
по сравнению с
hash( md5(some_UUID_value), p4ss\/\/0rD)
Существует ли настоящая причина, которую я не мог только продолжить работать с именем пользователя и упростить вещи? Единственной вещью мой веб-поиск закончился, были дебаты относительно того, как соль должна быть похожей на пароль, но законченный без любого обоснования позади него, где у меня создается впечатление, чтобы это только предотвратило что-то как cain-able взломщик для выполнения против него, не будучи в диапазоне миллиона лет. Думая об обработке ограничений действительности, я не полагаю, что это - грандиозное предприятие, если люди знают хеш, они все еще не знают пароля, и они переместили в суперкомпьютерный диапазон в грубую силу каждый отдельный хеш.
Кто-то мог просветить меня здесь?
5 ответов
Вы столкнетесь с проблемами при изменении имени пользователя (если его можно изменить). Вы не можете обновить хешированный пароль, потому что вы не храните несоленый, не хешированный пароль.
Этот метод был признан достаточно безопасным для рабочей группы, создавшей дайджест-аутентификацию HTTP, работающую с хешем строки «username: realm: password».
Думаю, вы не против, поскольку это решение секретное. Если кто-то украдет вашу базу данных и исходный код, чтобы увидеть, как вы на самом деле реализовали свое хеширование, хорошо, что они вошли в систему, чтобы получить доступ в этот момент? Веб-сайт, который отображает данные в базе данных, которые они уже украли?
В этом случае соль дает вашему пользователю пару преимуществ безопасности. Во-первых, если вор имеет предварительно вычисленные значения (радужные таблицы), ему придется пересчитывать их для каждого отдельного пользователя, чтобы провести атаку; если вор охотится за паролем одного пользователя, это не большая победа.
Во-вторых, хэши для всех пользователей всегда будут разными, даже если они используют один и тот же пароль, поэтому вор не получит никаких конфликтов хеширования бесплатно (взломав один пользователь, получите 300 паролей).
Эти два преимущества помогают защитить ваших пользователей, которые могут использовать один и тот же пароль на нескольких сайтах, даже если вор получит базы данных других сайтов.
Таким образом, хотя соль для хеширования паролей лучше хранить в секрете (что в вашем случае будут точными данными, используемыми для соли), она все же дает преимущества, даже если они скомпрометированы.
Случайное подсаливание предотвращает сравнение двух независимо вычисленных хэшей паролей для одного и того же имени пользователя. Без него можно было бы проверить, совпадает ли пароль человека на одной машине с паролем на другой, или соответствует ли пароль тому, который использовался в прошлом, и т. Д., Без необходимости иметь фактический пароль. Это также значительно упростило бы поиск критериев, подобных приведенным выше, даже когда пароль доступен (поскольку можно было бы искать вычисленный хэш, а не вычислять хеш отдельно для каждого хеш-значения старого пароля).
Кто знает, хорошо или плохо такая профилактика.
Я не вижу проблем с использованием имени пользователя в качестве значения соли.
Более безопасный способ хранения паролей в любом случае предполагает использование разных значений соли для каждой записи.
Если вы посмотрите на таблицу aspnet_Membership файла asp.net, вы увидите, что они сохранили поля пароля, пароля и имени пользователя практически в одной и той же записи. Таким образом, с этой точки зрения нет никакой разницы в безопасности в том, чтобы просто использовать имя пользователя для значения соли.
Обратите внимание, что некоторые системы используют одно значение соли для всех паролей и сохраняют его в файле конфигурации. Единственная разница в безопасности здесь заключается в том, что если они получили доступ к единственному значению соли, то им будет легче построить радужную таблицу для взлома всех паролей сразу ...
Но опять же, если у них есть доступ к зашифрованная форма паролей, тогда они, вероятно, будут иметь доступ к значению соли, хранящемуся в таблице пользователей, прямо вместе с ним ... Это может означать, что им будет немного сложнее выяснить значения пароля.
Однако, в конце концов, я считаю, что почти все приложения терпят неудачу на фронте шифрования, потому что они только шифруют то, что якобы является одной из наименее важных частей данных: паролем. Что действительно должно быть зашифровано, так это почти все остальное.
В конце концов, если у меня есть доступ к вашей базе данных, какое мне дело, если пароль зашифрован? У меня уже есть доступ к важным вещам ...
Очевидно, здесь есть другие соображения, но, в конце концов, я бы не стал слишком сильно беспокоиться об этом, поскольку это незначительная проблема по сравнению с другими.
Если вы используете имя пользователя в качестве пароля и существует много экземпляров вашего приложения, люди могут создать радужные таблицы для конкретных пользователей, таких как "admin" или "system", как это происходит с базами данных Oracle, или с целым списком общих имен, как они сделали для WPA (CowPatty)
Лучше возьмите действительно случайную соль, это не так сложно, и она не будет преследовать вас.