Как отмечалось ранее, использование MD5 для хеширования личных учетных данных или иного использования в процессе аутентификации и авторизации официально крайне не рекомендуется .
Однако ваш лучший шанс определить, хранит ли поле значение MD5 или не хэшированное значение и преобразовать его на лету, примерно так:
UPDATE TableName
SET Column = md5(Column)
WHERE Column !~ '^[a-f0-9]{32}$'
Могут быть оставшиеся, если кто-то действительно умный парень сгенерирует MD5-хэш чего-то и использует это непосредственно в качестве пароля. Это не будет обнаружено, но аутентификация должна завершиться неудачей в таком случае, поскольку сохраненное значение не будет соответствовать хэшу MD5 введенного пароля при входе в систему.
Вам также не следует не думать о передаче простых текстовых паролей в базу данных для хэширования и сравнения, поскольку поверхность атаки действительно уже достаточно высока. Даже если вы используете приличный TLS для соединений с базой данных, который гарантирует, что администратор или злоумышленник не включили запись медленных операторов с параметрами непосредственно в базе данных?
Вместо этого приложение должно использовать библиотеку для генерации соли и хешированного пароля напрямую и только передавать соль и хэш в хранилище. Формат, указанный в crypt , является общепринятым в отрасли (и поэтому настоятельно рекомендуется), для любого языка программирования существуют надежные библиотеки, и как только определенный алгоритм становится устаревшим, вы можете постепенно изменять его без согласованного однократного обновления .