[#18559] - Deleted 2FA key prevents login
- Closed - Unconfirmed Report
- 11 Mar 2020
- Medium
- Build: 3.8.2
- # 18559
Steps to reproduce the issue
In a ver prior to 3.7 (may also be the case for more recent versions)
Create a 2 Factor Authentication sign-in for the admin user with Google Authenticator (not tested with others 2FAs).
Then delete the 2 Factor Authentication setup.
Note the otpKey field in users table still contains 'totp:' and the otep field is now empty.
Upgrade to version 3.8.2
Admin attempts to Sign-in
Expected result
Admin sign-in should be accepted (perhaps with a response reminding them to set 2 Factor Authentication!).
Actual result
Admin sign-in is refused with request to complete the Secret Key, Admin is locked out
Admin has to edit user table and remove 'totp:' from the otpKey field.
System information (as much as possible)
MySQL v5.5.46-log
PHP v5.6.30
Joomla! 3.8.2 Stable [ Amani ]
Joomla Platform 13.1.0 Stable [ Curiosity ]
Linux bitnami-joomla-dm-4779 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u5
Additional comments
On delete 2 Factor Authentication, User table, otpKey field still retains 'totp:' with the otep field being empty.
It may be that deleting 2 Factor Authentication in more recent versions tidies up the user table properly and this error does not appear. However, if an admin deleted their 2FA in an earlier version they will be locked out of the site and will need to edit the db directly to gain access.
| Priority | Urgent | ⇒ | Medium |
| Status | New | ⇒ | Discussion |
I had 2FA created/set back in 2015 and then I deleted it around early 2016. So I think unless you go through the steps of installing a previous 3.4.x version it is going to be difficult to replicate the create delete 2FA process.
When I upgraded from v3.8.1 to v3.8.2, after my session logged out I found I could not log back in without a 2FA key - but I had no key set.
I checked my db for otp keys and found that otpKey field contained 'totp:'
Reviewing my db before the upgrade the otpKey field also contained 'totp:' and before the upgrading to 3.8.2 I was able to login without 2FA, this indicated to me that the 3.8.2 release made a change to the 2FA process.
So I guess the real issue is that even if otpKey field contains an empty 'totp:' key, the login process still demands an authentication pin response. Perhaps the login process should check the otpKey is a valid key before using it?
hmm I still don't understand where this can come from as i said above there was no change that fixed such kind of behavior (let the totp: there but remove all other code) I'm aware of.
I have created a workaround for the problem here: https://github.com/joomla/joomla-cms/compare/staging...zero-24:workarround_totp?expand=1
But I'm not sure if that is a change we should implement as i don't understand where this issue is comming from.
I would be very happy to hear @mbabker 's opinion on this issue and proposed workaround.
How could that be as this is just another issue? @franz-wohlkoenig
ah, you're right.
Has anyone been able to replicate this?
sure with just letting totp: stand but just with manimulate that in the database. At some place maybe @mbabker can take a look into the Patch linked above:
hmm I still don't understand where this can come from as i said above there was no change that fixed such kind of behavior (let the totp: there but remove all other code) I'm aware of.
I have created a workaround for the problem here: https://github.com/joomla/joomla-cms/compare/staging...zero-24:workarround_totp?expand=1
But I'm not sure if that is a change we should implement as i don't understand where this issue is comming from.I would be very happy to hear @mbabker 's opinion on this issue and proposed workaround.
| Labels |
Added:
J3 Issue
|
||
| Status | Discussion | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-03-11 19:58:19 |
| Closed_By | ⇒ | joomla-cms-bot |
| Status | Closed | ⇒ | Closed - Unconfirmed Report |
| Closed_Date | 2020-03-11 19:58:19 | ⇒ | 2020-03-11 19:58:23 |
| Closed_By | joomla-cms-bot | ⇒ | jwaisner |
Set to "closed" on behalf of @jwaisner by The JTracker Application at issues.joomla.org/joomla-cms/18559
Closing as issue is unable to be replicated unless the database is directly manipulated.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/18559.
hmm i can not reproduce this issue. Here is what i did:
Just to be sure how did you do this?
I can not reproduce this. And i can't remember a recent change regarding this.