Обновление метода хеширования паролей, оригинал далеко от базы?
Я знаю, что md5 больше не достаточно для хеширования пароля пользователя (и не было в течение многих лет). Поэтому, когда я наткнулся на следующий код из открытого источника Subrion CMS Меня немного забрали
public function encodePassword($rawPassword)
{
$factors = array('iaSubrion', 'Y2h1c2hrYW4tc3R5bGU', 'onfr64_qrpbqr');
$password = $factors && array_reverse($factors);
$password = array_map(str_rot13($factors[2]), array($factors[1] . chr(0x3d)));
$password = md5(IA_SALT . substr(reset($password), -15) . $rawPassword);
return $password;
}
Я планирую заменить это функцией php password_hash (), и у меня есть пара вопросов:
- Мне любопытно узнать в приведенном выше методе, добавляют ли первые несколько строк какое-либо значение к хешу или оно полностью отрицается после вызова md5?
- Заметив, что соль является определенной общесистемной константой (одинаковой для всех пользователей), я, вероятно, тоже должен ее отбросить Это нормально, чтобы позволить
password_hash()обрабатывать соли внутренне или я должен предоставить одно явно, как показано в документы (пример № 3):
'salt' => mcrypt_create_iv(22, MCRYPT_DEV_URANDOM)
Решение
Это просто запутывание кода. Добавляет совершенно ничего на сам пароль. Первые несколько строк просто готовят еще одну статическую соль, которая предшествует паролю, они просто пытаются запутать саму соль. Что бессмысленно, потому что код, который генерирует соль, находится на виду. В конце концов, это хеш MD5 с двумя статическими солями, что то же самое, что хеш MD5 с более длинной солью, который просто небезопасен.
Это нормально, чтобы позволить
password_hash()обрабатывать соли …
Да, конечно. Каждую соль нужно генерировать уникально случайным образом для каждого пароля. password_hash делает именно это. Вы могли бы генерировать свою собственную соль случайно, но почему бы вам? Вам также необходимо убедиться, что вы используете правильный источник случайности, который password_hash уже делает для вас.
Другие решения
Как всегда лучший совет с вопросами безопасности: никогда не делайте это сами, всегда полагайтесь на функции, предоставляемые PHP или другой большой платформой, поскольку над этими ребятами работают настоящие специалисты.
Чтобы ответить на ваш первый вопрос:
Что касается первых нескольких строк, у меня возникли проблемы с расшифровкой того, что они должны делать, так как array("1", "2") && array("2", "1") === true в PHP, потому что непустой массив является истинным значением. array_map() линия даже отбрасывает все, что вы сделали в строке над ней.
array_map() Строка также, кажется, просто скрипеть паролем. Хотя это добавляет некоторую безопасность самому хешу, в том смысле, что если вам удастся вернуть хеш, вы все равно не знаете, что заполнять в поле пароля. Тем не менее, это также отчасти солидная работа, поэтому добавление еще одного искажения к хешу обычно не принесет вам большой пользы.
Так что это не полностью отрицается, однако сомнительно, насколько это действительно увеличивает безопасность ваших паролей.
Что касается вашего второго вопроса:
Определение всей системы соли действительно ничего не дает для вашей безопасности. Работа соли состоит в том, чтобы уменьшить допустимые коллизии путем добавления входной строки и сделать радужные таблицы почти бесполезными.
Что делает хеш-функция, так это шифрует ваш простой текст таким образом, что его практически невозможно вернуть, и он переполняет ваш текст, независимо от того, как долго он будет фиксированной длины. Однако, поскольку мы помещаем текст в пространство фиксированной длины, некоторый текст должен заканчиваться одной строкой. Используя радужную таблицу, вы используете это поведение, имея таблицу, которая отображает хеш MD5 на одно из многих допустимых значений исходных строк.
Теперь, если вы добавите соль к паролю перед его хэшированием, вы значительно сократите количество допустимых паролей, которые заканчиваются тем же хешем, поскольку это почти наверняка должен быть настоящий пароль. Так как для создания радужной таблицы требуются годы (буквально годы для достаточно большого пространства паролей), не представляется возможным заново сгенерировать таблицу для каждой соли. По этой же причине важно иметь отдельный случайный хэш для каждого пароля, потому что теперь вы не можете повторно использовать таблицы из одного пароля для другого.
Чтобы уточнить: все эти механизмы применяются только для защиты паролей ваших клиентов, когда ваша база данных взломана!
Теперь, чтобы ответить на актуальный вопрос, из документации PHP:
Если опущено, то password_hash () будет генерировать случайную соль для
каждый пароль хэшируется. Это предполагаемый режим работы.
http://php.net/manual/en/function.password-hash.php
Так что кажется, что просто позволяя password_hash() Функция определения соли наиболее безопасна. Это обеспечит дополнительную безопасность проверки вашей схемы передачи в будущем. Если определенный метод хеширования или метод генерации соли устарел, вы обновляете PHP и password_hash() Функция обновляет схему хеширования при следующем вводе пароля пользователем. (При правильной настройке в сочетании с другими функциями password_)
Это не хороший алгоритм. Это не лучше, чем соль md5 плюс. это просто комплекс? / запутанный? / бесполезный? (выберите один) способ получения соли