Bug #37421
closedRSA Auth prevents User from login
100%
Description
Due to some mystical cache issues, my users complain about login failures. In the logs i see, that the rsa-aes keys are invalidated by time. To avoid frustrated users i suggest to load the rsa key via ajax, and if it's life is nearly over, just request a new one, to ensure, that users always can login.
This is related to 4.5, 4.6, 4.7, 6.0-dev
Updated by Stephan Großberndt about 12 years ago
I have users complaining too that often (but not always) the first login fails (using saltedpasswords/rsaauth). After reloading the login form it works. This is not a new issue - at least for 4.5.15 and 4.6.8 it was reported too.
Updated by Kay Strobach about 12 years ago
i know that this issue is known, but i can't find the related issue. as this is bothering me, i also suggested a solution... (load and refresh the key via ajax)
Updated by Kay Strobach about 12 years ago
Others have the problem as well:
http://www.typo3-media.com/blog/website-caching-login.html
Do you see any chance to get that issue voted up?
Regards
Kay
Updated by Helmut Hummel about 12 years ago
I think the key should be loaded by ajax right before the form is submitted. By doing so it is not necessary any more to load the key at a regular basis.
Updated by Mario Rimann about 12 years ago
I just verified the issue on a 4.7.1 installation with rsaauth + saltedpasswords (loginSecurityLevel = rsa).
The following steps are reproducable (Tested with Chrome to verify the noted steps below, but it also happens in Firefox, never logged in to that BE with Chrome before):
- Open a tab, navigate to foobar.tld/typo3
- Enter Username/Password and submit
Login fails + Form is shown again
- Enter Username/Password again and submit
Login success!
- Logout from Backend
Above steps can be reproduced after logout (2 rounds needed to be logged in)
I then also tried whether saving the credentials in the browser changes the behaviour - it doesn't. Also when Chrome prefills the form, I have to submit it two times to get logged in to the backend.
I had the impression that I had a similar (if not identical) behaviour also in 4.5.x - but never found a way to reproduce it consistently (and it happened every few days, in different installations - randomly). Now in 4.7.x it's reproducable consistently.
Updated by Stephan Großberndt about 12 years ago
- Target version set to 4.7.2
Could someone with according rights please change the priority of this bug to "must have"?
Updated by Oliver Hader about 12 years ago
- Status changed from New to Accepted
- Priority changed from Should have to Must have
Updated by Oliver Hader about 12 years ago
- Target version changed from 4.7.2 to 4.7.3
Updated by Helmut Hummel about 12 years ago
Mario Rimann wrote:
Above steps can be reproduced after logout (2 rounds needed to be logged in)
I had the impression that I had a similar (if not identical) behaviour also in 4.5.x - but never found a way to reproduce it consistently (and it happened every few days, in different installations - randomly). Now in 4.7.x it's reproducable consistently.
I cannot reproduce it on a clean 4.7.1 install. Do you have phpmyadmin installed on that installation? This extension messes with the PHP session, resulting in the described behaviour. If not phpmyadmin, any other extension that does some weird session handling?
Updated by Kay Strobach about 12 years ago
no phpmyadmin @all review, but some caching options enabled in apache.
login works smooth for me with rsaauth disabled, but is always blocked once with rsaauth. This also happens, if the loginpage is loaded in a background tab and used after some hours ;) - (timeout)
Updated by Stephan Großberndt about 12 years ago
Yes, on those websites phpmyadmin is installed and indeed this was the cause for the problems! After uninstalling phpmyadmin the login works again on first try. So this should be filed as a phpmyadmin-bug?
Updated by Mario Rimann about 12 years ago
Helmut Hummel wrote:
I cannot reproduce it on a clean 4.7.1 install. Do you have phpmyadmin installed on that installation?
I can confirm that on the same installation where I tested this problem a few days ago (see above), removing phpmyadmin + clearing caches solved the problem. I'm now able to login directly to the BE without problems.
Thanks for the hint with phpmyadmin - now I have the last reason to remove this extension once for all, ...
Updated by Alban Cousinie about 12 years ago
Hello,
I had the same problem of failing first identification on 4.7.2 installation. After reading this issue report, I have uninstalled the phmyadmin extension and I confirm it fixed the issue.
So it is likely the secured authentification code of this extension is interfering with the Typo3 authentification process. I figure phpmyadmin extension's security has been worked a lot for Typo3 because Phpmyadmin has proven in the past to be a wonderfull backdoor with its security breaches. But the authentification communication between Typo3 and phpmyadmin has been buggy for quite a year now : often when you would click on the phpmyadmin module title in the left column, you would have an authentification error in the right panel. In this case you have to reload the whole backend in your browser to be authentified and have phpmyadmin to show up. So it is likely phpmyadmin's authentification code does require some tweaking.
Updated by Michael Bakonyi about 12 years ago
I've the same problem but without having phpmyadmin installed. I figured out that in my case felogin is causing the problem. So after uninstalling felogin, restarting Firefox, clearing its cache I can login with the first try.
I can confirm this issue with two installations one with 4.7.1 and the other with 4.7.2 installed. So now I don't know if this is still a rsaauth-related problem or if we should change the category of this issue to "felogin". Or shall I open a new bug-report for felogin?
Michael
Updated by Kay Strobach about 12 years ago
it's rsaauth related - rsaauth should fetch the key via ajax directly before login ... thanks for sharing your thoughts and problems ;)
Updated by Tobias Schaefer about 12 years ago
On a 4.7.3 installation I'm having the same problem with the first FE-login (not with BE-login), but removing phpmyadmin didn't helped. Not even with the new version 4.14.0 published at 2012-08-13 which fixed the BE-login problem (http://bugs.typo3.org/view.php?id=18560). But I found that this bug only occurs if I'm trying to login right after logout. If I go to the login-page using the menu the login works at the first try.
Updated by Michael Bakonyi almost 12 years ago
Any news on this issue? I don't think it's "enterprise" to let hundreds of users try to login two times so let's do something here. :)
If this is not fixed yet I'd like to do some sponsoring on fixing that issue. If my sponsorship won't be enough for the effort of fixing that bug I'd be happy if others would sponsor some money, too.
Btw. I miss the "sponsor-feature" in Redmine we had in the old bug-tracker. :)
Updated by Sebastian Steinmetz almost 12 years ago
Hi, I am also experiencing this problem in at least one installation of a client. And it is also reproducible in my local testing environment.
The problem occurs if you logout and want to login right away. Then it seems as if the RSAAuth information in the session gets messed up:
Step 1: user logs in, everything is fine. The private-key used for the login was generated and has the ID 1)
Step 2: user is logged in, user hits "logout"
- the RSAAuth extension creates a new key-pair and stores one part of the private in the session and the other part into the database. The session also contains the key-pair-id (let's say the id is 2)
Step 3: user wants to login again.
- problem: the session that gets loaded still contains the private-key-id 1 as if the new key would not have been created. But the public key that was used for encrypting the users credentials belongs to id number 2.
So somewhere between step 2 and 3 the session does not get stored correctly. This is absolutely weird. Maybe someone with deeper knowledge in the PHP session handling and the RSAAuth-extension should have a look into this. I'll continue digging, over the next days as time permits.
Updated by Urs Braem almost 12 years ago
Just another case for the record (using 4.5.19 LTS on Chrome 22)
- Log in (after 2nd try)
- Go to direct_mail
- It logs me out
- Log in again
- Go to direct_mail
- Now I can work
These extensions are installed:
$TYPO3_CONF_VARS['EXT']['extList'] = 'css_styled_content,info,perm,func,filelist,about,tsconfig_help,context_help,extra_page_cm_options,impexp,sys_note,tstemplate,tstemplate_ceditor,tstemplate_info,tstemplate_objbrowser,tstemplate_analyzer,func_wizards,wizard_crpages,wizard_sortpages,lowlevel,install,belog,beuser,aboutmodules,setup,taskcenter,info_pagetsconfig,viewpage,rtehtmlarea,t3skin,t3editor,reports,felogin,linkvalidator,recycler,t3filelist,realurl,ke_search,realurl_clearcache,image_autoresize,tsconf,sourceopt,tscobj,naw_securedl,saltedpasswords,scheduler,additional_scheduler,kickstarter,formhandler,braem_oda_filelist,braem_oda_wb,css2inline,braem_oda_jobs,tt_address,direct_mail,df_direct_mail_subscription,nc_staticfilecache,it_dmailer_htmlfix,rsaauth,scriptmerger';
Like Michael Bakonyi I would also be glad to pledge a little sponsoring for this issue. but how? Would be cool if there was a kickstarter (not the TYPO3-Kickstarter :-) like functionality...
Updated by Francois Suter almost 12 years ago
I also observe this bug, with the same remarks as Sebastian: there is a shift of key number, which makes rsaauth unable to decrypt the password. After reloading the page one or more times, the login finally works.
I haven't been able to find the issue. It's really weird. Actually of all the sites I work on, it's the first time I get it. So it's quite obvious that it depends on server settings, maybe PHP, maybe also due to a proxy (that client uses a proxy and we get or not the mistake depending on whether the server is behind the proxy or not). I'm not expert enough in session storage (and possible influence by server/PHP settings or proxies) to know where to start digging.
Knowing what the problem is would of course help making rsaauth more solid.
Updated by Stephan Großberndt almost 12 years ago
Using a current version of phpmyadmin (v.4.14.0) the login error on first try is fixed.
Updated by Viktor Livakivskyi over 11 years ago
Hi all.
I've also recently faced same problem and it was site-specific in my case.
You may look at reason here: Bug #38660
Maybe, that may help someone :)
Updated by Moritz Völling over 11 years ago
Stephan Großberndt wrote:
Yes, on those websites phpmyadmin is installed and indeed this was the cause for the problems! After uninstalling phpmyadmin the login works again on first try. So this should be filed as a phpmyadmin-bug?
On my site, it used to be also a conflict with phpmyadmin (v. 3.5.2). Renaming the phpmyadmin directory to a non-standard name solved the problem! It seems phpmyadmin uses the same RSAAuth token.
My working example can be found here: http://www.wellness-heaven.net
However, reading the posts above, the bug seems to appear also on sites which do not use phpmyadmin at all. Try searching for other instances of RSAAuth ...
Updated by Kay Strobach over 11 years ago
i also had that problem in installations with no phpmyadmin installed.
This issue has two parts:- somtimes the login fails due to caching problems.
- sometimes the caching fails if the user has opened the login page for hours and the rsa key expired
Both problems can be solved, by fetching a new rsa key if there is a onblur on the username or before submitting the form.
Updated by David Bruchmann over 10 years ago
On the current site rsaauth is not working at all.
I installed felogin, put it as Content-Element on one page and have additionally a modal-box on each page that is shown by click on a login-button.
Maybe the double usage is the reason, but usually the user never sees the login-page but only the modal-box.
Updated by Gerrit Code Review over 10 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28893
Updated by Gerrit Code Review over 10 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28893
Updated by Gerrit Code Review over 10 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28893
Updated by Gerrit Code Review over 10 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28893
Updated by Helmut Hummel over 10 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset b5798938ebeb5e2c6f11a12b3ab6ad10dc8ec905.
Updated by Patrick Lenk almost 10 years ago
Are these changes in version 4.5? Or it is planned to apply the changes there?
thanks
Updated by Riccardo De Contardi almost 7 years ago
- Status changed from Resolved to Closed