Простое шифрование пароля

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

Ответ 1

Как говорит mk, SHA1 или MD5 являются стандартными, наряду с SHA2.


Обновление: поскольку процессоры с годами становились все быстрее, хэши становились более грубыми. Теперь рекомендуется использовать bcrypt.


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

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

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

Ответ 2

MD5 или SHA1 + соль.

Ответ 3

Если вы используете MD5 или SHA1, используйте соль, чтобы избежать взлома стола радуги.

В С# это легко:

MD5CryptoServiceProvider hasher = new MD5CryptoServiceProvider();
string addSalt = string.Concat( "ummm salty ", password );
byte[] hash = hasher.ComputeHash( Encoding.Unicode.GetBytes( addSalt ) );

Ответ 6

Это была проблема моей пары недель назад. Мы развертывали большой проект MIS в 975 различных географических местоположениях, где наш собственный хранилище учетных данных пользователя будет использоваться в качестве аутентификатора для разных наборов уже реализованных и используемых приложений. Мы уже предоставляли службы аутентификации на основе REST и SOAP, но клиент настаивал на том, чтобы иметь возможность доступа к хранилищу учетных данных пользователей из других приложений только с подключением БД к просмотру только для чтения связанной таблицы или представления. Вздох... (это очень плохое дизайнерское решение является предметом другого вопроса).

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

Мы назвали его "Безопасно безопасными хешированными паролями" или FSHP. Реализовано в Python, Ruby, PHP5 и выпущено в Public Domain. Доступно для потребления, раздвоения, пламени или плевки на GitHub в http://github.com/bdd/fshp

FSHP - это засоленная итеративно хешированная реализация хэширования пароля.

Принцип проектирования аналогичен спецификации PBKDF1 в RFC 2898 (a.k.a: PKCS # 5: Спецификация криптографии на основе паролей, версия 2.0.) FSHP позволяет выбирать длину соли, количество итераций и лежащую в основе криптографической хэш-функции среди SHA-1 и SHA-2 (256, 384, 512). Самоопределение мета префикса в начале каждого выхода делает его переносимым, позволяя потребителю выбрать собственную базу безопасности безопасности паролей.

Безопасность

По умолчанию FSHP1 использует 8-байтовые соли, с 4096 итерациями хеширования SHA-256. - 8-байтовая соль делает атаки радужного стола нецелесообразными, умножая   требуемое пространство с 2 ^ 64. - 4096 итераций заставляют атаки грубой силы быть довольно дорогими. - Нет никаких известных атак против SHA-256, чтобы найти столкновения с   вычислительное усилие менее чем на 2 ^ 128 операций во время   этот выпуск.

Реализации:

  • Python: Протестировано с 2.3.5 (w/hashlib), 2.5.1, 2.6.1
  • Ruby: Протестировано с 1,8.6
  • PHP5: Протестировано с помощью 5.2.6

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

ОСНОВНАЯ ОПЕРАЦИЯ (с Python):

>>> fsh = fshp.crypt('OrpheanBeholderScryDoubt')
>>> print fsh
{FSHP1|8|4096}GVSUFDAjdh0vBosn1GUhzGLHP7BmkbCZVH/3TQqGIjADXpc+6NCg3g==
>>> fshp.validate('OrpheanBeholderScryDoubt', fsh)
True

НАСТРОЙКА КРИПТА:

Позвольте ослабить схему хэширования паролей. - Уменьшите длину соли по умолчанию от 8 до 2. - Уменьшить итерационный раунд от значения по умолчанию 4096 до 10. - Выберите FSHP0 с SHA-1 в качестве основного алгоритма хэширования.

>>> fsh = fshp.crypt('ExecuteOrder66', saltlen=2, rounds=10, variant=0)
>>> print fsh
{FSHP0|2|10}Nge7yRT/vueEGVFPIxcDjiaHQGFQaQ==

Ответ 7

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

Ответ 9

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

Ответ 10

Вам нужно использовать однонаправленный хеш-алгоритм, такой как SHA-1, предложенный выше с солью. Я бы предложил этот сайт для получения дополнительной информации. Он включает некоторые примеры кода/реализации. http://www.obviex.com/samples/hash.aspx

Ответ 11

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

Ответ 12

Для необратимого шифрования я бы определенно пошел с SHA256 или SHA1. Сейчас у MD5 довольно много коллизий, и было затрачено много усилий, чтобы не повредить его, поэтому не стоит использовать его.

Ответ 13

Если вы хотите в будущем решить свое решение, я бы рекомендовал SHA256 или SHA512. Криптографический geekworld получает раздражители о MD5 и, в меньшей степени, SHA1.

Или, если можно, подождите SHA-3

Ответ 14

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

Дополнительная информация: Как правильно обрабатывать хэширование