Адрес электронной почты как пароль соли?

Question

Неплохо ли использовать адрес электронной почты как salt для получения пароля?

Answer 1

EDIT:
Сошлюсь на этот answer on Security StackExchange который объясняет много подробностей о хэширование паролей и ключевой вывод.

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

Если у вашей языковой библиотеки есть функция для нее, проверьте на обновления, что она делает то, что она должна делать, особенно если это PHP.

Ответ на этот вопрос по историческим причинам.

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

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

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

Кстати, простая конкатенация соли и паролей может быть менее безопасной, чем использование HMAC. В PHP 5, есть функция hash_hmac() вы можете использовать для этого:

$salt = $systemSalt.$userSalt; 
hash_hmac('sha1', $password, $salt); 

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

EDIT (немного не по теме):
Еще записка о безопасности пароля хэш: Вы также можете прочитать Why do salts make dictionary attacks 'impossible'? на хэширования несколько раз для дополнительной защиты от грубой форсирования и радужных атак таблицы (хотя Я думаю, что повторное хеширование может создать дополнительные возможности для атак типа «отказ в обслуживании», если вы не ограничите количество попыток входа за раз).

ПРИМЕЧАНИЕ

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

Еще одна вещи: Другие основнымы обоснование для использования «обычая» хэширование построено на широко используемые стандарты, а не широко используются преднастроенная функция сама PHP, которая зарекомендовала себя не заслуживающие доверия на всех, когда он приходит к внедрению связанных с безопасностью вещей, будь то генераторы случайных случайных чисел или crypt() function that does not work at all при определенных обстоятельствах, таким образом, полностью обходит любые преимущества, которые должна принести функция хэширования паролей с интенсивным вычислением или памятью.
Из-за их детерминированных результатов простые хеш-функции, скорее всего, будут проверены правильно, чем выходы функции деривации ключей, но ваш пробег может отличаться.

Answer 2

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

Answer 3

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

1. Как указывает Марк, электронное письмо может измениться, однако соль должна оставаться неизменной для данного пароля (иначе вы не сможете проверить правильность пароля).
2. Размер адресов электронной почты является переменным, и я полагаю, что важно, чтобы соль была больше определенного размера.
3. Использование адреса электронной почты делает соль много более предсказуемой, что обычно плохо в криптографии.

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

Answer 4

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

Предполагая, что злоумышленник узнает хэшированные пароли и соли из вашей базы данных, если соль «a74kd% $ QaU», а пароль «12345», сможет ли он взломать ее с помощью стола радуги? Нет, даже если пароль слабый, у злоумышленника не будет предварительно вычисленного хеш-словаря для вашей случайной соли.

Если вы используете неслучайную соль, такую ​​как идентификатор пользователя или адрес электронной почты, это несколько более вероятно, что кто-то уже создал радужный стол для этой соли, надеясь найти пользователя с именем пользователя «john» или по электронной почте «john» .doe @ example.com»

WPA безопасности для беспроводных сетей использует SSID точки доступа в виде соли. Слишком плохо, кто-то уже pre-computed hashes для наиболее часто встречающихся имен SSID.

Answer 5

Ophcrack (что, скорее всего, будет использовать большинство злоумышленников, в зависимости от вашей функции шифрования) не содержит таблиц со специальными символами типа '.' или «@», если вы не попадете в самые большие («расширенные») таблицы.Поэтому использование электронной почты, вероятно, будет лучше, чем многие другие соли.

Answer 6

Как и все связанные с безопасностью, ответ зависит от вопроса, который не содержит информации о , как безопасно вы хотите, чтобы система была. Самое безопасное здание - одно без окон или дверей; это тоже самое бесполезное здание.

С самого высокого уровня: нет, это неплохая идея. Это тоже не отличная идея. Однако это может быть достаточно хорошим - или более чем достаточно хорошим - для вашего приложения.

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

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