Шифрование в MD5 больше не безопасно

«Все пароли нужно хранить, предварительно захэшировав их в MD5» — классика любой статьи по информационной безопасности. Но, к сожалению, в 2016 она давно потеряла свою актуальность, и всё уже не так просто. Вас не спасет md5('пароль'), md5(md5('пароль')) и даже md5(md5(md5('пароль'))).

Так называемые радужные таблицы — инструмент для взлома хэшэй, который сегодня доступен любому, кто вобьет это слово в Google. Храня сопоставление исходной строки и её хэша, они позволяют легко обратить любую «необратимую» хэш-функцию.

Современные радужные таблицы хранят каждое слово, когда-либо встречавшееся на форумах, в Википедии и интернете в принципе, а также все его формы.

Как защититься?

Хорошим способом защититься будет использование соли при хэшировании — это когда к исходному паролю добавляется рандомная строка.

Простой пример на PHP:

			$password = 'password'; // Сам пароль
$hash = md5($password); // Хэшируем первоначальный пароль
$salt = 'sflprt49fhi2'; // Соль

// Солим пароль: конкатенируем старый хэш с солью и ещё раз хэшируем
$saltedHash = md5($hash . $salt);
		

В данном примере соль является статической строкой, в реальных проектах следует применять только динамическую (то есть каждый раз новую) соль.

Более правильный пример с использованием STL языка PHP:

			$hash = crypt('password'); // crypt генерирует соль и хэширует, используя алгоритм по умолчанию
// crypt извлекает соль из существующего хэша и хэширует входящий пароль с её использованием
if (crypt($password, $hash) == $hash) {
   // Пароль верен
}
		

Но на самом деле подумайте о том, что в 2012 году Пол-Хеннинг Кэмп, один из разработчиков FreeBSD, призвал полностью отказаться от созданного им алгоритма md5crypt, как не обеспечивающего в современных условиях ощутимого увеличения времени вычисления хэша, а значит, и не защищающего от полного перебора.