You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: