Что использовать для хеширования пароля? Есть ли причина не использовать jBCrypt? - PullRequest
17 голосов
/ 08 марта 2009

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

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

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

Ответы [ 3 ]

5 голосов
/ 08 марта 2009

jBcrypt, вероятно, подходит как криптоалгоритм для ваших паролей; Выдувная рыба относительно сильна. Хотя в самой Blowfish были некоторые недостатки реализации, я не нашел ничего особенного в jBcrypt. С другой стороны, Blowfish не был протестирован почти так же сильно, как другие алгоритмы, и атака известного открытого текста crack в стиле часто работает лучше, чем ожидалось, удивительные крипто-фанаты.

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

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

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

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

... поставляется с комплектом блока JUnit тесты для проверки правильности работы библиотека и совместимость с Каноническая С реализация алгоритм bcrypt.

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

0 голосов
/ 08 марта 2009

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

Я незнаком с Maven, но (ересь!) Я сомневаюсь, что вам нужен контроль версий для такого простого компонента, как bcrypt. Чтобы процитировать сайт, изменения с v0.1 до v0.2 были «корректность, опечатка и API-твики (полностью обратно совместимые)», и список TODO пуст.

...