Passwords no longer work after update from 2.2

DaveV

I've upgraded an old 2.2 installation to 2.5.6 and all the user passowrds no longer work 🙁.

After a bit of research and looking at the database I see that the passwords are all hashed with the Vanilla method, which in 2.2 uses $P$ (phpass). However in 2.5 the Vanilla method has changed and uses $2y$ (crypt), and it seems it can't automatically rehash the passwords. I've tried instead upgrading to 2.3 first and this works - the passwords are re-hashed to $2a$ on login. However, I really need to update to at least 2.5, so can't upgrade to 2.3 first and wait for all the users (over 2000) to login before then upgrading to 2.5...

Therefore, I think my only option is to change the hash method to 'reset' and force all the users to reset their passwords on their next login.

Has anyone else experienced this, or know of a work-around?

DaveV

Ah sorry, I think I posted too soon, I think this is a duplicate of https://open.vanillaforums.com/discussion/36237/upgrade-2-1-5-to-2-5-resolved.

I didn't remove the /applications/vanilla/controllers/class.settingscontroller.php file. This isn't mentioned as an upgrade step in the 2.5 readme, but is mentioned here: https://open.vanillaforums.com/discussion/35687/vanilla-2-5-is-now-available

DaveV

So even when I do remove /applications/vanilla/controllers/class.settingscontroller.php first before doing the update I still have the password issue. Is there any other way they can be re-hashed without having to ask users to reset them?

R_J

Since the original password is saved nowhere, it cannot be automatically rehashed. In theory it might be possible to write a plugin which would do the trick by intercepting when the user re-enters his password by first comparing the password with the old method and the old hash and then writing the new hash based on the new method to the database and setting a flag that this user is using the new method (maybe even that is not possible, I have not enough knowledge of the password methods Vanilla used then and now).

But I'm pretty sure your users will not be upset. Tell them "great new features, all is shiny and blinks, password are more secure than ever, please rest your old password". If my forum admin would tell me that, it would be okay for me to reset my password.

The effort for writing such a plugin is simply to high, I guess.

x00

edit wrong info

x00

it seem to be a problem with portable_hashes not being set at the appropriate time.

        if ($this->portable_hashes) {
            $phpass->setHashMethod(PhpassPassword::HASH_PHPASS);
        } else {
            $phpass->setHashMethod(PhpassPassword::HASH_BLOWFISH);
        }

x00

Instead you need to mark your portable hashes with HashType Phpass rather than Vanilla. As this uses PhpassPassword::HASH_PHPASS by default. Vanilla merely extends this.

You can do a query to achieve this.

x00

e.g.

UPDATE GDN_User SET HashMethod = 'Phpass' WHERE Password LIKE '$P$%'

x00

This will change when they sign in.

However the blowfish encryption, is mainly protecting the salt. Which is only relevant is you have been jack potted in the first place, and still would require a dictionary/rainbow attack after this.

Other attacks like timing attacks are already taken care of.

So theses are decent hashes.

DaveV

@x00 thanks for your help with this, but unfortunately changing all the old passwords' method to Phpass doesn't work - it looks like the old Vanilla method in v2.2.3.4 used a variation of Phpass which v2.5.6 doesn't account for..

x00

I don't know there is is probably soemthign else goign on.

It is true that the current release has re-factored some code. There is a lot more use of mixins, etc.

However it would eb a massive oversight if thsi was the case. It is possible for sure, however I have not heard of other people in you position having this issue. Granted, there are only a handful of cases and I have no been around much.

wjcroft

Hi, @DaveV, I'm facing a similar situation. Sent you a PM. Did you ever find a workaround? For example setting some value in GDN_User such that the user is immediately prompted to enter their email for a password reset? Or tweaking something in the login PHP to recognize the old hash and do similar? Otherwise they would try the old password over and over again, getting frustrated and annoyed.

William Croft, OpenBCI

wjcroft

Ah, after following @x00 's advice (using grep), I located the code in

./package/applications/dashboard/controllers/class.usercontroller.php

So with my mySqlAdmin panel, I would search GDN_User for field Password is LIKE '$P$%', that finds the old style passwords. Then on those records, set field HashMethod to 'Reset'. That will display a helpful message the next time the user logs in, and prompt for their email.

Tested this by manually setting 'Reset' in a test user, and that seems to work. Thanks again to @DaveV for starting this thread.

William Croft, OpenBCI

wjcroft

