>>>Еще раз - это "обертка" над хеш функцией, которая на основании парольной фразы генерирует ключ шифрования (один или несколько).
> речь щас о хешировании? а то вы про хеш функцию начинаете а
> кончаете "генерирует ключ шифрования" - определитесь.не придирайся к словам. тут по сути берется хеш функция от заданной парольной фразы, которая и используется в качестве ключа шифрования.
>[оверквотинг удален]
> - было высказано мнение "Хеш функции должны быть медленными" - я
> категорически против этого высказывания. Усложнить жизнь брутфорсеру можно всегда, и есть
> конкретные методы в данном случае привёл пример использования PBKDF2 она именно
> для этого и предназначена. В тоже время я предложил для усложнения
> использовать не хеш функцию, а конкретно какой либо алгоритм симметричного, а
> ещё лучше ассиметричного, шифрования. И вспыл такой вопрос, что и алгоритм
> шифрования так же быстро можно пробрутить. )))) Как и на скока
> быстро? Достаточно того, что (не буду точно утверждать) хеш функция быстрее
> вычисляется чем происходит шифрование (дешифрование) каким либо алгоритмом симметричного
> (асимметричного).
Не все так однозначно:
$ openssl genrsa -out key.txt 512 > key.txt
$ time for i in {1..100000}; do echo "qwertyuiop" | openssl rsautl -inkey key.txt -encrypt > /dev/null; done
real 4m35.424s
user 2m21.907s
sys 1m51.257s
$ time for i in {1..100000}; do echo "qwertyuiop" | openssl sha1 -sha512 > /dev/null; done
real 4m27.662s
user 2m9.487s
sys 1m56.034s
Да, разница есть, но она несущественна. И это я еще не брал самый быстрый алгоритм шифрования и самую медленную хеш-функцию.
>>>Спорить о способах хранения пароля в мои планы не входило - я знаю, что ты предлагаешь неправильный вариант, т.к. он основан на наличии секретной информации.
> Покажите мне хеш функцию у которой нет коллизии ? и где достоверность
> того, что введенный пароль точно соответствует тому паролю который лежит в
> базе ? хеш функция гарантии не даст, а вот шифрование даст.
Да, коллизии есть, не спорю. И не спорю с тем, что даже соль тут кардинально ничего не изменит (она не для этого и используется). Т.е. чисто теоретически вполне возможно подобрать парольную фразу, которая с той же солью даст тот же хеш. Вопрос стоит в количестве трудозатрат на поиск такой коллизии. Да, гарантию, что пользователь ввел именно тот пароль никто не даст. Но ИМХО это все-таки надежнее, чем полагаться на неуязвимость других компонентов системы, которые в случае взлома могут привести к утечке всех "секретов" в случае использования шифрования. В случае хеша - что поиск пароля, что поиск коллизии - это все время и ресурсы. В случае шифрования пароля - утечка "секретов" сразу приводит к раскрытию паролей всех пользователей, и тут нет смысла сравнивать скорость хеширования со скоростью шифрования - дешифровать нам нужно каждый пароль по разу, а считать хеш - миллионы раз для каждого пароля.
>>>но тебе это не поможет "восстановить" пароли всех юзеров, только брутфорс каждого пароля - а это ооооочень долго
> Не знание ключа шифрование так же заставит вас их брутить, или вы
> знаете метод как расшифровать.
Я говорю про ситуацию, когда ключ шифрования "утек". Никто не может гарантировать, что этого не произойдет.
