Что использовать для хеширования паролей?Есть ли причина не использовать jBCrypt?

Question

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

У меня есть это:

• Я не нашел его в репозитории Maven (искал jbcrypt и bcrypt на mvnrepository.org), что является недостатком, поскольку я бы хотел, чтобы мои зависимости управлялись с использованием репозитория Maven, если это возможно.Если jBCrypt — лучшее в своем классе решение для хеширования паролей, мне придется настроить собственный локальный репозиторий и сделать его доступным таким образом.Или я просто пропустил это?Может быть, оно где-то там?
• Это только версия 0.2, но, может быть, она все равно стабильна, и причина низкого номера версии имеет какую-то другую причину?

Answer 1

jBcrypt, вероятно, подойдет в качестве алгоритма шифрования для ваших паролей;Иглобрюхая рыба относительно сильна.Хотя сообщалось о некоторых недостатках реализации в самом Blowfish, я не нашел ничего особенного о jBcrypt.С другой стороны, Blowfish не тестировался так тщательно, как другие алгоритмы, и трескатьсяАтака в стиле «known-plaintxt» часто работает лучше, чем ожидалось, что удивляет крипто-гиков.

Итак, вот что я бы предложил:

• продолжайте использовать jBcrypt, но защитите свои зашифрованные файлы паролей настолько, насколько это возможно — так же, как вы бы использовали /etc/shadow в системе UNIX.
• Вопреки предложению Нихила, я бы перенесите исходники в свой контроль версий по двум причинам:(1) где еще вы могли бы их хранить, поскольку они нужны вам всякий раз, когда вы строите, и (2) потому что всегда есть шанс человек, выполняющий jBcrypt, перейдет к другим вещам, и вы не хотите, чтобы вас оставили висеть незадолго до доставки (что неизбежно произойдет, когда вы об этом узнаете). В такой ситуации я бы поместил исходники в ваш контроль версий, как если бы они были вашим кодом, а затем любые изменения можно вставлять, как если бы вы сами создали новую версию.Не нужно быть более сложным, чем обычно.

Answer 2

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

Но это уже сделано:

...Корабли с набором тестов на юнит для проверки правильной работы библиотеки и совместимости с канонической реализацией C алгоритма BCRYPT.

Я бы начал с просмотра тестов JUnit, чтобы увидеть, соответствуют ли они вашему уровню удовлетворенности...

Answer 3

Я сомневаюсь, что стабильность будет проблемой, поскольку bcrypt сам по себе является зрелым, а его крошечные стандартизированные оболочки не делают ничего особенного.Я доволен другой оболочкой bcrypt Дэмиена Миллера, python-bcrypt, который есть только в версии 0.1.

Я не знаком с Maven, но (осторожно, ересь!) Я сомневаюсь, что вам нужен контроль версий для такого простого компонента, как bcrypt.Цитируя сайт, изменения с версии 0.1 на версию 0.2 касались «корректности, опечаток и настроек API (полная обратная совместимость)», а список TODO пуст.