Хеширование, добавление большего количества соли

Question

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

мое мышление, так что если г-н Хакер раздобыл БД и хочет получить пароль для лица х, он думает про себя, а большинство людей предполагает добавление или предваряя соль, так что позволяет сделать .. Он создает радужный стол со всеми комбинациями паролей + соль и пробует свою удачу. Если это не работает, он делает то же самое, но salt + password.

Чтобы сделать сложнее сделать атаку, почему разработчики не идут дальше и не солируют + пароль + соль, или «наоборот (соль) + пароль + соль», или вы можете быть фантастическими и начните резать пароль/соль, начните наносить кусочки соли здесь и там и т. д.

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

Еще примечание, люди предлагают делать минимум 1000 итераций, когда ключ растяжения, опять же, почему не 1147, 1652 и т.д. :)

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

Answer 1

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

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

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

Если вы распространяете свою программу среди пользователей, они могут точно определить, как она хэширует вещи, разбирая или отлаживая ее. Если это серверная программа, они могут взломать другую уязвимость, или они могут купить/украсть/приобрести ваше программное обеспечение или что-то еще. Я даже зашел так далеко, чтобы сказать, что ВСЕ ХОРОШЕЕ КРИПТОГРАФИЧЕСКОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ОТКРЫТОЕ ИСТОЧНИК: хотя весь мир знает, как это работает, его все еще не ломается.

То, на что вы пытаетесь положиться, - это безопасность безвестности. Многие люди и компании использовали это как способ обеспечения безопасности своих продуктов. Последний большой инцидент, который я помню, когда был украден исходный код программного обеспечения Symantec PCAnywhere. Вы могли бы вспомнить, как это получилось. Мораль этой истории небезопасна, если никто не знает, как она работает, ее безопасность, если КАЖДЫЙ знает, как она работает (и она криптографически звучит).

Answer 2

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

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

1. Генерация достаточно сильную случайную соли (16 - 32 байт)
2. Установите хэш стоимость (15 - 20) (чем больше затрат, тем медленнее и сильнее хэш)
3. Подсчитать количество хэш раундов вы будете выполнять (2^стоимость)

Выполните следующие действия:

hash = "" 
for(numberOfHashRounds) 
{ 
hash = SHA256(hash + salt + password) 
} 

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

Это безопасно, потому что взломщик должен будет генерировать радужный стол для каждой соли и выполнять одинаковое количество раундов. Это займет десятилетия даже при использовании массива GPU, используемого для взлома.

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