Что использовать для хеширования пароля? Есть ли причина не использовать jBCrypt?
Я планирую использовать jBCrypt для хеширования паролей в новом веб-приложении, так как оно должно быть лучшим из того, что я прочитал. Поскольку я не использовал это прежде, чем я исследую, есть ли причина не использовать это.
У меня есть это:
- Я не нашел его в репозитории Maven (искал jbcrypt и bcrypt на mvnrepository.org), что является недостатком, поскольку я хотел бы, чтобы мои зависимости управлялись с помощью репозитория Maven, если это возможно. Если jBCrypt является лучшим в своем роде решением для хэширования паролей, мне придется настроить свой собственный локальный репозиторий и сделать его доступным для этого. Или я просто пропустил это? Может это где-то там?
- Это только в версии 0.2, но, возможно, в любом случае это стабильно, и причина низкого номера версии имеет другую причину?
3 ответа
jBcrypt, вероятно, подходит как криптографический алгоритм для ваших паролей; Выдувная рыба относительно сильна. Хотя в самой Blowfish были некоторые недостатки реализации, я не нашел ничего особенного в jBcrypt. С другой стороны, Blowfish не был протестирован почти так же интенсивно, как другие алгоритмы, и атака с открытым исходным текстом в стиле крэк часто работает лучше, чем ожидалось, что удивляет крипто-фанатов.
Итак, вот что я бы предложил:
- продолжайте и используйте jBcrypt, но защищайте ваши зашифрованные файлы паролей настолько, насколько это разумно, как если бы вы использовали /etc/shadow в системе UNIX.
- Вопреки предложению Nikhil, я бы включил источники в ваш контроль версий по двум причинам: (1) где еще вы будете их хранить, так как они нужны вам при сборке, и (2) потому что всегда есть шанс, что человек, делающий jBcrypt перейдем к другим вещам, и вы не захотите, чтобы вас оставляли висящими прямо перед доставкой (что неизбежно, когда вы узнаете.) В такой ситуации я бы поместил источники в ваш контроль версий как если бы они были в вашем коде, и тогда любые изменения могут быть вставлены, как если бы вы сами создали новую версию. Не нужно быть более сложным, чем обычно.
Что касается вашего беспокойства о том, что оно еще не достигло зрелости, я собирался предложить вам создать собственные тесты JUnit, сравнивающие результаты jBcrypt и более проверенного Bcrypt, чтобы убедиться, что вы получите те же результаты, а затем добавить их в jBcrypt проект.
Но это уже сделано:
... поставляется с набором модульных тестов JUnit для проверки правильности работы библиотеки и совместимости с канонической реализацией C алгоритма bcrypt.
Я бы начал с тестов JUnit, чтобы увидеть, соответствуют ли они вашему уровню удовлетворенности...
Я сомневаюсь, что стабильность будет проблемой, так как сам bcrypt зрел, и его крошечные стандартизированные обертки не делают ничего экстраординарного. Я доволен другой оболочкой bcrypt Дэмиена Миллера, python-bcrypt, которая есть только в версии 0.1.
Я не знаком с Maven, но (ересь!) Я сомневаюсь, что вам нужен контроль версий для такого простого компонента, как bcrypt. Чтобы процитировать сайт, изменения с v0.1 до v0.2 были "корректность, опечатка и настройки API (полностью обратно совместимые)", и список TODO пуст.