Updating the hash to make use of bcrypt

[JN-Jones]

The Auth class should try to update the hash to use bcrypt (mybb 2 default) instead of the currently used hasher like the loginconvert plugin does.

@euantorano suggested to fire an event in the auth package and add a listener in the core (3rd parties can simply ignore the event) where the hash is updated.
Another solution would be to update the trait/interface and add a new method (eg updateHash) which can update the hash/salt/hasher (our own interface requires them anyways). 3rd parties can overwrite the updateHash method if they want to keep the old hashing method.

@mybb/developers What do you prefer? Or do you have another suggestion?

[JN-Jones]

Anyone?

[wpillar]

What are we trying to achieve here? Move 1.x hashes over to bcrypt hashes?

[JN-Jones]

For example. But also other types of passwords. We support sometimes very old passwords which are simplied hashed with md5 without a salt (or the username as salt). The old loginconvert plugin only used the old hash once and created "our" hash then. IMHO we should still do this as some hash implementations are very weak. However 3rd parties should be able to keep the old hash.

[wpillar]

What do you mean by a 3rd party in this context?

IMHO we should do the following at login:

1. Check if password is a valid 2.0 hash, if so carry on as normal.
2. If It fails authentication as a 2.0 hash, try it as a 1.x hash.
3. If authentication succeeds as a 1.x hash, take the plaintext from the request hash it using the 2.0 hash and save to database.

That will catch most old 1.x hashes and ensure the greatest amount of security without forcing a password reset on everyone. Unless we're ok with forcing a password reset on everyone, which wouldn't be so bad arguably, if so, great let's do that :)

[JN-Jones]

3rd party = everyone except us. This is an own package and is supposed to work without the core (eg when I decide to rewrite my homepage I can use this package for authentication).

It's already possible to login with 1.x passwords (and SMF, phpBB, XenForo and a few more), the only question is whether and where to update those to make use of bcrypt.

[wpillar]

I think we have a responsibility to re-hash any known weakly hashed passwords to the best practice / standard.

I say we do it at login and forgotten password. Ideal world, we force any users with a known weakly hashed password to reset their password.

[JN-Jones]

Resetting your password uses bcrypt anyways as it's a new password. Same for changing your password. As said: this package is completely independent from the core so we can't reset passwords as other softwares may use different methods. Also this would be very annoying. I'd need to reset/change my passwords in a ton of forums. And some softwares may want to use another hashing algorithm and don't want to have it changed automatically

[wpillar]

Personally I think that as a vendor of an authentication package, we should always enforce the best practice. We shouldn't allow people to change which hashing algorithm it is.

As for people who have existing passwords and want to use this authentication package, that's kind of not something we should have to worry about either.

If I have some software with a bunch of md5 hashes in the database and I want to use a new authentication package and I don't want to force everyone to reset their password, then I should:

1. Run a script that re-hashes all md5 hashes in the db using the new hashing algo. So essentially the algo is bcrypt(md5('password')). Or do this on the fly as they log in.
2. Integrate the authentication package so I always md5 the plain password before checking it. $newAuth->check($email, md5($password)). I could even extend the new auth package to wrap it up like this too.

We should probably write some documentation and recommend a best practice for doing this. What do you think?

[JN-Jones]

This package already extends laravels authentication system so there's no need to do anything about checking passwords. You've the hasher column (which can be renamed or hardcoded by 3rd parties) which indicates which hashing method should be used. And simply think about a scenario where I've a (eg) XenForo forum running and a laravel application which uses the same user table for authentication: now I want to be able to use this package (which is why this is a seperate package and not in the mybb2 repo) to authenticate my users but I don't want to update the users passwords (otherwise I'd break XenForo). However mybb 2 should update the password as we want to use bcrypt there. And now the question is how we want to do so: either add a "hook" when a password was valid (we'd listen to that hook in the mybb2 repo) or automatically call a function in the trait which then can be overwritten.

[euantorano]

Coming back to think on this again as part of my refactoring of the Auth package, these are some abstract thoughts:

• Out of the box, we don't need any edited Auth package or anything if the install is a fresh install
• The upgrade script can install this Auth package if it needs to (as can the merge tool). It can also modify config to require the package's service provider which can register its own Auth class.
• The various password hashers can be registered with aliases such as password_hasher.mybb1, which can be resolved by the IOC Container from the database column hasher.
• We shouldn't re-implement all of the Auth package, just add a new Auth provider which will be registered and used.

I'm going to start work on the last point from above tonight and hopefully get it done so that we're in a semi-working state.