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

Question

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

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

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

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

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

Answer 1

Хорошая реализация этого.

  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

Answer 2

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

Большинство атак в наши дни учитывают недостатки используемых алгоритмов, что позволяет быстрее находить коллизии для использования. Показано, что MD5 слабее, чем считалось ранее. Эта статья из Реестра показывает, как слабость использовалась для создания SSL-сертификатов.

Было показано, что даже более стойкие алгоритмы имеют недостатки, которые облегчают обнаружение этих столкновений.

В этом PDF показана статья, в которой обсуждаются столкновения SHA-1 и как это было сделано проще. (Математика тяжелая)

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

http://project -rainbowcrack.com /

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

Answer 3

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

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

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

Изобретите пару ключей шифрования / дешифрования и зашифруйте пароли своих пользователей перед их хранением в общедоступных местах.

Answer 4

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

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

Если вы сделаете это, очень трудно найти пароль, который даст данный хэш, кроме как пытаться вводить пароль за паролем, пока вы не нажмете правильный. Хеширование обеспечивает защиту от инсайдеров и злоумышленников следующим образом: недостаточно иметь доступ к таблице паролей, чтобы войти в систему под чужим именем.

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

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

Answer 5

Если вы используете SHA-512 с приличным семенем, маловероятно (но не невозможно), что это произойдет.

У Брюса Шейнера есть несколько интересных блогов о надежности различных методов безопасности - sha1 нарушено

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

Чтобы обойти это, вы могли бы создать начальное число, включающее в себя что-то конкретное для пользователя, например поле ключа userid из таблицы пользователя.

Answer 6

Возьмем, к примеру, строку хеша md5 - она ​​имеет 128 битов, что означает, что может быть сгенерировано 2 ^ 128 разных хешей. Даже принимая во внимание парадокс дня рождения , очень маловероятно , что можно найти строку, которая не является действительным паролем для генерирования значения хеша (конечно, md5 был найден небезопасно, но это еще одна проблема, md5 является лишь примером).

Допустим, у вас есть пароль, программа его хеширует и помещает хеш в базу данных. Когда вы пытаетесь войти в систему, то, что вы вводите, хэшируется и проверяется на соответствие этому хешу - если это предположение, есть вероятность 1 в 2 ^ 128, что вы правы. Это бесконечно мало, и фактически взломать пароль таким образом (грубая сила) «невозможно». Увеличьте количество битов, и это на самом деле станет невозможным, если алгоритм хеширования не будет хотя бы частично переработан.

Answer 7

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