Project

General

Profile

Actions

Bug #86155

closed

Login in Backend after Upgrading from 8.7.19 to 9.4 throws error

Added by Angelo Previtali over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Backend API
Target version:
Start date:
2018-09-05
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

After cleaning out all not compatible extensions in a 8.7.19 and upgrading the wizard in the 9.4 the Upgrade Wizard says that everything is done with 100% complete.

I cleaned up everything like caches and the PHP Cache.

Afterthat, if you want to login into the BE a blank page is apperead. If enabling the Debug modus the following PHP error is shown:

Fatal error: Uncaught TYPO3\CMS\Core\Crypto\PasswordHashing\InvalidPasswordHashException: Configured default hash method TYPO3\CMS\Core\Crypto\PasswordHashing\Argon2iPasswordHash is not available, missing php requirement? in /home/httpd/vhosts/demoweb.ch/t9demo.demoweb.ch/typo3/sysext/core/Classes/Crypto/PasswordHashing/PasswordHashFactory.php:125

Stack trace:
#0 /home/httpd/vhosts/demoweb.ch/t9demo.demoweb.ch/typo3/sysext/core/Classes/Authentication/AuthenticationService.php(132): TYPO3\CMS\Core\Crypto\PasswordHashing\PasswordHashFactory->getDefaultHashInstance('BE')
#1 /home/httpd/vhosts/demoweb.ch/t9demo.demoweb.ch/typo3/sysext/core/Classes/Authentication/AbstractUserAuthentication.php(714): TYPO3\CMS\Core\Authentication\AuthenticationService->authUser(Array)
#2 /home/httpd/vhosts/demoweb.ch/t9demo.demoweb.ch/typo3/sysext/core/Classes/Authentication/AbstractUserAuthentication.php(410): TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->checkAuthentication()
#3 /home/httpd/vhosts/demoweb.ch/t9demo.demoweb.ch in /home/httpd/vhosts/demoweb.ch/t9demo.demoweb.ch/typo3/sysext/core/Classes/Crypto/PasswordHashing/PasswordHashFactory.php on line 125

So there is no change to log in.

TYPO3 version 9.4
PHP 7.2
LINUX


Files

bug.JPG (276 KB) bug.JPG Philipp Faber, 2018-09-05 16:15

Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #86386: Run silent upgraders after install tool loginClosed2018-09-26

Actions
Related to TYPO3 Core - Task #86392: Mitigate argon2i hash issuesClosed2018-09-26

Actions
Related to TYPO3 Core - Task #86402: Add informational upgrade wizard for argon2iClosed2018-09-27

Actions
Actions #1

Updated by Christian Kuhn over 5 years ago

Go to the install tool and select a different hash algorithm in setting -> configuration presets. You may also need to add a new admin user then reset the password of your old user.

Apart from that i wonder why you had an argon2i has for the old user in the database already, this indicates the algorithm is available for you, but isAvailable() still returns false. It would be cool if you could have a deeper look at that, maybe our hash detection is broken at this point.

Actions #2

Updated by Angelo Previtali over 5 years ago

Ok. It works now.

1. I logged into the install tool in setting -> configuration presets -> Password hashing settings and choosed another encryption like i.e. "phpass". Afterthat i added a new admin-user and logged into the BE with this new user without problem.

After that i set to the actual admin user (that did not worked anymore) a new password and tried to login into the BE. -> It's working again.

Seems that by upgrading there is something you should fix on my opinion so that the BE users gets "converted" in the upgrade procedure already without setting up manually this like described.

Actions #3

Updated by Philipp Faber over 5 years ago

I had the same thing, did what Christian suggested and I was able to log in to the Backend.

Actions #4

Updated by Philipp Faber over 5 years ago

InvalidPasswordHashException shows up again after next deployment. DB has not changed. See image.

Actions #5

Updated by Stephan Großberndt over 5 years ago

  • Description updated (diff)
Actions #6

Updated by Philipp Faber over 5 years ago

On another server, I am not able to create a backend user from the install tool, after the InvalidPasswordHashException. I get this error:

Something went wrong. Please use Check for broken extensions to see 
if a loaded extension breaks this part of the install tool and unload it. 
Actions #7

Updated by Christian Kuhn over 5 years ago

Some background info:

The default hash mechanism is tested and set / upgraded if you open the install tool if upgrading from v8 to v9.

So, if you upgrade locally on your dev machine that supports argon, it will be selected and configured as the default hash mechanism. If you then login locally with a user, the hash in the database for that user will be upgraded from whatever has been selected before to argon.

If you then deploy that instance to some other system that does not support argon, you end up with a hash mechanism for that user in the database that will fail with above error message: the new system detects argon is used for the BE user, but the mechanism is not available server side.

You have 3 options in this case:

  • (as outlined above): Change manually to a different default hash mechanism on the server instance, add a temp user to reset affected users to the alternative mechanism by resetting their password.
  • (preferred): Fix the system that does not support argon. There is literally zero reason to have PHP 7.2 without argon support. Make your server admin / hoster fix that.
  • Select a different hash algorithm in standalone install tool after v8 -> v9 upgrade on your dev system before logging in with a BE user, so your hashes are not upgraded to argon, even if your local system supports it.
Actions #8

Updated by Christian Kuhn over 5 years ago

  • Status changed from New to Needs Feedback

So, I think the issue is about deploying an instance that is configured to use argon to a server that does not support it. And optionally having single users upgraded to that hash algorithm already.

Thus, this is more a configuration / deployment issue than a core fail. argon is the mechanism to go and we will keep configuring it as default hash if the system the upgrade is performed on, supports it. If your local dev instance is not identical to your live system, there is not much we can do, that is not in our hands.

I'll set the issue to 'needs feedback' for now since there is currently no hint the hash mechanism detection in plain core is broken. If no further hints on an actually core bug come in, I'll close the issue after a while.

I also hope the issue now has enough information for other users who stumble upon that for instances that are upgraded on a system that supports argon and later deployed to a system that does not.

Actions #9

Updated by Susanne Moog over 5 years ago

  • Target version changed from next-patchlevel to 9 LTS
Actions #10

Updated by Christian Kuhn over 5 years ago

  • Status changed from Needs Feedback to Closed
Actions #11

Updated by Christian Kuhn over 5 years ago

ok, it seems we will do some patches to mitigate that issue: better communication in core if that happens and similar patches.

Actions #12

Updated by Christian Kuhn over 5 years ago

  • Related to Bug #86386: Run silent upgraders after install tool login added
Actions #13

Updated by Christian Kuhn over 5 years ago

  • Related to Task #86392: Mitigate argon2i hash issues added
Actions #14

Updated by Christian Kuhn over 5 years ago

  • Related to Task #86402: Add informational upgrade wizard for argon2i added
Actions

Also available in: Atom PDF