Улучшите хеширование паролей случайной солью - PullRequest
21 голосов
/ 24 февраля 2012

Я запускаю веб-сайт и пытаюсь решить, как зашифровать пароли пользователей для хранения их в базе данных SQL.

Я понимаю, что использование простого md5 (пароля) очень небезопасно. Я подумываю об использовании sha512 (password.salt) и изучаю лучший способ получения полезной соли. Я прочитал множество статей о том, что соль должна быть как можно более случайной, чтобы добавить энтропию к хешу, и это выглядит как отличная идея. Но:

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

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

Кто-нибудь имеет опыт в этой области? Спасибо!

Ответы [ 5 ]

40 голосов
/ 24 февраля 2012

Злоумышленнику «разрешено» знать соль - ваша безопасность должна быть разработана таким образом, чтобы даже при знании соли она все еще была в безопасности.

Что делает соль?

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

Если вы хотите еще больше укрепить безопасность
Вы можете вычислить хэш несколько раз (хэш и т. Д.) - это не будет стоить вам дорого, но делает атаку грубой силой / вычисление «радужных таблиц» еще дороже ... пожалуйста, не изобретайте себя - существуют проверенные стандартные методы для этого, см., например, http://en.wikipedia.org/wiki/PBKDF2 и http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard

ПРИМЕЧАНИЕ:

Использование такого механизма в наши дни mandatrory , поскольку «время процессора» (используется для атак, таких как радужные таблицы / грубая сила и т. Д.) Становится все более доступным (см., Например, тот факт, что Amazon Облачный сервис входит в число 50 самых быстрых суперкомпьютеров в мире и может использоваться кем угодно за сравнительно небольшую сумму)!

15 голосов
/ 24 февраля 2012

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

Весь смысл засолки - победить «радужные столы»:

http://en.wikipedia.org/wiki/Rainbow_table

Узнайте, почему достаточно длинная соль побеждает любой радужный стол в разделе "Защита от радужных столов" .

как это безопаснее?

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

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

В настоящее время вы хотите хранить свои «пароли», используя что-то вроде PBKDF2 или scrypt.

0 голосов
/ 28 февраля 2012

Ниже приведены вопросы с родственного сайта Security StackExchange . Они обсуждают хеширование, соли, PBKDF2, bcrypt, scrypt и некоторые другие вещи.

Здесь также есть некоторые предыдущие обсуждения StackOverflow:

Является ли BCrypt хорошим алгоритмом хеширования для использования в C #? Где я могу найти это?

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

0 голосов
/ 24 февраля 2012

Надежность ваших хешированных паролей зависит от всех следующих факторов:

  • Сила алгоритма хеширования
  • Случайность соли
  • Случайность пароля

Ваша система так же сильна, как самая слабая из перечисленных.

0 голосов
/ 24 февраля 2012

Вот хорошая статья о криптографии: http://www.javacodegeeks.com/2012/02/introduction-to-strong-cryptography-p1.html

См. Раздел Использование алгоритмов хеширования в реальном мире, сценарий 1 , для обсуждения соли.

IНастоятельно рекомендуем использовать http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html для получения соли

...