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

MD5 или SHA1 + соль.

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

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

В C# это просто:

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

Если вы используете SQL Server, есть функция HashBytes:

http://msdn.microsoft.com/en-us/library/ms174415.aspx

Статья Джеффа Вероятно, вы неправильно храните пароли - отличное чтение по этой теме.

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

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

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

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

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

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

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

Легко: BCrypt.

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

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

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

Мы назвали это Fairly Secure Hashed Passwords или сокращенно ФШП. Реализовал его на Python, Ruby, PHP5 и передал в общественное достояние. Доступно для употребления, разветвления, флейма или плевания на 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 (с 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==

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

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

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

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

Подробнее: Как правильно хешировать пароли