Шифрование паролей

Question

Я прочитал несколько вопросов, которые предлагают хешировать пароли и хранить их в базе данных.

Когда кто-то входит в систему, вы хэшируете пароль, который вы сохранили.

Что я не понимаю, как это может работать ?? Две строки могут хешировать одно и то же значение - маловероятно, но, безусловно, возможно

Может кто-нибудь помочь мне, пожалуйста?

РЕДАКТИРОВАТЬ: Кто-нибудь может дать статистику вероятности столкновения?

Answer 1

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

Хэширование паролей не позволяет администраторам баз данных видеть пароль.

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

PS также неплохо было бы солить пароли перед хэшированием, чтобы еще больше усложнить взлом, если хакер каким-то образом получил доступ к таблице паролей. Усложняет использование радужных столов и т. Д.

Answer 2

Две строки могут хэшировать одно и то же значение - Маловероятно, но, безусловно, возможно

Да, но если хеш достаточно большой и хорошего качества, вряд ли о чем беспокоиться. В разговорной речи: каждый пользователь приложения, пораженный молнией одновременно, не похож, но определенно возможно. Вы беспокоитесь об этом?

Answer 3

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

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

Если вы хотите использовать хеширование в .NET, попробуйте что-то вроде

    public static string ComputeHash(string plaintext)
    {
        HashAlgorithm mhash = new SHA1CryptoServiceProvider();
        byte[] bytValue = Encoding.UTF8.GetBytes(plaintext);
        byte[] bytHash = mhash.ComputeHash(bytValue);
        mhash.Clear();
        return Convert.ToBase64String(bytHash);
    }

Answer 4

То, на что вы ссылаетесь, называется "уязвимостью при столкновении". Но сначала немного предыстории.

Если вы храните незашифрованный пароль, это, как вы уже догадались, Сэм, предположительно, дыра в безопасности. Тем не менее, вы можете использовать проверенный алгоритм, который уменьшает эту возможность. Вам определенно не следует пытаться изобретать свои собственные (так как вы, похоже, не являетесь разработчиком алгоритма).

Я обычно использую MD5, который доступен в базах данных, таких как mysql. Таким образом, вы можете также включить проверку в запросы к вашей базе данных.

Теперь, к сожалению, MD5 не является устойчивым к столкновениям. Однако шансы на столкновение довольно невелики. На форумах могут быть и другие предложения, на которые вы можете посмотреть. Я знаю, что SHA-2 - одна из таких возможностей. Я не знаю, как легко использовать в приложениях.

Answer 5

Тот факт, что «MyAwesomePassword1» и «@ @ # ngt0n8 $ !! ~~~ 09 || {2` = & - [kla2%! B q» могут хэшировать одно и то же значение, не уязвимость безопасности.

Answer 6

Вы можете сказать «ОПРЕДЕЛЕННО возможно» в том смысле, что это доказуемо возможно, но с хорошим алгоритмом хеширования это крайне маловероятно. Существует множество статей о выборе алгоритма хеширования, и частота столкновений является огромным фактором в этом процессе выбора.

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

Answer 7

Если вы беспокоитесь о столкновении, используйте SHA-2 с 512 битами. С другой стороны, алгоритм SHA-1 еще не получил продемонстрированного столкновения, поэтому он все еще достаточно безопасен, чтобы не беспокоиться о столкновении.

Answer 8

Да, это возможно, но вряд ли для приличного хэша.

Чтобы дать вам пример: SHA1 равен 160 битам , что означает, что для поиска двух строк с одинаковым хешем вам необходимо хешировать около 2 ^ 80 разных строк. Даже на всех наших лучших суперкомпьютерах никто не когда-либо нашел две строки , которые хэшируют одно и то же значение SHA1 (хотя я предсказываю, что это произойдет в ближайшее время).

Answer 9

Несмотря на то, что вероятность столкновения может быть небольшой («тонкость» зависит от вашего алгоритма хеширования), это не имеет значения, не так ли?

Даже если у вас одинаковый хэш пароля для пользователя x и пользователя y, вы никогда не будете сравнивать пароли двух пользователей, чтобы определить, что они совпадают на основании их хеша! Так что, хотя «технически» хеш коллизий, в данном сценарии он не сталкивается / не вмешивается / имеет значение.

Answer 10

Хеш-функция должна быть разработана таким образом, чтобы маловероятно, чтобы она давала одинаковый хеш-код для 2 разных входов, то есть она устойчива к столкновениям. Более подробная информация доступна на Википедии .