Движение от несоленого до соленых паролей MD5

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

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

Обычный процесс соления:

salt + PWD -> hash

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

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

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

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

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

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

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

Это должно остановить атаки в стиле радужной таблицы.

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

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

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

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

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

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

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

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

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

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

Здесь два варианта

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

Насколько я понимаю, другого способа восстановления паролей нет.

]РЕДАКТИРОВАТЬ: Хотя MD5 является хешем и его нельзя декодировать, его можно разбить с помощью радужных таблиц: с вероятностью почти единица вы можете найти уникальную (вот вероятность) строку не более чем, скажем, из 20 символов с заданным хешем, особенно если ваш набор символов ограничен, скажем, буквенно-цифровым. Строго говоря, это не декодирование. Для всех практических целей это так. Дополнительное примечание: создание радужных таблиц и поиск паролей 1000 по-прежнему займет много времени.

Добавьте исходный хеш-код, как упоминалось другими. Несколько советов:

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

к сожалению, ваш единственный способ - попросить пользователей обновить свои пароли.

вы также можете сгенерировать случайные пароли, но это та же проблема.

изменить

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

md5(md5($new_password).$salt).':'.$salt

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

md5($old_password.$salt).':'.$salt

, чтобы проверить правильность предоставленного пароля, просто используйте

list($stored_password, $salt) = explode(':', $salted_password);
if(md5(md5($provided_password).$salt) == $stored_password) {
  // you are now logged in
}