Итак, каким же образом обеспечивается безопасность на нынешних веб-ресурсах? Хешированием паролей алгоритмом md5. Вроде бы всё здорово и замечательно — md5 есть функция необратимая и пароли, хранимые в виде таких хэшей, взломать нельзя, даже если злоумышленник получил доступ к базе. Ан нет! Вспоминаем про Rainbow-таблицы и прощаемся с мыслью о полной безопасности хранения паролей в таком виде. Та как же их тогда шифровать? Алгоритмы востановимого шифрования с ключами тоже не панацея, да и системных ресурсов сии функции кушают немало...
Вопрос: Так как же, не в ущерб производительности, обезопасить md5 хэши от Rainbow-таблиц?
Ответ: соль.
Суть метода заключается в следующем. А кто нам мешает при генерации хэша, помимо голого md5, ввести ещё каки-либо операции над паролем? Правильно, никто :) Тогда новый, "засоленый", хэш определяем следующим образом (классическая схема; используется, например, в *nix'ах ):
хэш = соль + md5(соль+пароль)
или на PHP:
Таким образом мы получаем хэш, увеличенной длинны с конкатенацией пароля с той же самой солью. Естественно, что в таком случае генерацией Rainbow-таблиц, именно для этой соли, никто заниматься не будет. В принципе, достаточно ограничиться конкатенацией соли с паролем и от этого брать md5 — всё равно результат взломать, даже зная соль, практически невозможно.
"Подперчить" сей метод можно добавив динамики в генерацию соли т.е. при правильном вводе пользователем его пароля, динамически заменять соль на новую, например, при каждом 10-ом логине или каждую неделю. Кстати, если соль сделать из 8-ми абсолютно случаных символов, то при взломе такого хэша, система взлома может распознать его как SHA-хэш и априорно начнёт двигаться в ложном направлении.
А можно, коли руки чешутся поминусовать, это как-то обосновывать в комментариях? Спасибо.
Вопрос: Так как же, не в ущерб производительности, обезопасить md5 хэши от Rainbow-таблиц?
Ответ: соль.
Суть метода заключается в следующем. А кто нам мешает при генерации хэша, помимо голого md5, ввести ещё каки-либо операции над паролем? Правильно, никто :) Тогда новый, "засоленый", хэш определяем следующим образом (классическая схема; используется, например, в *nix'ах ):
хэш = соль + md5(соль+пароль)
или на PHP:
function md5WithSalt($pass, $salt = "someDefaultSalt"){<br>
$hash = $salt;<br>
$hash .= md5($salt.$pass); <br> return $hash;<br>}
Таким образом мы получаем хэш, увеличенной длинны с конкатенацией пароля с той же самой солью. Естественно, что в таком случае генерацией Rainbow-таблиц, именно для этой соли, никто заниматься не будет. В принципе, достаточно ограничиться конкатенацией соли с паролем и от этого брать md5 — всё равно результат взломать, даже зная соль, практически невозможно.
Дальше -больше
"Подперчить" сей метод можно добавив динамики в генерацию соли т.е. при правильном вводе пользователем его пароля, динамически заменять соль на новую, например, при каждом 10-ом логине или каждую неделю. Кстати, если соль сделать из 8-ми абсолютно случаных символов, то при взломе такого хэша, система взлома может распознать его как SHA-хэш и априорно начнёт двигаться в ложном направлении.
А можно, коли руки чешутся поминусовать, это как-то обосновывать в комментариях? Спасибо.