TYPO3 Core

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.

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.

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';

I'm having the same issues. Setting securityLevel for frontend to normal makes it work again.

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!

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

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.

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.

I'm only using standard functionality. No AJAX. And I can leave RSA for the backend turned on.

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?

I can try if you tell me what you need exactly.

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

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.

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

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.

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.

Same problem here on Chrome 28, TYPO3 4.5.29... This is an LTS and really should be fixed ASAP, IMO.