Является ли MD5 менее безопасным, чем SHA et. Эл. в практическом смысле?
Я видел a несколько вопросы и ответы на так предполагая, что MD5 менее безопасен, чем что-то вроде SHA.
мой вопрос:стоит ли беспокоиться об этом в моей ситуации?
вот пример того, как я его использую:
- на стороне клиента, я обеспечиваю себя "обезопасить" контрольная сумма для сообщения, добавляя текущее время и пароль, а затем хэширования с помощью MD5. Итак:
MD5(message+time+password). - на стороне сервера я проверяю этот хэш против сообщения, отправленного с использованием моих знаний о времени его отправки и пароля клиента.
в этом примере мне действительно лучше использовать SHA вместо MD5?
при каких обстоятельствах выбор функции хэширования действительно вопрос в практическом смысле?
Edit:
просто уточнить -, есть ли какая-либо польза от перехода на алгоритм SHA?
другими словами, возможно ли в этом примере кому-то отправить сообщение и правильный хэш не зная общий пароль?
Изменения:
извинения за повторное редактирование - я не был ясен с тем, что я спрашивал.
11 ответов
Да, это стоит беспокоиться на практике. MD5 настолько сильно сломан, что исследователи смогли подделать поддельные сертификаты, которые соответствовали реальному сертификату, подписанному центром сертификации. Это означало, что они могли создать свой собственный поддельный центр сертификации и, таким образом, могли олицетворять любой банк или бизнес, который они чувствовали, с браузерами, полностью доверяющими им.
теперь это заняло у них много времени и усилий, используя кластер PlayStation 3s, и несколько недель, чтобы найти подходящее столкновение. Но после взлома хэш-алгоритм становится только хуже, никогда не лучше. Если вы заботитесь о безопасности, было бы лучше выбрать непрерывный алгоритм хеширования, например семья ша-2 (SHA-1 также ослаблен, хотя и не сломан так сильно, как MD5).
редактировать: метод, используемый в ссылке, которую я предоставил вам, включал возможность выбора двух произвольных префиксов сообщений и общего суффикс, из которого он может генерировать для каждого префикса блок данных, который может быть вставлен между этим префиксом и общим суффиксом, чтобы создать сообщение с той же суммой MD5, что и сообщение, построенное из другого префикса. Я не могу придумать способ, которым эта конкретная уязвимость может быть использована в ситуации, которую вы описываете, и в целом, используя secure has for проверка подлинности сообщения более устойчив к атаке, чем использование его для цифровых подписей, но я могу подумайте о нескольких уязвимостях, которые вам нужно остерегаться, которые в основном не зависят от выбранного вами хэша.
-
как описано, ваш алгоритм включает в себя хранение пароля в виде обычного текста на сервере. Это означает, что вы уязвимы для любых атак раскрытия информации, которые могут обнаружить пароли на сервере. Вы можете подумать, что если злоумышленник может получить доступ к вашей базе данных, то игра закончена, но ваши пользователи, вероятно, предпочтут, если даже сервер скомпрометирован, что их паролей не будет. Из-за распространения паролей в интернете многие пользователи используют одни и те же или похожие пароли в разных службах. Кроме того, атаки на раскрытие информации могут быть возможны даже в тех случаях, когда атаки на выполнение кода или эскалацию привилегий отсутствуют.
вы можете смягчить эту атаку, сохранив пароль на своем сервере, хэшированном случайной солью; вы сохраняете пару
<salt,hash(password+salt)>на сервере и отправьте соль клиенту, чтобы он может вычислитьhash(password+salt)использовать вместо пароля в протоколе, который вы упомянули. Однако это не защитит вас от следующей атаки. если злоумышленник может обнюхать сообщение, отправленное от клиента, он может выполнить автономную атаку словаря на пароль клиента. Большинство пользователей имеют пароли с довольно низкой энтропией, и хороший словарь из нескольких сотен тысяч существующих паролей плюс некоторое время случайным образом перестановки их может сделать поиск пароля, учитывая информация, которую злоумышленник имеет от обнюхивания сообщения довольно легко.
метод, который вы предлагаете, не аутентифицирует сервер. Я не знаю, является ли это веб-приложение, о котором вы говорите, но если это так, то кто-то, кто может выполнить атаку захвата DNS или DHCP-захват в незащищенной беспроводной сети или что-то в этом роде, может просто сделать атаку "человек в середине", в которой они собирают пароли в четком тексте из вашего клиенты.
в то время как текущая атака на MD5 может не работать против протокола, который вы описываете, MD5 был серьезно скомпрометирован, и хэш будет только слабее, никогда не сильнее. Хотите поспорить, что вы узнаете о новых атаках, которые могут быть использованы против вас, и у вас будет время обновить хэш-алгоритмы, прежде чем ваши злоумышленники смогут его использовать? Вероятно, было бы проще начать с чего-то, что в настоящее время сильнее MD5, чтобы уменьшить ваши шансы иметь дело с MD5 ломается дальше.
теперь, если вы просто делаете это, чтобы убедиться, что никто не подделывает сообщение от другого пользователя на форуме или что-то еще, то, конечно, маловероятно, что кто-то приложит время и усилия, чтобы нарушить протокол, который вы описали. Если кто-то действительно хотел олицетворять кого-то другого, они, вероятно, могли бы просто создать новое имя пользователя, которое имеет 0 вместо O или что-то еще более похожее, используя Unicode, и даже не беспокоиться о попытке подделать сообщение и сломать хэш-алгоритмы.
Если это используется для чего-то, где безопасность действительно имеет значение, тогда не изобрести собственную систему проверки подлинности. Просто используйте TLS / SSL. Одним из основных правил криптографии чтобы не изобретать свой собственный. И тогда даже для случая форума, где это, вероятно, не имеет большого значения, не будет ли проще просто использовать что-то, что доказано полке, чем собственное?
в этом конкретном случае я не думаю, что самое слабое звено вашего приложения использует md5, а не sha. Способ, которым md5 "сломан", заключается в том, что, учитывая, что md5(K) = V, можно создать K' такой, что md5(K') = V, потому что выходное пространство ограничено (не потому, что есть какие-либо трюки, чтобы уменьшить пространство поиска). Однако K 'не обязательно K. Это означает, что если вы знаете md5(M+T+P) = V, вы можете создать P' такой, что md5(M+T+P') = V, что дает действительную запись. Однако, в этом случае сообщение остается тем же самым, и P не был скомпрометирован. Если злоумышленник пытается подделать сообщение M' с меткой времени T, то маловероятно, что md5(M'+T'+P') = md5 (M'+T'+P), если P' = P. В этом случае они бы грубо принудили пароль. Если они грубо принудили пароль, то это означает, что не имеет значения, использовали ли вы sha или md5, так как проверка, если md5(M+T+P) = V эквивалентна проверке, если sha (M+T+P) = V. (За исключением того, что sha может принимать константу время больше для вычисления, что не влияет на сложность грубой силы на P).
однако, учитывая выбор, вы действительно должны просто идти вперед и использовать sha. Нет смысла не использовать его, если нет серьезного недостатка в его использовании.
во-вторых, вы, вероятно, не должны хранить пароль пользователя в своей базе данных в виде обычного текста. Что вы должны хранить хеш пароля, а затем использовать это. В вашем примере хэш будет иметь значение: md5(message + время + md5 (пароль)), и вы можете безопасно хранить md5(пароль) в своей базе данных. Однако злоумышленник, крадущий вашу базу данных (через что-то вроде SQL-инъекции), все равно сможет подделывать сообщения. Я не вижу другого выхода.
ответ Брайана охватывает вопросы, но я думаю, что это нужно объяснить немного менее подробно
вы используете неправильный алгоритм шифрования здесь
MD5-это неправильно здесь, SHA1 используется неправильно использовать здесь Sha2xx неправильно использовать и моток неправильно использовать.
то, что вы должны использовать, это что-то как RSA.
поясню:
Ваш безопасный хэш эффективно отправляет пароль для мира, чтобы увидеть.
вы упоминаете, что ваш хэш-это "время + полезная нагрузка + пароль", если третья сторона получает копию вашей полезной нагрузки и знает время. Он может найти пароль (используя грубую силу или атаку словаря). Таким образом, это почти так же, как если бы вы отправляли пароль в открытом тексте.
вместо этого вы должны смотреть на криптография с открытым ключом пусть ваш сервер отправит открытые ключи вашим агентам и агенты зашифруют данные с помощью public ключ.
ни один человек в середине сможем сказать, что в сообщениях, и никто не сможет подделать сообщения.
на боковой ноте,MD5 достаточно сильный большую часть времени.
Это зависит от того, насколько ценное содержимое сообщений. Семья SHA явно более безопасна, чем MD5 (где "более безопасный" означает "труднее подделать"), но если ваши сообщения являются обновлениями twitter, то вам, вероятно, все равно.
Если эти сообщения являются уровнем IPC распределенной системы, которая обрабатывает финансовые транзакции, то, возможно, вы заботитесь больше.
Update: я должен добавить также, что два алгоритма дайджеста по существу взаимозаменяемы во многих пути, так насколько больше проблем было бы действительно использовать более безопасный?
Update 2: это гораздо более подробный ответ:http://www.schneier.com/essay-074.html
Да, кто-то может отправить сообщение и правильный хэш, не зная общего пароля. Их просто нужно найти строку, хэш и то же значение.
Как это что? В 2007 году группа из Нидерландов объявила, что они предсказали победителя президентских выборов 2008 года в файле с хэш-значением MD5 3D515DEAD7AA16560ABA3E9DF05CBC80. Затем они создали двенадцать файлов, все идентичные, за исключением имени кандидата и произвольное количество следующих пробелов, которые хэшируются до этого значения. Хэш-значение MD5 бесполезно как контрольная сумма, потому что слишком много разных файлов дают один и тот же результат.
Это тот же сценарий, что и ваш, если я правильно вас понял. Просто замените "имя кандидата"на" секретный пароль". Если вы действительно хотите быть в безопасности, вам, вероятно, следует использовать другую хэш-функцию.
Если вы собираетесь создать хэш-mac, не изобретайте свою схему. использовать HMAC. существуют проблемы с выполнением хэша(секретный ключ || сообщение) и хэша (сообщение || секретный ключ). если вы используете пароль в качестве ключа, вы также должны использовать функцию вывода ключа. взгляните на PBKDF2 с.
да, стоит беспокоиться о том, какие хэш использовать в этом случае. Давайте сначала рассмотрим модель атаки. Злоумышленник может не только попытаться сгенерировать значения md5 (M+T+P), но и попытаться найти пароль P. В частности, если злоумышленник может собрать тупели значений MЯ, TЯ, и соответствующий md5 (MЯ, TЯ, P) тогда он / она может попытаться найти P. Эта проблема не изучалась так широко для хэш-функций, как поиск столкновения. Мой подход к этой проблеме состоял бы в том, чтобы попробовать те же типы атак, которые используются против блочных шифров: например, дифференциальные атаки. И поскольку MD5 уже очень восприимчив к дифференциальным атакам, я могу представить, что такая атака может быть успешной здесь.
поэтому я рекомендую использовать более сильную хэш-функцию, чем MD5 здесь. Я также рекомендую использовать HMAC вместо md5 (M+T+P), потому что HMAC был разработан для ситуации, в которой вы опишите и соответственно проанализируйте.
нет ничего небезопасного в использовании MD5 таким образом. MD5 был сломан только в том смысле, что существуют алгоритмы, которые, учитывая кучу данных, могут быть сгенерированы дополнительные данные B для создания желаемого хэша. Это означает, что если кто-то знает хэш пароля, они могут создать строку, которая приведет к этому хэшу. Хотя эти сгенерированные строки обычно очень длинные, поэтому, если вы ограничиваете пароли 20 или 30 символами, вы все еще, вероятно, в безопасности.
главная причина использовать SHA1 над MD5 является, чтобы MD5 функции прекращается. Например, библиотека Silverlight .Net не включает поставщика криптографии MD5.
MD5 обеспечивают больше столкновений, чем SHA, что означает, что кто-то может получить тот же хэш из другого слова (но это редко).
семья SHA была известна для ее надежность, SHA1 стандартна на ежедневной пользе, пока SHA256/SHA512 было стандартом для приборов правительства и банка.
для вашего личного веб-сайта или форума Я предлагаю вам рассмотреть SHA1, и если вы создадите более серьезную коммерцию, я предлагаю вам использовать SHA256 /SHA512 (семья SHA2)
оба MD5 amd SHA-1 имеют криптографические недостатки. MD4 и SHA-0 также скомпрометированы.
вы можете безопасно использовать MD6, Whirlpool и RIPEMD-160.
см. следующий powerpoint из Принстонского университета, прокрутите вниз до последней страницы.
Я не собираюсь комментировать MD5 / SHA1 / etc. проблема, поэтому, возможно, вы сочтете этот ответ спорным, но что-то, что меня немного забавляет, когда используется MD5 и др. для хэширования паролей в базах данных приходит.
Если кто-то копается в вашей базе данных, то они вполне могут захотеть посмотреть на ваши хэши паролей, но так же вероятно, что они захотят украсть личную информацию или любые другие данные, которые у вас могут быть в других таблицах. Честно говоря, в этой ситуации, у вас есть рыба и покрупнее.
Я не говорю игнорировать проблему, и, как я уже сказал, это не имеет большого отношения к тому, следует ли использовать MD5, SHA1 или что-то еще, чтобы хэшировать ваши пароли, но я получаю щекотку слегка розовым каждый раз, когда я читаю, что кто-то слишком расстроен простыми текстовыми паролями в базе данных.