I keep getting told I'm entering the incorrect password

[Bruce Banner]

So I can't login to my board. I now have to delete the board and reinstall it. This is the second time this has happened to me in the last 2 or 3 weeks. It's like something is changing my password. I'm definitely entering the correct one. I've checked and rechecked and rechecked multiple times. It's the one my browser has stored. But the board keeps telling me it's wrong.

[KevC]

You almost never need to delete and reinstall. Almost everything can be fixed without doing that.

Have you tried a different browser?
Have you tried the SQL query to create an admin account so you can get in to edit the password on your account?


In phpMyAdmin, run the following, which will create an admin user named Admin1 with a password of admin. From that point you should be able to get into the ACP.

Code: Select all

INSERT INTO phpbb_users (user_type, group_id, username, username_clean, user_regdate, user_password, user_email, user_lang, user_style, user_rank, user_colour, user_posts, user_permissions, user_ip, user_birthday, user_lastpage, user_last_confirm_key, user_post_sortby_type, user_post_sortby_dir, user_topic_sortby_type, user_topic_sortby_dir, user_avatar, user_sig, user_sig_bbcode_uid, user_jabber, user_actkey, user_newpasswd) VALUES (3, 5, 'Admin1', 'admin1', 0, '21232f297a57a5a743894a0e4a801fc3', '[email protected]', 'en', 1, 1, 'AA0000', 1, '', '', '', '', '', 't', 'a', 't', 'd', '', '', '', '', '', '');

Change your table prefix if it is not phpbb_

See Executing SQL Queries in phpMyAdmin if you are unfamiliar with running database queries.

As soon as you have done this, use the temporary admin account to change the details on the original admin account, then delete the temporary account.
This is because:

