funcool/buddy-hashers

Reasoning for hashing password before bcrypting?

danielcompton opened this issue · 6 comments

The main reason is the password length, and this technique is used by many well known and security audited frameworks (django framework is a great example). Is not an isolated random decision.

Additionally, the problem that you are commenting about the bad idea of hash before bcrypt it is very dependent of the bcrypt implementation. The bcrypt implementation that I'm using on buddy is not affected by that weird behavior.

I'm open to add a little not about the reason of using the combination of hash+bcrypt.

There were two concerns, the specific PHP one was pretty weird and I agree not an issue here. However the more general point was that combining crypto algorithms can non-obviously make them weaker, so having a note with justification for why this is safe would be a good addition.

Agree, Can you make a proposal of that note?

I came here because I also wanted an explanation about the choice of algorithm. It would be nice if the note included which other frameworks this technique is used by.

As i have said previously, I used the same technique that django uses, and i have used the same approach (more on this: https://docs.djangoproject.com/en/2.0/topics/auth/passwords/#using-bcrypt-with-django). Additionaly, i'm using a bcrypt implementation that uses binary data instead of just plain characters, so it is not affected by the problem described here https://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html

And, in any case, if you are not convinced about this approach, the toolkit is very extensible, so implementing a raw bcrypt is very easy. In fact the PR is welcome for that if someone consider having raw bcrypt useful.

Close for inactivity.