Я запускаю веб-сайт, и я пытаюсь решить, как шифровать пароли пользователей для их хранения в базе данных SQL.
Я понимаю, что использование простого md5 (пароля) очень небезопасно. Я рассматриваю использование sha512 (password.salt), и я изучал лучший способ создания полезной соли. Я читал многочисленные статьи о том, что соль должна быть настолько случайной, насколько это возможно, чтобы добавить энтропию к хешу, и это выглядит как отличная идея. Но:
Разве не очевидно, что странное выглядящее значение рядом с хэшем в базе данных является солью? Если злоумышленник может получить доступ к соли вместе с хеш-значением, как это безопаснее?
У кого-нибудь есть опыт в этой области? Благодаря!
Злоумышленнику «разрешено» знать соль – ваша безопасность должна быть спроектирована таким образом, чтобы даже при сохранении соли в безопасности.
Что делает соль?
Соль помогает в защите от нападений грубой силы с использованием предварительно вычисленных «радужных столов».
Соль делает грубую силу намного дороже (во времени / памяти) для атакующего.
Вычисление такой таблицы является дорогостоящим и обычно выполняется только тогда, когда оно может использоваться для нескольких атак / паролей.
Если вы используете ту же соль для всего пароля, злоумышленник может предварительно вычислить такую таблицу, а затем перевести ваши пароли в открытый текст …
Пока вы создаете новую (лучшую криптографически сильную) случайную соль для каждого пароля, который вы хотите сохранить хэш, нет проблем.
ЕСЛИ вы хотите еще больше укрепить безопасность
Вы можете рассчитать хэш несколько раз (хеш-хэш и т. Д.) – это вам не дорого, но делает более грубую атаку / расчет «радужных столов» … пожалуйста, не изобретайте себя – Есть проверенные стандартные методы для этого, см., например, http://en.wikipedia.org/wiki/PBKDF2 и http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage -Использование-заместитель RSA-PBKDF2-Standard
ЗАМЕТКА:
Использование такого механизма в наши дни является обязательным, поскольку «процессорное время» (используемое для таких атак, как радужные таблицы / грубая сила и т. Д.) Становится все более доступным (см., Например, тот факт, что Amazon's Cloud service входит в первую 50 самых быстрых суперкомпьютеры по всему миру и могут быть использованы кем-либо за сравнительно небольшую сумму)!
учитывая, что злоумышленник каким-то образом получил доступ к вашим хешированным паролям (и пытается изменить хеш на обычный текст), это означает, что он, вероятно, сбросил вашу базу данных, затем получил доступ к вашим случайным солям также
Весь смысл соления – победить «радужные столы»:
http://en.wikipedia.org/wiki/Rainbow_table
Посмотрите, почему достаточно длинная соль побеждает любой радужный стол в разделе «Защита от радужных столов» .
как это безопаснее?
Раньше он был более безопасным, потому что он заставлял злоумышленника попробовать тогда, очень дорогостоящий подход грубой силы вместо мгновенного просмотра в заранее вычисленных таблицах радуги. Если у вас было 64-битное соль, атакующий должен был иметь 2 ^ 64 предварительно вычисленных радужных таблиц вместо одного … Другими словами: он сделал бесполезными столы радуги.
Обратите внимание, однако, что современные графические процессоры могут взломать миллиарды паролей в секунду, в результате чего злоумышленник может хранить огромные таблицы радуги (вместо того, чтобы хранить миллиарды хэшей, просто вычислить их через несколько секунд).
В настоящее время вы хотите хранить свои «пароли», используя что-то вроде PBKDF2 или scrypt.
Сила ваших хешированных, соленых паролей основывается на следующих факторах:
Ваша система столь же сильна, как и самое слабое из вышеперечисленного.
Ниже приведены вопросы с сайта- партнера Security StackExchange . Они обсуждают хеширование, соли, PBKDF2, bcrypt, scrypt и некоторые другие вещи.
Также есть несколько предыдущих обсуждений от StackOverflow:
Является ли BCrypt хорошим алгоритмом хеширования для использования в C #? Где я могу найти его?
Короткий ответ на ваш вопрос, соль – это гарантия, которая заставляет занять много времени, чтобы восстановить пароль в случае компрометации, как хэш. Если атаковать один пароль, соль не изменит ситуацию. Если вы пытаетесь использовать предварительно вычисленный словарь или одновременно тестируете много паролей, наличие различной соли для каждой записи значительно увеличит объем требуемой работы и, как правило, сделает невозможным создание подходящего стола радуги.
Вот хорошая статья о криптографии: http://www.javacodegeeks.com/2012/02/introduction-to-strong-cryptography-p1.html
См. Раздел «Использование алгоритмов хеширования в реальном мире», сценарий 1 для обсуждения соли.
Я настоятельно рекомендую использовать http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html для создания соли