Эта страница в Википедии имеет обширный список методов хеширования
Как видите, и MD5, и Sha1 были сломаны (в криптографии «сломанный» означает, что существует атака менее сложная, чем атака грубой силы. Другими словами, если вам нужен 1 миллион лет, чтобы найти коллизию, вместо миллиарда лет с использованием грубой силы алгоритм считается сломанным, даже если его использование, вероятно, все еще безопасно)
Что вы используете в качестве хеш-алгоритма?
SHA1 не работает, но для вычисления столкновения все еще требуется миллиард лет.
Другие хэши все еще не разорваны, но мы должны помнить, что исследователи концентрируют свои усилия на основном алгоритме (то есть MD5 и SHA1), поэтому неразбитые хэши также могут быть небезопасными.

Есть и другие, такие как SHA-256 или РИПЭМД-160, или даже один из кандидатов SHA-3 (см. Список здесь для выбора. Всегда помните, что они не были так тщательно протестированы и проанализированы, как MD4 / 5 и SHA-1. также, конечно, стоимость с точки зрения производительности.
Один из ответов на ваш вопрос - использовать два из них, надеюсь, достаточно разных, чтобы нарушение одного не сломало другое. Шансы на то, что оба они будут достаточно сломаны, чтобы подделать две контрольные суммы, довольно ужасны, ИМХО.
Если вас беспокоит безопасность, лучше избегать «сломанных» хэш-функций. То, что вы сказали, может быть правдой для некоторых хеш-функций, которые только что взломаны исследователями, но вскоре может появиться реальная атака, если использовать новые идеи, полученные в ходе исследовательской работы.
Например, коллизии MD5 теперь можно найти очень быстро (я думаю, что википедия упомянула метод, который может сделать это за несколько минут, но поправьте меня, если я ошибаюсь).
Вы не хотите повторно вычислять весь свой хэш / подпись для множества вещей, которые вы уже вычислили, на случай, если это произойдет.
Да, насчет MD5 ты прав. Что касается SHA1, он не работает, но вам все еще нужны миллиарды лет, чтобы вычислить коллизию.
Я использую Whirlpool hash. Однако ... вы не должны полагаться на хеширование для защиты паролей. Если вы храните пароль в базе данных, всегда использует приличную соль (которая помогает предотвратить атаки и коллизии радужных таблиц).
И следуйте другим подходящим правилам безопасности для вашей платформы :)
Да, использование соли обязательно. Но даже при использовании приличной соли MD5 остается серьезно сломанной. Я посмотрю на хэш Whirlpool. Спасибо:)
Это зависит от того, для чего я использую хеш ... Безопасность? Обнаружение изменения файла? Найти дубликаты файлов?
Судя по тому, как был задан вопрос, я предполагаю, что первая причина, по которой вы используете хеши. В этом случае я бы рекомендовал не использовать «ломаный» метод.
Если это не безопасность использования (например, поиск дубликатов файлов), MD5 работает нормально и работает быстрее.
Действительно, я использую хеши для хранения паролей пользователей.
Насколько я понимаю, сломанная часть MD5 заключается в том, что кто-то из с оригиналом text теперь может легко создать текст второй, который имеет тот же дайджест MD5.
Тем не менее, у кого-то, у кого есть только MD5-дайджест этого исходного текста, все еще невозможно создать второй текст, который ему соответствует.
Атака md5 еще слабее. То, что вы описываете, называется вторым прообразом, и мы не знаем быстрого способа найти его для MD5. Злоумышленник может создать два сообщения с одинаковым хешем.
@CodesInChaos верно, MD5 не "сломан" в том смысле, что грубая сила по-прежнему является единственным способом найти простой текст для заданного хэша. Ну, и поиск хешей в Google ;-)
В наши дни большинство людей все еще используют SHA1 или даже MD5, сломанный или нет. Поскольку текущее состояние хеширования таково, что у нас есть некоторые функции, которые, как мы знаем, имеют теоретические уязвимости, но не имеют действительно практических проблем, а также некоторые недоказанные функции, о которых мы вообще очень мало знаем.
Если вы используете хеш-функцию для хранения паролей, теоретические уязвимости, вероятно, для вас не имеют значения. Во-первых, потому что природа уязвимостей не очень помогает в изменении паролей. Во-вторых, если вы так сильно заботитесь о безопасности, вы, вероятно, не будете использовать пароли.
Более важно, если вы используете цифровую подпись, SSL, IPSEC и т. д., Которые полагаются на хэш-функции, и если вам нужно, чтобы хеш-функция оставалась защищенной в течение длительного времени. Однако здесь у вас нет выбора, кроме как подождать и посмотреть, какая хеш-функция (-ы) станет новым проверенным стандартом, и / или использовать более одной хеш-функции, если можете.
Но даже в этом случае это далеко не полный список угроз. Проблемы безопасности в вашей системе гораздо чаще связаны с вашим собственным кодом или угрозами для людей, чем с кем-то, кто атакует вашу хеш-функцию!
Тем не менее, если вы разрабатываете новую систему, совет по ее разработке так, чтобы вы могли заменить любой ваших криптоалгоритмов в любое время, остается ценным. В идеале через конфигурацию / плагин, а не перекомпиляцию.
Используйте нет MD5 или SHA1 для хеширования паролей! Используйте bcrypt или даже лучше lib. Также см. security.stackexchange.com/questions/19906/…
В 2020 году это плохой, устаревший ответ. Используйте bcrypt для паролей (где вам нужно, чтобы ваш алгоритм хеширования был медленным) и SHA256 или BLAKE2b для таких вещей, как сравнение файлов (где вам нужно, чтобы ваш алгоритм хеширования был быстрым).
Это также обсуждается в https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords и https://security.stackexchange.com/questions/56397/which-hashing-algorithm-is-ideal-for-use-on-the-web.
TL; DR: