Я прочитал ряд вопросов, которые предлагают хеширование паролей и их хранение в базе данных.
Когда кто-то войдет в систему, вы получите пароль, предоставленный с тем, что вы сохранили.
Я не понимаю, как это может работать? Две строки могут иметь значение хэша с одинаковым значением. Невозможно, но возможно. ОПРЕДЕЛЕННО.
Кто-нибудь может мне помочь?
РЕДАКТИРОВАТЬ: Может ли кто-нибудь дать статистику вероятности столкновения?
Нельзя хранить пароль незашифрованным, потому что администраторы базы данных не должны иметь доступ к паролям клиентов.
Хеширование паролей позволяет администраторам баз данных не видеть пароль.
Очень небольшая вероятность столкновения - это не проблема, так как это не увеличивает вероятность того, что кто-то попытается перевести пароль пользователя, чтобы получить совпадение, прежде чем блокировать учетные записи.
PS также рекомендуется использовать соли пароли перед хешированием, чтобы еще труднее было переработать грубую силу, если хакер каким-то образом получил доступ к таблице паролей. Это затрудняет использование радужных столов и т.д.
Две строки могут использовать хэш с тем же значением - Невозможно, но ОПРЕДЕЛЕННО возможно
Да, но если хэш достаточно большой и хорошего качества, маловероятно, чтобы не беспокоиться. В разговорных условиях: каждый пользователь приложения, попавшего под удар молнии одновременно, не похож, но определенно возможен. Вы беспокоитесь об этом?
Даже если две строки имеют хэш с тем же значением (и они определенно делают это, потому что пространство возможных значений намного больше, чем пространство хэшей), все же не так легко найти такие пары строк (при условии, что вы используйте сильную хэш-функцию).
Поэтому, если злоумышленник захочет войти в систему как кто-то другой, не зная его пароля, ему придется найти пароль с таким же хэшем, который должен быть таким же сложным, как поиск пароля (неинвертируемость хеш-функции является основное свойство).
Если вы хотите использовать хэширование в .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);
}
То, что вы называете, называется "Уязвимость при столкновении". Но сначала немного фона.
Если вы храните незашифрованный пароль, это дыра в безопасности, как вы могли догадаться, и предлагает Сэм. Тем не менее, вы можете использовать проверенный алгоритм, который уменьшает эту возможность. Вы не должны пытаться изобрести свои собственные (поскольку вы не являетесь разработчиком алгоритмов).
Я обычно использую MD5, который доступен в таких базах данных, как mysql. Таким образом, вы можете встроить проверку в свои запросы к базе данных.
Теперь MD5, к сожалению, не устойчив к конфликтам. Однако шансы на столкновение довольно тонкие. На досках объявлений могут быть другие предложения, на которые вы можете посмотреть. Я знаю, что SHA-2 - одна из таких возможностей. Я не знаю, как легко это использовать в приложениях.
Тот факт, что "MyAwesomePassword1" и "@@# ngt0n8 $!! ~~~ 09 || {2` = & - [kla2%! Bq" может хеш с тем же значением, не является уязвимостью безопасности.
Вы можете сказать "ОПРЕДЕЛЕННО возможно" в том смысле, что это возможно, но с хорошим алгоритмом хэширования это крайне маловероятно. Существует множество статей о выборе алгоритма хеширования, и скорость столкновения является огромным фактором в этом процессе выбора.
Причина, по которой люди выступают за хеширование и шифрование, заключается в том, что хеширование - это односторонняя операция. Сама возможность столкновения - это то, что делает хэширование хорошим выбором с точки зрения безопасности пользователя; потому что два значения могут выдавать один и тот же хеш, хеширование не может быть отменено. Это делает невозможным (или почти невозможным) для кого-то взломать вашу базу данных и получить доступ к учетным данным для других сайтов (так как пользователи часто будут использовать один и тот же пароль в вашей системе, как это делают [многие]).
Хеш-функция должна быть разработана так, что очень маловероятно, чтобы такой же хэш имел два разных входа, т.е. он устойчив к столкновению. Более подробную информацию можно найти на wikipedia.
Хорошая реализация этого.
private static string CreateSalt(int size)
{
//Generate a cryptographic random number.
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] buff = new byte[size];
rng.GetBytes(buff);
// Return a Base64 string representation of the random number.
return Convert.ToBase64String(buff);
}
private static string CreatePasswordHash(string pwd, string salt)
{
string saltAndPwd = String.Concat(pwd, salt);
string hashedPwd =
FormsAuthentication.HashPasswordForStoringInConfigFile(
saltAndPwd, "sha1");
return hashedPwd;
}
Источник: http://davidhayden.com/blog/dave/archive/2004/02/16/157.aspx
Несмотря на то, что вероятность столкновения может быть тонкой ( "тонкость" в зависимости от вашего алгоритма хеширования), это не имеет значения, не так ли?
Даже если у вас есть тот же хэш пароля для пользователя x и пользователя y, вы никогда не будете сравнивать пароли двух пользователей, чтобы определить, что они одинаковы на основе их хэша! Таким образом, хотя "технически" хеш столкновений, в этом сценарии он не сталкивается/мешает/имеет значение.
Да, это возможно, но маловероятно для приличного хэша.
Чтобы дать вам пример: SHA1 - это 160 бит, что означает найти две строки с одинаковым хэшем, вам нужно будет хэшировать около 2 ^ 80 разных строк. Даже со всеми нашими лучшими суперкомпьютерами никто никогда не обнаружил две строки, что хеш с тем же значением SHA1 (хотя я предсказываю, что это произойдет в ближайшее время).
Если вас беспокоит столкновение, используйте SHA-2 с 512 бит. Опять же, алгоритм SHA-1 еще не получил продемонстрированное столкновение, поэтому он все равно достаточно безопасен, чтобы не беспокоиться о столкновении.
При правильном алгоритме хеширования вероятность столкновения крайне мала. Пока вы можете последовательно вычислять хеш, не имеет значения, имеет ли две строки один и тот же хеш (если это не происходит очень часто). Вы просто сравниваете хэш пароля, введенного пользователем в хэш, который вы сохранили в базе данных.
Возьмем, к примеру, хэш-строку md5 - она имеет 128 бит, это означает, что могут быть сгенерированы 2 ^ 128 различных хэшей. Даже принимая во внимание Day Paradox, маловероятно, что строка, которая не является фактическим паролем, может быть найдена для генерации хэш-значения (конечно, md5 найден небезопасным, но это еще одна проблема, md5 - просто пример).
Скажем, у вас есть пароль, программа хеширует его и помещает хэш в базу данных. Когда вы пытаетесь войти в систему, то, что вы печатаете, хэшируется и проверяется на этот хеш - если это предположение, есть вероятность того, что вы в порядке. Это бесконечно мало, и на самом деле взломать пароль таким образом (грубая сила) является "неосуществимым". Увеличьте количество бит, и это фактически становится невозможным, если алгоритм хэширования не может быть, по меньшей мере, частично реконструирован.
Если вы используете SHA-512 с достойным семенем, это довольно маловероятно (но не невозможно), что это произойдет.
У Брюса Шейнера есть интересные блоги о надежности различных методов безопасности - sha1 broken
Еще одно соображение состоит в том, чтобы убедиться, что у двух пользователей с одним и тем же паролем у них не получается тот же хэшированный результат в вашей базе данных.
Чтобы обойти это, вы могли бы построить семя, которое включает в себя что-то конкретное для пользователя, такое как поле ключа userid из таблицы пользователя.
Почему имеет значение, что несколько строк имеют хеш с одинаковым значением пароля? Каждый раз, когда пользователь вводит свой пароль, он будет хеш с тем же значением, и это будет аутентифицировать пользователя. Ввод почти любого другого пароля почти наверняка не будет соответствовать хешируемому значению. Если вы используете хорошую хеш-функцию, которая дает 64-битное значение, вероятность того, что другой пароль будет соответствовать пользователю, - это квинтиллы к одному.
То, что вы защищаете, - это инсайдеры, копирующие пароли пользователей и раскрывающие фактические пароли, если безопасность нарушена, а таблица паролей скомпрометирована. Стандартный метод заключается в добавлении некоторых дополнительных битов в пароль (соль, которая должна быть разной для каждой учетной записи) и использовать сильную функцию хэширования.
Если вы это сделаете, очень сложно найти пароль, который даст заданный хеш, за исключением попыток пароля после пароля, пока вы не нажмете правый. Хеширование обеспечивает защиту от инсайдеров и злоумышленников таким образом: доступ к таблице паролей недостаточен для входа в систему как кто-либо другой.
Возможно, что у двух пользователей будет один и тот же пароль или (хотя это крайне маловероятно) пароли, для которых хэш имеет одинаковое значение. С солью они не будут выглядеть одинаково в таблице паролей, и поэтому ни один злоумышленник или инсайдер не узнает, что их пароль такой же, как и у кого-то другого, если посмотреть на таблицу.
Другим преимуществом является то, что многие люди повторно используют пароли, особенно для учетных записей, которые не нуждаются в безопасности. (Все мои учетные записи с финансовой информацией имеют разные и хорошие пароли, но я использую один и тот же не очень сильный пароль на разных форумах.) С солью и хэшем невозможно определить, совпадает ли мой пароль на сайте A на сайте B, даже с обеими таблицами паролей.
Хеширование и шифрование - это несколько разные понятия, хотя md5() и sha1() и аналогичные - это, по сути, функции шифрования, выполняющие хеширование. Поскольку хеширование в теории должно обеспечивать уникальный выход для заданного ввода (обычно большего размера), по сути это означает, что каждый хеш должен отображаться на один вход - это означает, что у вас есть на руках прекрасная функция сжатия, которая может уменьшить данные размера N обычно чем M, к данным такого размера M, и процесс обратим. Однако на практике происходит хеш-столкновение. Это означает, что один хэш может потенциально отображать более одного исходного ввода. Это означает, что один хэш пароля может вывести пользователя с другим паролем в целом, что является реальной проблемой безопасности.
Однако шифрование гарантирует обратимость (с правильным ключом дешифрования, конечно), где зашифрованные данные имеют взаимно однозначное отношение с исходными данными. Если длина вашего пароля равна N, ваш зашифрованный пароль также является размером N. Пароли так же безопасны и не сталкиваются.
Как говорится, если что-то слишком хорошо, чтобы быть правдой, вероятно, это - если хеширование может быть обратимым, чтобы всегда производить оригинальные данные, тогда нам не нужны алгоритмы сжатия данных - мы могли бы брать данные произвольного размера, хешировать для получения некоторых 128-битных данных и ожидать, что при необходимости они вернут исходные данные. Однако это не так. Чем дольше ваши исходные данные, тем более ненадежным хеш, независимо от его длины.
Создайте пару ключей шифрования/дешифрования и зашифруйте пароли своих пользователей, прежде чем хранить их в общедоступных местах.
Столкновения действительно происходят, но они должны быть достаточно редкими, что вряд ли когда-либо произойдет в течение определенного периода времени.
Большинство атак в наши дни считают недостатки в используемых алгоритмах, что позволяет быстрее находить столкновения для использования. Было показано, что MD5 слабее, чем считалось ранее. Эта статья из реестра показывает, как слабость использовалась для создания сертификатов SSL.
Было показано, что еще более устойчивые алгоритмы имеют недостатки, которые облегчают поиск этих столкновений.
Этот PDF показывает документ, в котором обсуждаются столкновения SHA-1 и способы его облегчения. (Maths heavy)
Для практических целей для тех, кто пытается восстановить пароли из хешей, используются инструменты, например радужные таблицы
http://project-rainbowcrack.com/
Это учитывает, что люди будут выбирать легко доступные пароли, поэтому это возможно с помощью словарной атаки (список часто используемых паролей плюс множество других терминов), чтобы вычислить хэши и сравнить их. Вот почему рекомендуется использовать salt