Bug #38660
Login not possible from Firefox when using salted passwords and RSA
| Status: | Needs Feedback | Start date: | 2012-07-05 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | saltedpasswords/rsaauth | |||
| Target version: | - | |||
| TYPO3 Version: | 4.7 | Complexity: | ||
| PHP Version: | 5.3 | |||
| Votes: | 3 (View) |
Description
When using salted passwords and RSA in the frontend, I cannot login with Firefox 13.0.1 and the failed login error message is displayed as if I entered an incorrect password. Chrome 20.0.1132.47 m, Opera 12, and IE9 work just fine. Everything running on Windows.
If I switch loginSecurityLevel to normal, I can also login using Firefox.
Related issues
| related to Core - Bug #46032: RSA + SaltedPassword only works not correctly | Closed | 2013-03-05 |
History
Updated by Steffen Ritter 11 months ago
- Status changed from New to Needs Feedback
Works fine for me.... Please investigate further, delete all cookies, disable extensions in Firefox and report back your experience.
Updated by Christian Hennecke 11 months ago
Done, even created a new profile and also tried on a different machine. It does not work with RSA in Firefox, but as soon as I change loginSecurityLevel to normal, I can log in.
Updated by Michael Bakonyi 10 months ago
I've got a bug quite the other way round :
When installing rsaauth + saltedpasswords and configure saltedpasswords to be used for be-logins be-users can't login anymore in Chrome 20/Mac/WinXP + Safari 5/Mac.
When configured to be used in FE FE-login is working in Chrome, but not in Safari.
Both, BE- + FE-login is working in Firefox 14/Mac/WinXP and IE8/WinXP.
I could reproduce this bug in two installations with TYPO3-Version 4.7.2.
Updated by Markus Müller 10 months ago
Here's the same problem with Chrome (v21).
In FF and IE sometimes the first login fails, the second is successfull.
in Chrome every login try fails.
TYPO3 4.5.15, saltedpassword, rsaauth
$TYPO3_CONF_VARS['FE']['loginSecurityLevel'] = 'rsa';
$TYPO3_CONF_VARS['BE']['loginSecurityLevel'] = 'rsa';
When i switch both loginSecurityLevels to normal, it works.
$TYPO3_CONF_VARS['FE']['loginSecurityLevel'] = 'normal';
$TYPO3_CONF_VARS['BE']['loginSecurityLevel'] = 'normal';
Updated by Marc Neuhaus 9 months ago
I'm having the same issues. Setting securityLevel for frontend to normal makes it work again.
Updated by Jens 9 months ago
I confirm this Bug for TYPO3 4.5.19 and PHP5.3
Hope this will be fixed fast, for me i´s no solution to set the loginSecurityLevel to normal for a live system!
Updated by Viktor Livakivskyi 5 months ago
I've faced same problem recently and after researches I've found the reason.
In my case it was wrong <f:cObject> tag in fluid layout, which should return an image resource for background image, but due to wrong code image wasn't returned and Firefox (as well, as some versions of Chrome) still was trying to fetch an image, so I was getting such a requests in 'HttpFox':
GET 200 text/html http://domain.tld/index.php?id=2 GET 200 text/html (NS_IMAGELIB_ERROR_NO_DECODER) http://domain.tld/index.php?id=2
So, it first was taking a real page, adn after that tried to load an image from a page, but due to broken code not an image was returned, but complete output of a website! Firefox understands, taht it is not image/png, throws NS_IMAGELIB_ERROR_NO_DECODER and doesn't accept the output.
What it means for us? It means, that code runs twice!
First time - normal HTML page is returned, public/private key pairs are created. Public key is put to the login form and private key is saved in session and db.
Then code runs for a second time - all same is performed, with only one difference: output, that is shown in browser is not updated and therefore we get a collision: felogin form contains public key from a first run, but session contains part of private key from a second run and therefore expects public key from second run.
After removing problematic code, we can login again from any browser.
So, general great advise: check request and responce headers in browsers, that doesn't allow you to login. Maybe you run in same issue, as I had. And non-allowed logins isn't the worst thing, since double-running code is much worse.
Updated by Xavier Perseguers 3 months ago
Pinging...
Could you further investigate the problem? Are you using some sort of AJAX instead of the standard plugin for Frontend login? Is is related to Backend as well? The bug description describes a bug in Frontend but the solution to switch off RSA in your localconf.php does it for Backend as well.
Updated by Christian Hennecke 3 months ago
I'm only using standard functionality. No AJAX. And I can leave RSA for the backend turned on.
Updated by Xavier Perseguers 3 months ago
Are you able to debug the problem or not? I mean check which key is present in the login form, sent back to TYPO3 and what's in the DB?
Updated by Christian Hennecke 3 months ago
I can try if you tell me what you need exactly.
Updated by Christian Hennecke 3 months ago
Hope this helps:
Actual test password: +XrGc.004*
Database password field: $1$hle1h7zL$637rYKloA53xflGdYPMwS/
Login form:
rsa_n: C286EAE1738454BB299BA8F56805FB3D42C19B4F14CB3821A156AD2D082CDADD610D08CB90AF20AE2FFEDE77D44941CD32B03170F340652DFF8664CD18E9630BB87D1AB308BA5F0DA409E2D185E87BB532E5228DF718ACC5E4BC42843C68422A2AD33EBBA04EBB058C1EFDD4176A595914577F46EBD714605D5463FBB81D3367
rsa_e: 10001
POST variable pass: rsa%3AZZlFfmKOnJLHOYRP59sXHeXYV0a91ZmZepI6rdsIv%2B06dMjIgrH3IZ41bQneR0be0a7EeMKXWbo4VqkPJXV%2BKChzx6BAq7od44mw%2BK7OiSo%2Fhf8V7araembTNORcRIbdOrNhh3k1Ep%2FYiHgaxEe42It4j947SRB3H9P%2F1%2FZJ%2FPE%3D
Updated by Sven Teuber 3 months ago
I have the same problem. TYPO3 6.0.1, felogin with rsa authentication.
Password for the user is "lhc" (without quotes).
The felogin-form encrypts the password as $1$NDXke86W$DzJTR2yQN.2Dc7e9frhr3.
TYPO3\CMS\Saltedpasswords\Salt\Md5Salt encrypts it as $1$NDXke86W$Dk1ygYkOZJyNno8LE6A.5/
Since the two hashes do not match, an "invalid password" error ist triggered and the login is not possible.