Неплохо ли использовать адрес электронной почты в качестве соли для пароля?
РЕДАКТИРОВАТЬ:
Позвольте мне направить вас к этому вопросу в Security StackExchange, который объясняет много деталей о хэшировании паролей и генерации ключей.
Итог: используйте безопасную систему хэширования паролей, которая как-то ресурсоемкой для защиты от атак с грубой силой, но ограничивает количество разрешенных вызовов для предотвращения атак типа «отказ в обслуживании» (DoS).
Если в вашей языковой библиотеке есть функция для нее, проверьте на обновления, что она делает то, что она должна делать, особенно если это PHP.
Ответ ниже приведен для исторических причин.
Вы можете использовать имя пользователя в качестве соли, которое может с меньшей вероятностью измениться, чем адрес электронной почты ( EDIT: 0xA3 правильно указано, это менее безопасно, чем использование адреса электронной почты, поскольку имена для входа, как правило, предположительно, и некоторые из них довольно часто используются, так что для них могут существовать радужные таблицы или их можно использовать повторно для других сайтов).
Кроме того, у вас есть столбец базы данных, в котором вы сохраняете соль для пароля.
Но тогда вы могли бы также использовать случайную специфичную для пользователя соль, которая также сложнее угадать.
Для лучшей безопасности вы можете использовать две соли: индивидуальную для пользователя и общесистемную (concat их, а затем хэш соли с паролем).
Кстати, простая конкатенация соли и паролей может быть менее безопасной, чем использование HMAC . В PHP 5 есть hash_hmac() вы можете использовать для этого:
$salt = $systemSalt.$userSalt; hash_hmac('sha1', $password, $salt);
EDIT: Обоснование для всей системы: она может и должна храниться за пределами базы данных (но создавайте резервную копию . Вы не сможете аутентифицировать своих пользователей, если вы ее потеряете). Если злоумышленник каким-то образом узнает ваши записи в базе данных, он все равно не может эффективно взломать хэши паролей, пока не узнает общесистемную соль.
EDIT (слегка не по теме):
Еще одно замечание о безопасности хэшей паролей: вы также можете прочитать « Почему соли делают словарные атаки« невозможными »? при многократном хэшировании для дополнительной защиты от атак с использованием жестокого форсинга и радуги (хотя я думаю, что повторное хеширование может ввести дополнительные возможности для атак типа «отказ в обслуживании», если вы не ограничите количество попыток входа за раз).
ЗАМЕТКА
Учитывая рост многоцелевых многоядерных систем (графических карт, программируемых микроконтроллеров и т. Д.), Может быть полезно использовать алгоритмы с высокой вычислительной способностью вместе с солями для борьбы с грубой силой, например, с использованием множественного хеширования, такого как PBKDF2. Тем не менее, вы должны ограничить количество попыток аутентификации на единицу времени для предотвращения атак DDoS.
Еще одно: Еще одним основным аргументом в пользу использования «настраиваемого» хеширования, основанного на широко используемых стандартах, а не широко используемой предварительно построенной функцией, был сам PHP, который оказался не заслуживающим доверия вообще, когда дело доходит до внедрения безопасности, будь то генераторы случайных чисел , не являющихся случайными, или функция crypt() , которая не работает вообще при определенных обстоятельствах, тем самым полностью обходя любые преимущества, которые должна принести функция хэширования, требующая вычисления или памяти.
Из-за их детерминированных результатов простые хеш-функции, скорее всего, будут проверены правильно, чем выходы функции деривации ключей, но ваш пробег может отличаться.
Я не эксперт по криптографии, однако есть три вещи, в частности, которые меня поражают, поскольку это вызывает проблемы с этим предложением.
Я не знаю, является ли это проблемой или нет, однако, что касается криптографии, это часто никто не знает, пока кто-то не разработал эксплойт (и к тому времени его слишком поздно), поэтому мой совет был бы ошибочным на стороне и не используйте адреса электронной почты в качестве соли.
Чтобы повысить безопасность, было бы лучше использовать случайную соль. Адреса электронной почты можно найти довольно легко, таким образом снижая эффективность соли. (Уточнено в комментариях)
Как уже упоминалось, соль лучше всего быть случайной. Цель соли – предотвратить атаки радужного стола с использованием предварительно вычисленных хеш-словарей.
Предполагая, что злоумышленник узнает хэшированные пароли и соли из вашей базы данных, если соль «a74kd% $ QaU», а пароль «12345», сможет ли он взломать ее с помощью радуги? Нет, даже если пароль слабый, у злоумышленника не будет предварительно вычисленного хеш-словаря для вашей случайной соли.
Если вы, однако, используете неслучайную соль, такую как идентификатор пользователя или адрес электронной почты, несколько более вероятно, что кто-то уже создал радужную таблицу для этой соли, надеясь найти пользователя с именем пользователя «john» или по электронной почте «john.doe@example .com " 1
1 Безопасность WPA для WLAN использует SSID точки доступа в качестве соли. Слишком плохо, кто-то уже предварительно вычислил хэши для наиболее часто встречающихся имен SSID.
Ophcrack (то, что большинство злоумышленников, вероятно, будет использовать, в зависимости от вашей функции шифрования) не содержит таблиц со специальными символами типа. или «@», если вы не попадете в самые большие («расширенные») таблицы. Поэтому использование электронной почты, вероятно, будет лучше, чем многие другие соли.
Как и все связанные с безопасностью, ответ зависит от вопроса, который не содержит информации о том, насколько безопасна ваша система. Самое безопасное здание – одно без окон или дверей; это также самое бесполезное здание.
С самого высокого уровня: нет, это не плохая идея. Это тоже не отличная идея. Однако это может быть достаточно хорошим – или более чем достаточно хорошим – для вашего приложения.
Если у кого-то есть радужный стол для определенного адреса электронной почты, сможете ли вы остановить их, используя хэширование пароля со случайной солью? Хорошие хакеры выходят на путь наименьшего сопротивления, что может включать в себя получение доступа root к вашей системе и загрузку таблиц солей и пользователей. (Разделяются ли они отдельно?) Если это так, они имеют до тех пор, пока смена пароля не будет соответствовать хешу, независимо от установленного в системе последовательного отказа от попытки входа в систему или того, что вы выбрали для соли.
Насколько сложнее возникает случайная соль в вашем приложении? Как определяется хакер, который вы пытаетесь сорвать? Какие другие меры – максимальная последовательная блокировка сбоя, принудительные периоды истечения срока действия пароля, входящие сообщения и предупреждения DoS, брандмауэры и т. Д. – есть ли у вас на месте? Ответ лежит где-то в сближении ответов на эти вопросы, а может быть и на других.