EDIT:
Позвольте мне отослать вас к этому ответу по Security StackExchange , который объясняет множество деталей о хешировании паролей и получении ключей.
Итог: Используйте безопасную установленную схему хеширования паролей, которая требует значительных ресурсов для защиты от атак методом перебора, но ограничивает количество разрешенных вызовов для предотвращения отказа в обслуживании (DoS). атаки.
Если в вашей языковой библиотеке есть функция, при обновлении проверьте, что она делает то, что должна, особенно если это PHP.
Ответ, приведенный ниже, оставлен по историческим причинам.
Вы можете использовать имя пользователя для входа в систему как соль, которая может измениться реже, чем адрес электронной почты ( РЕДАКТИРОВАТЬ: 0xA3 правильно указано, это менее безопасно чем использование адреса электронной почты, потому что имена для входа, как правило, легче угадать, а некоторые довольно часто используются, так что радужные таблицы уже могут существовать для них или могут быть использованы для других сайтов).
В качестве альтернативы, есть столбец базы данных, в котором вы сохраняете соль для пароля.
Но тогда вы могли бы также использовать случайную пользовательскую соль, которую сложнее угадать.
Для большей безопасности вы можете использовать две соли: пользовательскую и общесистемную (объединить их, затем хешировать соли с паролем).
Кстати, простое объединение соли и паролей может быть менее безопасным, чем использование HMAC . В PHP 5 есть функция hash_hmac(), которую вы можете использовать для этого:
$salt = $systemSalt.$userSalt;
hash_hmac('sha1', $password, $salt);
РЕДАКТИРОВАТЬ: Обоснование для всей системы соли: она может и должна храниться вне базы данных (но резервное копирование . Вы не сможете аутентифицировать своих пользователей если ты его потеряешь). Если злоумышленнику каким-то образом удастся прочитать записи вашей базы данных, он все равно не сможет эффективно взломать хеши паролей, пока не узнает общесистемную соль.
РЕДАКТИРОВАТЬ (немного не по теме):
Еще одно замечание о безопасности хэшей паролей: вы также можете прочитать Почему соли делают невозможными атаки по словарю? при многократном хешировании для дополнительной защиты от грубых атак и атак радужных таблиц (хотя я подумайте, что повторное хеширование может создать дополнительные возможности для атак типа «отказ в обслуживании», если вы не ограничите количество попыток входа в систему за раз).
Примечание
Учитывая рост многоцелевых многоядерных систем (видеокарты, программируемые микроконтроллеры и т. Д.), Может быть целесообразно использовать алгоритмы с высокими вычислительными затратами наряду с солями для противодействия взлому, например используя многократное хеширование, как PBKDF2. Однако вам следует ограничить количество попыток аутентификации за единицу времени, чтобы предотвратить атаки DDoS.
Еще одна вещь: Еще одним основным обоснованием использования «пользовательского» хэширования, построенного на широко используемых стандартах, а не на широко используемой предварительно созданной функции, был сам PHP, который доказал, что не заслуживает доверия вообще, когда дело доходит до реализации связанных с безопасностью вещей, будь то генераторы случайных чисел, которые не так случайны, или функция crypt(), которая вообще не работает при определенных обстоятельствах, тем самым полностью обойдя любые преимущества, которые должна обеспечить функция хеширования паролей, требующих большого объема вычислений или памяти.
Из-за их детерминированных результатов простые хэш-функции с большей вероятностью будут протестированы должным образом, чем выходные данные ключевой деривационной функции, но ваш пробег может отличаться.