aarondl
commented
3 years ago As long as it's all done via optional interfaces as you're suggesting I think this is an easily acceptable proposal as it wouldn't be breaking and provides reasonably interesting functionality to users. Increasing bcrypt cost over time as a supported use case is interesting and I also wonder if there's currently any sources that would advocate increasing it authboss itself for security reasons.
We're using authboss at Mattel, but we need to be able to support multiple types of password hashing. There's two reasons for this functionality - first is that we want to upgrade our hashing mechanism to argon2. But we have existing hashes in the field that are bcrypt, so we'll need to support both. And, we're migrating users from other systems that use other hashing mechanisms, and so we want to be able to support those as well.
If instead of explicitly calling bcrypt in login etc, authboss first checked if the user supports a VerifyPassword() method, then it could call that instead, and implementors could choose their own method of hashing.
This would also allow us to incrementally strengthen our hash strength (bcrypt's "cost") as time goes on, and re-save the hash with the new cost as needed.
Right now we're working on doing this by just hacking copied portions of authboss, but we'd rather contribute upstream.