Да, на практике стоит побеспокоиться. MD5 настолько сильно сломан, что исследователи смогли подделать поддельные сертификаты, соответствующие реальному сертификату, подписанному центром сертификации. Это означало, что они могли создавать свои собственные поддельные центры сертификации и, таким образом, могли выдавать себя за любой банк или бизнес, который им казалось, с браузерами, полностью доверяющими им.
Теперь, это заняло у них много времени и усилий, используя кластер PlayStation 3, и несколько недель, чтобы найти подходящее столкновение. Но после взлома алгоритм хеширования становится только хуже, а не лучше. Если вы вообще заботитесь о безопасности, было бы лучше выбрать непрерывный алгоритм хеширования, такой как один из семейства SHA-2 (SHA-1 также был ослаблен, хотя и не сломан так же плохо, как MD5 есть).
edit : Техника, использованная в предоставленной мной ссылке, включала возможность выбора двух произвольных префиксов сообщений и общего суффикса, из которого он мог бы генерировать для каждого префикса блок данных, который мог бы быть вставляется между этим префиксом и общим суффиксом, чтобы создать сообщение с той же суммой MD5, что и сообщение, составленное из другого префикса. Я не могу придумать, каким образом эту конкретную уязвимость можно использовать в описываемой вами ситуации, и в целом использование защищенного ключа для аутентификации сообщений более устойчиво к атакам, чем использование его для цифровых подписей, но Я могу вспомнить несколько уязвимостей, на которые нужно обратить внимание, и которые в основном не зависят от выбранного вами хеша.
Как описано, ваш алгоритм предполагает хранение пароля в виде простого текста на сервере. Это означает, что вы уязвимы для любых атак раскрытия информации, которые могут обнаружить пароли на сервере. Вы можете подумать, что если злоумышленник сможет получить доступ к вашей базе данных, игра будет запущена, но ваши пользователи, вероятно, предпочтут, если даже если ваш сервер скомпрометирован, их пароли не будут. Из-за распространения паролей в сети многие пользователи используют одинаковые или похожие пароли в разных сервисах. Кроме того, атаки на раскрытие информации могут быть возможны даже в тех случаях, когда атаки на выполнение кода или повышение привилегий невозможны.
Вы можете смягчить эту атаку, сохранив пароль на вашем сервере, хэшированный случайным образом; Вы сохраняете пару <salt,hash(password+salt)> на сервере и отправляете соль клиенту, чтобы он мог вычислить hash(password+salt) для использования вместо пароля в протоколе, который вы упомянули. Однако это не защитит вас от следующей атаки.
Если злоумышленник может прослушать сообщение, отправленное клиентом, он может выполнить автономную атаку по словарю против пароля клиента. У большинства пользователей есть пароли с довольно низкой энтропией, и хороший словарь из нескольких сотен тысяч существующих паролей плюс некоторое время, произвольно переставляя их, может сделать поиск пароля, учитывая информацию, полученную злоумышленником, от перехвата сообщения довольно легким.
Метод, который вы предлагаете, не аутентифицирует сервер. Я не знаю, является ли это веб-приложением, о котором вы говорите, но если это так, то тот, кто может выполнить атаку DNS-перехвата, или перехват DHCP в незащищенной беспроводной сети, или что-то в этом роде, может просто сделать атака «человек посередине», при которой они собирают пароли в виде открытого текста от ваших клиентов.
Хотя текущая атака на MD5 может не работать против описанного вами протокола, MD5 серьезно скомпрометирован, и хеш будет только слабее, а не сильнее. Готов поспорить, что вы узнаете о новых атаках, которые могут быть использованы против вас, и у вас будет время обновить алгоритмы хэширования, прежде чем ваши злоумышленники смогут использовать его? Вероятно, было бы легче начать с чего-то, что в настоящее время сильнее, чем MD5, чтобы уменьшить ваши шансы справиться с MD5, сломанным дальше.
Теперь, если вы просто делаете это, чтобы убедиться, что никто не подделывает сообщение от другого пользователя на форуме или что-то в этом роде, то, конечно, вряд ли кто-то потратит время и усилия на то, чтобы нарушить протокол, который вы описали , Если кто-то действительно хочет выдать себя за кого-то другого, он может просто создать новое имя пользователя с 0 вместо O или что-то еще более похожее с помощью Unicode и даже не пытаться подделать сообщение и нарушить алгоритмы хэширования.
Если это используется для чего-то, что действительно важно для безопасности, не изобретайте свою собственную систему аутентификации. Просто используйте TLS / SSL . Одним из основных правил криптографии является не выдумывать свои собственные . И потом, даже в случае форума, где это, вероятно, не так уж важно, разве не будет проще просто использовать что-то проверенное с полки, чем раскручивать свое собственное?