Насколько безопасны MD5 и SHA1

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

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

Общий совет - сначала изучить уровень безопасности, которого вы хотите достичь в своем сценарии, и решить, какие технологии (в данном случае хеширование) вы используете. 100% безопасности тоже нет. Также не тратьте слишком много времени на одни проблемы безопасности и игнорируйте другие, которые могут быть не столь очевидными или техническими (человеческие ошибки, безопасность через неизвестность, человеческая инженерия).

Проверь это:

1. сгенерируйте хеш для маленького слова здесь. Например, password имеет хеш MD5: 5f4dcc3b5aa765d61d8327deb882cf99
2. теперь перейдите сюда и запросите текст.

Приведенный выше пример - лишь один из многих возможных способов взлома (атака по словарю). Также статьи в Википедии о каждом алгоритме безопасности содержат список уязвимостей.

ТАКЖЕ СМ:

• Является ли MD5 менее безопасным, чем SHA et. al. в практическом смысле?

БОКОВОЕ ПРИМЕЧАНИЕ

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

Вот сравнение между MD5 и SHA1. Вы можете получить четкое представление о том, какой из них лучше.

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

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

Еще одна - возможность перехвата пары логин + хеш-пароль из клиентской или клиент-серверной транзакции. Если на клиенте нет троянского коня и связь между клиентом и сервером защищена TLS, пара должна быть защищена от атак типа «злоумышленник в середине».

Злоумышленнику остается (помимо социальной инженерии, xss и взлома безопасности хостинга) впоследствии отправить количество сгенерированных запросов на сервер входа в систему и посмотреть, будет ли один из них успешным. Этим тоже можно управлять:

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

Я считаю, что при реализации вышеуказанных правил хеш md5 будет достаточно безопасным. На самом деле он так же безопасен, как и простой пароль :) Подводя итог, если мы считаем, что наш хеш md5 безопасен, мы можем просто оставить пароли открытыми. Дело в том, что в настоящее время md5 вообще не используется (в том, что касается обфускации паролей). Что нужно сделать, так это оставить его в хранилище в доверенной зоне или использовать какой-нибудь более сильный инструмент (например, SHA), когда доверенной зоной не нужно управлять. И, на мой взгляд, доверенная зона все еще находится под угрозой нарушения безопасности сервера (службы хостинга), поэтому в любом случае просто запутайте пароли с помощью SHA (или лучше) :) Это не должно быть дорогостоящим, чтобы укрепить хеширование паролей и это приносит некоторые преимущества (снижает риски), поэтому я советую никогда больше не возвращаться к этому обсуждению.

Тем не менее, даже при хешировании SHA все устные правила безопасности должны быть реализованы. Особенно TLS, который предотвращает компрометацию пары логин + пароль (независимо от того, отправляется ли пароль простым или хешированным с помощью md5 или sha, он может обеспечить успешный вход в систему). Также следует отслеживать попытки входа в систему. Даже если мы считаем, что наш сайт защищен от перебора, хорошо знать, что кто-то пытается взломать систему безопасности.