Та же соль или другая соль?
У меня есть супер старая версия php (пожалуйста, не говорите мне, что обновление никогда не будет в нашем случае), и мне нужно хранить пароли. Я видел посты вроде этот и многое другое, что говорит, используйте крипты () php. Я просто путаюсь с одной вещью:
Мой вопрос в том, какой правильный способ хранения пароля; Использовать ОДНУ ОДНУ СОЛЬ для всех паролей разных пользователей или РАЗНОЕ СЛУЧАЙНО СОЛНЕЧНУЮ СОЛЬ для каждого пароля пользователей?
Мой вопрос возникает из-за моего опыта, я не видел базу данных / таблицу с солью в каждой строке, у некоторых есть одна соль в файле конфигурации, и она используется для подсчета всех паролей. Кроме того, я думаю, что хранение различной соли у каждого пользователя просто означает больше байтов для хранения.
Спасибо, ребята!
Решение
Вы хотите использовать другую соль. Идея заключается в том, что соль будет влиять на полученный хэш.
При «взломе» паролей, которые были раскрыты, злоумышленники будут использовать «радужные таблицы». По сути, это обратный поиск, который находит строки, которые хэшируют данное значение. Радужные таблицы также могут быть сгенерированы для общих паролей.
Если вы используете одну соль, хакеру нужно будет создать только один радужный стол. Если вы используете новую соль для каждого пароля, хакер должен создать радужные таблицы для каждого пароля, который он хочет скомпрометировать.
Это актуально для обновления вашего PHP для современных библиотек хеширования (например, bcrypt). Однако для старых версий PHP есть обратные порты, которые я серьезно рекомендую. Функции хеширования паролей рассчитаны на высокую вычислительную стоимость, поэтому пароль занимает много времени проверять. Идея состоит в том, что вы не можете проверить 1000 различных паролей за достаточно короткое время.
Другие решения
Создайте уникальную соль для каждого пароля, это единственный безопасный метод. Как вы можете вычислить хеш, зависит от того, сколько лет вашей версии PHP на самом деле:
Версия 5.5 PHP будет иметь встроенную поддержку BCrypt, функции password_hash () а также password_verify (). Эта функция сама генерирует безопасную соль и включает ее в результирующее хеш-значение.
Для PHP версия 5.3.7 и позже, существует пакет совместимости, от того же автора, который сделал функцию password_hash (). После этого вы уже можете использовать функцию password_hash (), и если вы переключитесь на более новую версию PHP, вам не придется менять свой код.
Для версий PHP до 5.3.7 нет поддержки crypt () с 2y, Unicode безопасный алгоритм BCrypt. Можно использовать пакет совместимости и заменить его на 2a, которая является лучшей альтернативой для более ранних версий PHP.
Для версий PHP до 5.3, нет поддержки BCrypt вообще. Ваша лучшая ставка, вероятно, будет Фреймворк phpass затем.
Обратите внимание, что crypt() функция будет не создайте безопасную соль самостоятельно, хотя она будет включать ее в результирующее хеш-значение. Для проверки он извлечет его оттуда.
Использование одной соли для каждого хеша всегда предотвратит атаку по радужному столу, если специально сгенерированная радужная таблица не будет создана с использованием соли, которую вы использовали, что астрономически невозможно, если ваша соль не является единичным символом или не была известна заранее.
Использование одной и той же соли для каждого хеша также отлично подходит для хакеров, которые имеют доступ к вашей базе данных SQL, но не к внутреннему коду.
Однако, если у хакера есть доступ к вашей статической соли, он делает ее почти бесполезной против скорости атаки методом грубой силы, которая уменьшит количество соли для каждого пользователя.
Вы должны использовать как жестко запрограммированную статическую соль, так и динамическую соль, чтобы предотвратить как атаку «радужным столом», так и смягчить атаку методом грубой силы.
detector