Bug #29130
closed
Security Level "normal" does not work for backend login
100%
Description
Problem:
After introducing rsaauth and saltedpasswords system extensions, the backend user object has been changed to always set the object property "security_level" to what is configured in $GLOBALS['TYPO3_CONF_VARS']['BE']['loginSecurityLevel'].
However although named the same, the configuration and the object property have been intended to be used for different things.
The configuration sets how the transmission of the password should be handled.
The object property defines how the password hash is stored in the database and which value (uident_text, uident_challenged, uident_superchallenged) should be used to compare the submitted password with the password stored in the database.
Solution:
Only change the object property to something different than "superchallenged" if the configuration is not set to "standard" settings (normal, challenged,superchallenged).
Steps to reproduce:
1. Set $GLOBALS['TYPO3_CONF_VARS']['BE']['loginSecurityLevel']='normal';
2. Try to log into the backend.
Updated by Helmut Hummel about 13 years ago
Besides that, the property $this->challengeStoredInCookie must be set to false, so that a previously stored challenge does not hinder to login to work correctly.
Updated by Mr. Hudson about 13 years ago
Patch set 1 of change Ibf1194d04a7159ade9ef33701e92930f98cfb90e has been pushed to the review server.
It is available at http://review.typo3.org/4439
Updated by Susanne Moog about 13 years ago
- Status changed from Accepted to Under Review
Updated by Mr. Hudson about 13 years ago
Patch set 1 of change Ibf1194d04a7159ade9ef33701e92930f98cfb90e has been pushed to the review server.
It is available at http://review.typo3.org/4452
Updated by Anonymous about 13 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 6ed0538b4886a2fa82136ca543c4c850dd104da6.
Updated by Michael Miousse about 13 years ago
I think their is a bug with this patch or maybe i understood it wrong.
when the loginSecurityLevel is set to normal, it should still give the password in clear-text rigth?
because rigth now the password received is encrypted and It causes login error with extension using ldap like ig_ldap_sso_auth.
i think you have a "!" that should not be their before the in_array in this condition:
if (!empty($securityLevel) && !in_array($securityLevel, $standardSecurityLevels)) {
$this->security_level = $securityLevel;
+ } else {
+ $this->security_level = 'superchallenged';
+ }
best Regards
Updated by Helmut Hummel about 13 years ago
Michael Miousse wrote:
I think their is a bug with this patch or maybe i understood it wrong.
It's not a bug, it was a bug before. But indeed it is a bit hard to understand. It took a while to figure out how to solve this correctly
when the loginSecurityLevel is set to normal, it should still give the password in clear-text rigth?
because rigth now the password received is encrypted and It causes login error with extension using ldap like ig_ldap_sso_auth.
If any extension relies on the fact that the cleartext password is in $loginData['uident'], then it is a problem in this extension, because the cleartext password by definition is always stored in $loginData['uident_text']
This is the case before and after this fix.
Unfortunately the cleartext password has also been present in $loginData['uident'] (since 4.3.0) which then triggered the bug in TYPO3. So extension looking for the cleartext password in $loginData['uident'] relied on this very bug.
i think you have a "!" that should not be their before the in_array in this condition:
if (!empty($securityLevel) && !in_array($securityLevel, $standardSecurityLevels)) {
$this->security_level = $securityLevel;
+ } else {
+ $this->security_level = 'superchallenged';
+ }
Nope, it is correct like it is.
Updated by Helmut Hummel about 13 years ago
Michael Miousse wrote:
Ok my bad sorry
No problem. You're not the only one stumbling over this.
thanks
You're welcome. Now it is documented here for others running into this problem.
Updated by