Bug #38660
closedLogin not possible from Firefox when using salted passwords and RSA
Added by Christian Hennecke about 12 years ago. Updated over 6 years ago.
0%
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.
Updated by Steffen Ritter about 12 years 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 about 12 years 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 about 12 years 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 about 12 years 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 almost 12 years ago
I'm having the same issues. Setting securityLevel for frontend to normal makes it work again.
Updated by Jens Neumann almost 12 years 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 over 11 years 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 over 11 years 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 over 11 years ago
I'm only using standard functionality. No AJAX. And I can leave RSA for the backend turned on.
Updated by Xavier Perseguers over 11 years 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 over 11 years ago
I can try if you tell me what you need exactly.
Updated by Christian Hennecke over 11 years 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 over 11 years 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.
Updated by Robert Vock about 11 years ago
As Viktor Livakivskyi points out, it is very problematic, if you send a second request, which generates another keypair.
This will lead to very hard to debug errors. The loginform will have another key as the session.
I found another possibility how to create this bug:
config.baseURL = http://www.example.com/ page.shortcutIcon = fileadmin/nonexistent.ico
This will lead to the following HTML:
<base href="http://www.example.com/" /> <link rel="shortcut icon" href="http://www.example.com/" type="directory" /> <link rel="icon" href="http://www.example.com/" type="directory" />
Chrome sends a request for the favicon, which generates a new keypair in the session.
I think that's a bug in the favicon generation.
Additional Note:
This is also hard to debug, because the request for the non-existant favicon does not appear in Chrome. There is a bug report for that:
https://code.google.com/p/chromium/issues/detail?id=110449
Updated by Tsvetan Dachev about 11 years ago
The same double-request problem (as #7) is caused by the extension tq_seo. It places by default a couple of link-tags in the meta through the function "Link generation" - you could switch it off from the Constant editor.
Updated by Alexander Opitz about 11 years ago
- Status changed from Needs Feedback to New
Updated by Andre Hohmann about 11 years ago
Markus Müller wrote:
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';
Hallo Markus,
in my installation it's the same. But I only have to switch the FE-loginSecurityLevel to 'normal' and then I can log in in the frontend. The backend in my installation works with rsa and chrome.
In older chrome-versions (e.g. vers. 25) I can log in with rsa in the frontend, in newer versions (vers. 28) I can not.
Updated by Gone With the Wind almost 11 years ago
Same problem here on Chrome 28, TYPO3 4.5.29... This is an LTS and really should be fixed ASAP, IMO.
Updated by Nicole Cordes almost 11 years ago
- Status changed from New to Needs Feedback
Could you please check if your openSSL can create private keys.
Updated by Markus Klein over 10 years ago
- Status changed from Needs Feedback to Closed
- Is Regression set to No
No feedback within 90 days. Closing this issue.
Updated by Xavier Perseguers over 6 years ago
- Status changed from Closed to New
- TYPO3 Version changed from 4.7 to 7
- PHP Version changed from 5.3 to 7.0
Reopening this ticket, just had the problem again with following environment:
- Windows 10 (Enterprise, 32-bit)
- Firefox 59.0.1 (32-bit)
- TYPO3 7.6.25
The loading icon is spinning forever. Backend authentication form is the default one, using RSA + salted passwords.
The Network panel in Firefox shows that the RSA key was properly fetched but no other request is done afterwards.
This problem cannot be reproduced on my MacBook Pro running macOS 10.13.4 beta with same Firefox version (59.0.1), in 64-bit.
After disabling RSA authentication for the Backend within file typo3conf/AdditionalConfiguration.php
:
$GLOBALS['TYPO3_CONF_VARS']['BE']['loginSecurityLevel'] = 'normal';
and clearing system cache, authentication works again.