Important: #85026 - salted passwords changes¶
Several changes to the processing of user passwords and storage have been applied to the system. Default settings of the system have been adapted over time, these changes only apply for instances that actively disabled features during upgrading.
All changes are justified by looking at the time line of salted password milestones in the TYPO3 core and should automatically work if no manual changes have been applied to the salted passwords evaluation and configuration settings:
4.3.0 (05/2008) Introduction of salted passwords extension
4.5.0 (01/2011) Introduction of salted passwords bulk update scheduler task
4.5.0 (01/2011) Default hash algorithm is phpass
4.5.0 (01/2011) The reports module shows a warning if saltedpasswords extension is not loaded
6.2.0 (03/2014) Salted passwords extension is mandatory
6.2.0 (03/2014) Salted password storage can not be disabled for backend users anymore
8.0.0 (03/2016) Default hash algorithm of new instances is pbkdf2
As a best practice on the principle of data minimisation, inactive frontend and backend users should be removed from
the database after a while! The main idea is that not existing data can't be compromised in case of a security breach.
lastlogin field of the two user tables
be_users store the last login timestamp of a user, and
soft deleted user records have the
deleted field set to
1. The "Table garbage collection task" scheduler task can
be configured to fully remove those inactive or deleted users from the system. See the
for details on this task.
Salted passwords bulk update task removed¶
The "Convert user passwords to salted hashes" scheduler bulk update task of the
extension has been removed from the system.
The salted passwords extension is by default configured to upgrade single password hashes to the currently configured hash algorithm if a user logs in.
The scheduler task itself allowed to convert clear-text and simple md5 hashed passwords of frontend and backend users to salted md5 passwords. This hash method however is in itself outdated and not considered secure enough anymore. The task needed to be run only once and disabled itself as soon as it walked through all frontend and backend users.
TYPO3 v9 assumes all admins took care of basic salted password security within the last ten years if upgrading from instances older than version 4.3 by running this task once, the upgrade task has now been removed with core version 9.
If there are still clear-text or simple md5 stored passwords, they can be found by searching the database
password of tables
be_users for entries not starting with
$. If there are still entries
like that, an administrator should convert them to simple md5 salted hashes by using the convert bulk update
scheduler task in a core version prior to v9, before upgrading the system to v9.
Disabled clear-text storage of frontend user passwords¶
Storing frontend user passwords as non clear-text but as salted password hashes has been optional since core version 4.3 and enabled by default since core version 4.5. An option to store passwords in clear-text had to be manually configured. This has been removed for backend users in 6.2 already and is now dropped for frontend users as well.
There has been little reason to store passwords in clear-text in the database in the past, most of them only justified by third party systems being directly connected to the TYPO3 database. Those cases should be solved using the Authentication service API instead, which can hand over the clear-text user password upon successful user login, but never persists the native clear-text password. If a third party layer such as LDAP is used for authentication to TYPO3, the user password should not be stored in the TYPO3 internal tables at all. The authentication service chain supports all of these scenarios, it is a common business use case to connect third party applications without the need to store passwords in clear-text anywhere.
In case a TYPO3 instance messed around with configuration options of the salted passwords extension in the past, the
FE.enabled is now ignored and users still having clear-text passwords in the database will get their password
storage strategy automatically upgraded to the configured salted password hash algorithm upon successful login.