This is off the topic of this thread, but I notice whenever I am logged into open.vanillaforums.com (as wjcroft), my CPU usage on that Chrome tab shoots way up. As shown with the Chrome Task Manager window. Typically consumes about 100% of one CPU core. Insane. Logging out of this website will stop the CPU hogging. I can then view this or other threads without any CPU impact.

Any ideas?

I don't have any ad blockers running on this site or tab. Maybe others have more CPU cores to burn and this does not bother anyone. This CPU pattern does not show up on my own Vanilla site, neither the production version nor test sites.

William Croft, OpenBCI

wjcroft

OR with a single SQL statement:

UPDATE GDN_User
SET HashMethod = 'Reset'
WHERE Password LIKE '$P$%'

wjcroft

Hi, I would have opened a new thread for this, but see that is disabled. Anyway this is related to my previous posts on this thread.

Any suggestions about what could cause the popup in lower left after a Sign In, "The session could not be started". Shown here,

After closing the Sign in, the lower left box is more visible:

Grep found these locations in the code:

$ grep -r "could not be started" .
./applications/dashboard/controllers/api/AuthenticateApiController.php:            throw HttpException::createFromStatus(401, 'The session could not be started.');
./applications/dashboard/settings/class.hooks.php:                    throw new ClientException('The session could not be started', 401);
./library/Vanilla/Models/SSOModel.php:                throw new ClientException('The session could not be started.', 401);

I'm not using SSO. Seems more likely that it is this code in class.hooks.php:

    /**
     * Check to see if a user is banned.
     *
     * @throws Exception if the user is banned.
     */
    public function base_afterSignIn_handler() {
        if (!Gdn::session()->isValid()) {
            if ($ban = Gdn::session()->getPermissions()->getBan()) {
                throw new ClientException($ban['msg'], 401, $ban);
            } else {
                if (!Gdn::session()->getPermissions()->has('Garden.SignIn.Allow')) {
                    throw new PermissionException('Garden.SignIn.Allow');
                } else {
                    throw new ClientException('The session could not be started', 401);
                }
            }
        }
    }

I'm migrating a 2.1.8p2 Vanilla to 2.8.4. (Yes, will do 3.x eventually.) Booted a clean 2.8.4, then changed config.php database to point to a test version of by 2.1.8p2 database. With various tweeks: put Reset in the PasswordHash field for all old style passwords '$P$%'; fixed GDN_Role and GDN_UserRole, they work fine when I log in as the administrator.

The issue is with the users whose passwords have been reset. After visiting the 'Forgot' link in the error message, I get the email and click on the link, resetting the password. Reset page comes up and completes ok. View database shows new password has been set.

Yet when I try to login as this test user, the popup immediately shows up in lower left: "The session could not be started". Have already checked in forum/log/DebugLog.txt and forum/error_log. Nothing there. I do have the switches set in config.php to enable the DebugLog.

What conditions cause Gdn::session()->isValid() to fail? Where do I find that code, I'm a complete php novice (but fluent in other languages.)

Mentioning @R_J @DaveV @x00 .

Thanks, William Croft, OpenBCI

wjcroft

Ah, disregard the previous post. I had something going on with the cache or ordering in which I did my database tweaks after the import. Things are working now. I was really sweating the cryptic popup, "The session could not be started", because it gave no clues what was the reason. I now believe I had GDN Permission out of sync with GDN Role.

But while I'm here, I'll mention this bug that appears when the user attempting to log in has a GDN_User HashMethod equal to Reset or Random. The pop up box that appears is supposed to have a clickable link 'here' to take the user to the dialog asking for the user email. That clickable link is not working. For now I'm just going to change the text message on Reset or Random to tell them to "click the 'Forgot?' link below".

It would appear that the conditional expression evaluation is failing on the Reset and Random cases:

case 'reset':
                $resetUrl = url('entry/passwordrequest'.(Gdn::request()->get('display') ? '?display='.urlencode(Gdn::request()->get('display')) : ''));
                throw new Gdn_UserException(sprintf(t('You need to reset your password.', 'You need to reset your password. This is most likely because an administrator recently changed your account information. Click <a href="%s">here</a> to reset your password.'), $resetUrl));
                break;

Regards,

William Croft, OpenBCI

R_J

The category is closed for a reason: the version of Vanilla you are using has security issues. Any question concerning a Vanilla version prior to 3.0.2 (currently) can be answered with: "Update!"

Simple as that.