Переход от несоленых к соленым паролям MD5

Question

У меня есть веб-сайт LAMP (PHP), который становится популярным.

Я проиграл, сохранив пароли пользователей в виде хэшей md5.

Но теперь я вижу, что это не безопасно; Мне следовало посолить хеш md5 - потому что в настоящее время можно декодировать несоленые хеш md5, используя радужные таблицы.

Что я могу сделать?

Я не хочу заставлять всех вводить новый пароль.

Answer 1

Вы можете сделать "двухэтапное хэширование" вместо создания хэша за один шаг.

Вы можете добавить каждый хэш пароля к имени пользователя, а затем снова его хешировать. Это создаст недопустимый хеш с уникальной информацией.

Обычный процесс засола

соль + PWD -> хэш

Вы могли бы сделать что-то вроде: PWD -> Hash -> UserID + Hash -> Hash

(Обратите внимание, что UserID был выбран только для того, чтобы существовала уникальная соль для каждого двойного хеша ... Не стесняйтесь, чтобы сделать вашу соль более сложной)

Answer 2

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

Единственная проблема - вам нужно добавить индикатор того, солен ли каждый MD5 или нет, поскольку какое-то время у вас будет смесь обоих. Или, для незначительной потери безопасности, вы можете проверить каждый пароль соленый и несоленый и, если любой из них ударил, принять логин. Конечно, если вы обнаружите, что это несоленый, то вы обновитесь в этот момент.

Answer 3

Ответ прост: убедитесь, что сохраняете запись или какой-либо флаг, у которого у пользователей есть пароли в новой системе хеширования, при следующем входе в систему, аутентификации их, вычислении нового хэша, изменении флага.

Теперь, когда кто-то входит в систему и установлен флаг, аутентифицируйте его с новым хешем.

Answer 4

Почему бы не добавить новый столбец new_pwd в свою пользовательскую таблицу, в которой хранится результат md5($originallyHashOfPwd . $salt). Затем вы можете предварительно вычислить new_pwd и, как только это будет сделано, настроить проверку входа в систему, чтобы сравнить результат md5(md5($entered_pwd) . $salt) с тем, что в new_pwd. Когда вы закончите переключение проверки входа, удалите старый столбец.

Это должно остановить атаки в стиле радуги.

Answer 5

Вы все еще можете использовать соль. Просто вычислите другой хеш из текущего хеша вместе с солью:

$newHash = md5($salt.$oldHash);

Для новых паролей вам необходимо использовать:

$hash = md5($salt.md5($password));

Answer 6

Отличный способ обновить пароли, а также сделать их более безопасными, - перейти на использование соленого SHA1 для паролей. SHA1 сложнее создать столкновение, и он также имеет длину строки, отличную от MD5. Длина MD5 составляет 32 символа, а SHA1 - 40 символов.

Чтобы преобразовать их в PHP, сначала проверьте длину строки сохраненного пароля. Если длина составляет 32 символа, проверьте пароль, используя старый метод, а затем запишите новый, используя SHA1, в базу данных.

Если я правильно помню, именно так WordPress справился с этой проблемой.

Answer 7

Если вы уходите от MD5, вам следует просто пропустить посолку и перейти к еще лучшей технике, называемой растяжкой. В частности, вы должны использовать bcrypt (реализован как PHPASS с php).

Вот отличная ссылка, почему bcrypt: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

А вот кратко Как: 1. Загрузите пакет phpass: http://www.openwall.com/phpass/ 2. Посмотрите на test.php примеры, подобные приведенному ниже:

require 'PasswordHash.php';
$t_hasher = new PasswordHash(8, FALSE);
$correct = 'plaintextpassword';
$hash = $t_hasher->HashPassword($correct);
$check = $t_hasher->CheckPassword($correct, $hash);

Если $ check === true (как в случае выше), тогда пароль правильный. Если ваш пароль 'hello', вы бы его хешировали, используя HashPassword, помещали хеш в базу данных, а когда пользователь входил в систему, вызывали CheckPassword (userenteredpassword, hashInDb), чтобы проверить, верен ли пароль

Answer 8

Соль оригинального хэша, как упоминалось другими. Просто несколько указателей здесь:

• Соли тем лучше, чем дольше. Также, если они содержат больше, чем просто [a-z0-9], но длина лучше в первую очередь.
• Если у кого-то уже есть копия вашей БД и вы перефразируете те же пароли солью, перефразировать старый хеш соль не будет. Вместо этого вы действительно должны заставить пользователей сделать новый пароль.
• Вы должны сопоставить новые пароли (и пароли, которые будут добавлены) с различными списками наиболее часто используемых паролей. Они используются в атаках "грубой силы". Запрашивать / заставлять пользователя сменить пароль.

Answer 9

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

При успешном входе пользователя в систему, если новый столбец пуст, введите более надежный пароль и очистите исходный столбец. Если в новом столбце есть запись, сравните вход со значением в нем.

Answer 10

Динамическое повторное шифрование паролей при следующем входе пользователей в систему, т. Е. Сначала проверьте, правильно ли оно, затем зашифруйте его солью и сохраните снова.