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

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

Большинство нападений в эти дни считают слабости в алгоритмах, используемых таким образом, что делает его быстрее находить столкновения для эксплуатации. МД5 было показано, что он слабее, чем думал ранее. Это Статья из реестра показывает, как была использована слабость для создания сертификатов SSL.

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

Это PDF PDF показывает бумагу, обсуждающую CHA-1 Collisons и как было облегчено. (Maths Heavy)

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

http://project-rainebrack.com/

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

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

Брюс Шейнер имеет некоторые интересные блоги на устойчивости различных методов безопасности - Sha1 Brada

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

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

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

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

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

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

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

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

  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

Реализация булевых операций правильно не тривиальна; К счастью, есть библиотеки, которые уже реализуют эту функциональность.

Какой язык вы используете? Если это C ++, взгляните на CGAL , библиотеку алгоритмов вычислительной геометрии.

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

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

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

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

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

Если вы хотите использовать хеширование в .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() и sha1() и подобные им по сути своей являются шифровальными функциями, выполняющими хэширование. Поскольку хэширование в теории должно обеспечивать уникальный вывод для заданного входа (обычно большего размера), это, по сути, означает, что каждый хэш должен быть сопоставлен с одним входом - это означает, что на руках у вас есть идеальная функция сжатия, которая может уменьшить данные размером N обычно больше M до данных такого размера M, и процесс является обратимым. Однако на практике происходит столкновение хэшей. Это означает, что один хэш может потенциально сопоставляться более чем с одним исходным входом. Это означает, что один хэш пароля может привести к тому, что вы получите пользователя с другим паролем, что представляет собой реальную проблему с точки зрения безопасности.

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

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

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

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

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

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

То, что вы называете называться «уязвимостью столкновения». Но сначала маленький фон.

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

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

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

Можно сказать "ОЧИСТИТЕЛЬНО возможно" в том смысле, что это возможно, но при хорошем алгоритме хеширования это крайне маловероятно. О выборе алгоритма хэширования есть много статей, и скорость столкновений является огромным фактором в этом процессе выбора.

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

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

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

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