1. anyone could use that account to log in to your board if you didn't change the password.
2. this temporary user has not been fully set up (e.g. it is not a member of the "Registered users" group, so it won't have normal access to your forums).

To remove the account you will first need to remove ???founder??? status from it: ACP > USERS AND GROUPS tab > Manage Users > Admin1 > Overview > Founder = No

[Bruce Banner]

It's too late now, I'm afraid. I already started deleting the board a half an hour ago or so. I guess I could try that method if this happens again, though, so thanks. But I don't understand what could be causing the board to not accept the correct password. I can't remember how this happened the first time but this time, I opened a different browser and tried logging in to one of my test accounts. Was told I'd entered the incorrect password so thought I'd just mistyped so I very carefully made sure to type in the correct password but I still wasn't allowed in. So then I tried logging in to my original admin account that I started the board with, used the correct password that the browser had stored, but I still wasn't allowed in. So then I went back to my default browser and tried there and STILL no luck. What could be causing the board to reject the correct passwords?

[KevC]

It's often a cookie/browser thing. I had people with the same problem PM me their password and I've logged in first time. It's because I don't have a pre-saved cookie for the site.

[Bruce Banner]

It's often a cookie/browser thing. I had people with the same problem PM me their password and I've logged in first time. It's because I don't have a pre-saved cookie for the site.

I'd considered that but I think this might be more complicated because I tried clearing my browser cookies and browser cache to see if that'd help but it didn't, so then I just started deleting the board. If I use the method you recommended in your first post, could I just edit the password and then immediately change it back again, or would I have to stick to a new password?

[KevC]

You can keep the same password. Just try 123456 to get in and then change it in the UCP to the one you want.

[EA117]

You may already be aware, but one thing which can create exactly "the password you are entering is not correct" behavior -- even though you know it is the correct password -- is if the PHP configuration is changing out from under the existing phpBB board. e.g. If the PHP version moved backwards (e.g. PHP 7.3 to PHP 7.2, or PHP 7.2 to PHP 7.1), or maybe even just had certain options or modules disabled even if the PHP version itself didn't change.

Such that PHP no longer has access to the password hashing algorithm necessary for comparing a hash of the password you're entering against the currently-stored password hash in the phpbb_users table.

If you know you weren't intentionally changing anything about the PHP configuration, maybe next time it happens (if there is a next time it happens), take a look at the user_password column for your user entry in the phpbb_users table, and see what prefix the user_password value has on it. e.g. Would probably be $argon2id$ for a password you logged in with using PHP 7.3 or later.

And then just use phpBB 3.3.x's normal "forgotten password" feature to override and set yourself a new password, without knowing or entering your existing password. Editing the database and creating an additional user works too; but phpBB already has a built-in feature for handling how to reset your password. And then once you've given yourself a new password that works for logging in, see if the hash method prefix on your user_password value is any different than it was before. This doesn't prove "why" it changed, but at least would confirm or rule out whether the same hashing method was no longer available to your running phpBB board.

I agree with KevC that "failure to login" can be a cookie thing, unless you specifically are receiving "You have specified an incorrect password" as the failure. Indeed, cookie problems can cause issues where you "fail to login successfully", but with phpBB reporting "you don't have access" or "form invalid" or some other "indirect" failure like that. "You have specified an incorrect password", on the other hand, is a message returned because the hash of what you entered doesn't match the hash stored for the username you specified. It's an outcome which is "not cookie-dependent."

Well, I should caveat all of this to say "if you're using the default phpBB DB auth provider." If you've introduced some external or additional auth provider for your phpBB board, the conditions under which "You have specified an incorrect password" gets returned may be specific to that provider, and the values being compared against are probably not the user_password database value.

[P_I]

Could the OP be encountering viewtopic.php?f=661&t=2571596? and need to ensure they have the sodium module installed in PHP.

[Bruce Banner]

You can keep the same password. Just try 123456 to get in and then change it in the UCP to the one you want.

OK, great, thanks. Forgot to mention, I only tried clearing the cookies and cache from one browser, not from both I'd tried. But as I was having the same problem in both browsers, I'd imagine it's probably a cookie issue then, right? So if this happens again but I do regain access, should I then go into the cookie settings and change the cookie name? I always change it immediately after installation but does it need to be frequently changed?

If the PHP version moved backwards (e.g. PHP 7.3 to PHP 7.2, or PHP 7.2 to PHP 7.1), or maybe even just had certain options or modules disabled even if the PHP version itself didn't change.

I think it might be this. I was having trouble with an extension that hadn't been updated since before 3.3.0 so I thought I'd try it out on a 3.2.10 board, but my PHP version was set to 7.4 which 3.2.10 can't be installed on, so I changed the version to 7.2, not knowing that this might have any significant effect on my 3.3.1 board. Only problem is I can't remember whether or not when this problem occurred this time, that was the first time I'd tried logging in to an account since I'd changed the PHP version. If it was, then it's probably the backwards change that caused the problem, but if I'd successfully logged out and logged in again between changing the PHP version and when this problem occurred, then I guess it would have to be something else.

If you know you weren't intentionally changing anything about the PHP configuration, maybe next time it happens (if there is a next time it happens), take a look at the user_password column for your user entry in the phpbb_users table, and see what prefix the user_password value has on it. e.g. Would probably be $argon2id$ for a password you logged in with using PHP 7.3 or later.

And then just use phpBB 3.3.x's normal "forgotten password" feature to override and set yourself a new password, without knowing or entering your existing password.

Unfortunately, that's not working for me for some reason. I forgot to mention earlier that that was something else I'd tried before I started deleting the board. I filled in my email address and username as I'd allowed email address re-use because I wanted to set up test accounts with the same email for the purpose of testing extensions, but when I checked my inbox, there was nothing there, and nothing in my spam folder either. There's still nothing in either now several hours later.

see if the hash method prefix on your user_password value is any different than it was before. This doesn't prove "why" it changed, but at least would confirm or rule out whether the same hashing method was no longer available to your running phpBB board.

Just to make sure I understand you right, if the prefix is different, that confirms the same hashing method is no longer available, but if it's the same, that confirms the same hashing method is still available. Right?

I agree with KevC that "failure to login" can be a cookie thing, unless you specifically are receiving "You have specified an incorrect password" as the failure. Indeed, cookie problems can cause issues where you "fail to login successfully", but with phpBB reporting "you don't have access" or "form invalid" or some other "indirect" failure like that. "You have specified an incorrect password", on the other hand, is a message returned because the hash of what you entered doesn't match the hash stored for the username you specified. It's an outcome which is "not cookie-dependent."

Sorry, can't remember now what the exact error message displayed was. Hadn't occurred to me at the time that the wording might matter so didn't take note of it. I think it was "You have specified an incorrect password" but can't be sure.

Well, I should caveat all of this to say "if you're using the default phpBB DB auth provider." If you've introduced some external or additional auth provider for your phpBB board, the conditions under which "You have specified an incorrect password" gets returned may be specific to that provider, and the values being compared against are probably not the user_password database value.

Sorry, I've no idea what a phpBB DB auth provider is, how to check whether I'm using the default one, or how to introduce an external or additional one. I don't understand any of the technical details.

Could the OP be encountering viewtopic.php?f=661&t=2571596? and need to ensure they have the sodium module installed in PHP.

Just looked under PHP Extensions for sodium and found it wasn't enabled so I ticked the box. That's right, isn't it? Or should I have enabled it elsewhere?

[EA117]

If it was, then it's probably the backwards change that caused the problem, but if I'd successfully logged out and logged in again between changing the PHP version and when this problem occurred, then I guess it would have to be something else.

Agreed; this root cause fits with the symptoms, but only if every attempt to login with an existing account password failed after the switch, and not "at some point later."

I filled in my email address and username as I'd allowed email address re-use because I wanted to set up test accounts with the same email for the purpose of testing extensions, but when I checked my inbox, there was nothing there, and nothing in my spam folder either. There's still nothing in either now several hours later.

Fair enough. It's not the time anyone wants to learn that something eats the password reset notification emails, but that failure doesn't really figure into or illuminate anything about the original "can't login with my known password" issue. It just means yes you would need to resort to the direct database edit or similar in order to make a recovery account that lets you reset your original account passwords by other means.

Just to make sure I understand you right, if the prefix is different, that confirms the same hashing method is no longer available, but if it's the same, that confirms the same hashing method is still available. Right?

Correct. If moving from PHP 7.4 to PHP 7.2, the passwords currently in the database would have $argon2id$ prefixes, and after successfully resetting your password you would see a $argon2i$ prefix instead. The PHP 7.2 system couldn't match against those hashes in the database, because it doesn't have access to the $argon2id$ algorithm. The algorithm it does have access to is the one you see set after successfully resetting your password.

When there is a known change in PHP versions, the story is a little more straight forward even without looking at the hashes in the database. Where looking at the hashes provides greatest value would be a scenario such as "no, I did actually move from a PHP 7.4 system to another PHP 7.4 system, but I cannot login with existing passwords." The fact that the PHP 7.4 system you moved to didn't have the expected hashing algorithm available would be revealed in the algorithm you saw it use (instead of the expected one) when setting the password.

I think it was "You have specified an incorrect password" but can't be sure.

Also fair enough. Need to leave room for the possibility that we're barking up the wrong tree, and maybe the failure was actually "form invalid" or something else.

Just looked under PHP Extensions for sodium and found it wasn't enabled so I ticked the box. That's right, isn't it? Or should I have enabled it elsewhere?

You're saying that sodium is offered in your PHP 7.2 configuration? Or are you saying you've switched back from PHP 7.2 to PHP 7.4 again, but when visiting the PHP modules, see that sodium is not selected?

Yes, selecting the sodium module in the PHP Extensions list, and then making sure you commit or save that change, is all that's expected to be necessary. Note this does add another unknown for "was the sodium module selected when you were running PHP 7.4 previously, before switching to PHP 7.2?"

But, if now you're back on PHP 7.4 with the sodium module now enabled, there should be no hash present in the database that PHP couldn't compare against & convert successfully. So if you do still have any kind of login issue, let's determine precisely what the failure message is.

[stevemaury]

Was this a host one-click installation? What is the EXACT COMPLETE error message?

[Bruce Banner]

Agreed

Thanks for all the help and info!

Need to leave room for the possibility that we're barking up the wrong tree, and maybe the failure was actually "form invalid" or something else.

Definitely wasn't "form invalid", no. Can't be exactly sure what it was but I do know it wasn't that.

You're saying that sodium is offered in your PHP 7.2 configuration? Or are you saying you've switched back from PHP 7.2 to PHP 7.4 again, but when visiting the PHP modules, see that sodium is not selected?

Yes, selecting the sodium module in the PHP Extensions list, and then making sure you commit or save that change, is all that's expected to be necessary. Note this does add another unknown for "was the sodium module selected when you were running PHP 7.4 previously, before switching to PHP 7.2?"

But, if now you're back on PHP 7.4 with the sodium module now enabled, there should be no hash present in the database that PHP couldn't compare against & convert successfully. So if you do still have any kind of login issue, let's determine precisely what the failure message is.

Not sure if it was offered in my 7.2 configuration, might have been, but I'm definitely back on 7.4 again now and had to enable sodium myself, so I can only guess that that box wasn't ticked the first time I was on 7.4.

Have left the PHP configuration alone now since installing the new test board and haven't had any problems at all of any kind so far. So I think it's safe to say the cause of the errors was me switching back from 7.4 to 7.2 just to test out that extension on a 3.2.10 board. Won't be doing that again while I'm still testing my 3.3.2 board. Thanks again.

Was this a host one-click installation? What is the EXACT COMPLETE error message?

I can't remember now; it's been a day or two. If it happens again, I'll take note.

[stevemaury]

Was this a host one-click installation?

[Bruce Banner]

Was this a host one-click installation?

I don't know what that means.

[Lumpy Burgertushie]

did you install it yourself or did you click a button from your hosting control panel to install it?


robert