Resolved Plesk MFA/Google Auth stopped working on version 18.0.64

[nogray]

Server operating system version

CentOS 7 (Core)

Plesk version and microupdate number

18.0.64 #1

I saw this topic Resolved - Plesk 18.0.61 Login Problem w/ Google Auth/MFA & Cloudflare but it's already marked resolved.

Today is the first time I tried to login after the Plesk was updated to 18.0.64 and Google Authenticator didn't recognize the code. After disabling the extension using SSH, I was able to login. I found the notice it was deprecated and installed MFA.

Trying to setup MFA fails as well and does not recognize the code.
I am logged in using port 8443

 

[Sebahat.hadzhi]

I tested the MFA extension on a CentOS 7.9 server with Authenticator app for Android and I was not able to encounter any issue. At what stage exactly the process fails, please? Do you encounter any error/issue when scanning the QR code from MFA through your local authentication app? If possible, please provide us with step-by-step instructions so we can attempt to reproduce the issue.

 

[nogray]

The error happens when I try to input the code and submit the form. Scanning the QR code and everything else works as expected.

Here are step by step instructions.

• Install MFA extension and open it.
• Check "Enable Multi-factor Authentication"
• Scan the QR code with Google Authenticator app (I am using an iPhone)
• Enter the "Verification Code" from the app in the form
• Press the "OK" button.

Error: CODE is not valid (under the Verification Code field)

The error happened for both Google Authenticator extension (before I un-installed it) and the MFA extension. It also happened to multiple user accounts out of the sudden. I encountered it after I tried to login the code didn't work anymore so I had to disable the extension via SSH. After logging in, I noticed that Plesk auto updated to 18.0.64 around two weeks ago.

I have a suspicion it might be the system time, but we have 2FA in our SSH login (using google authenticator) and it works correctly. So I am not sure what else could cause the issue.

 

[Sebahat.hadzhi]

Thank you for the update. I believe your suggestion about the system time might be correct. Could you please try the following workaround? Although the guide is for Google Authenticator, it is also applicable for the MFA extension.

 

[nogray]

Thank you, the system time was off by one minute. Changing the system time through the Plesk panel fixed the issue and did not effect the SSH 2FA.
P.S. I don't know how to mark the issue as Resolved.

 

[tmuka]

Thanks, this helped me diagnose the same MFA "is not valid" error with the Google Authenticator Extension. I thought it was just the deprecation of that extension in favor of the new "Multi-Factor Authenticator (MFA)" extension, but the issue persisted when trying to switch. Turns out in Ubuntu 22.04.5 LTS the ntp service status was "ntp.service is masked" and wouldn't restart. I ended up installing Plesk's NTP Timesync extension and choosing the "crony (recommended)" option to get time sync'd back up. After that the time was synchronized and MFA worked again! Hope this helps someone else!

 

[trialotto]

Thank you for the update. I believe your suggestion about the system time might be correct. Could you please try the following workaround? Although the guide is for Google Authenticator, it is also applicable for the MFA extension.

@Sebahat.hadzhi

Could you be so kind as to discuss this "issue" internally?

It is an issue from a normal perspective, but it is - also - a bug from a security perspective.

In essence, the MFA extensions (all of them) should be set up by means of an install sequence that starts with time synchronization FIRST.

Otherwise, these MFA extensions are getting installed ...... and Plesk users / admins think that they do not work, but they are active "in the background" and can hence be used by external parties to get into systems (without getting noticed during an interval equal to the time delays) - not a good thing.

A simple remedy would be that time synchronization (or checks related to that) are done first, preceding the installation of MFA extensions.

Kind regards...

 

[Sebahat.hadzhi]

@trialotto , will do, first thing on Tuesday.

 

[Sebahat.hadzhi]

@trialotto , I double-checked the case with our team and it is in fact not possible to configure MFA on the user's device if the server time is not synchronized with the device. Keeping server time synced is very important for correct operation of Plesk server as a whole - logging, correct work with sessions, cookie expiration, TLS certificate validation. It's especially important for MFA as the time-based codes are used. It means, both sides (server and MFA device) every 30 seconds generate new secret value using the current time. If the server's time is off, it may reject a valid code or accept an expired one.

 

[trialotto]

@Sebahat.hadzhi

This statement

Keeping server time synced is very important for correct operation of Plesk server as a whole

is a clear indication that - whenever needed (and that is almost always) - server time synchronization should be checked before installation (as a first step).

This statement

If the server's time is off, it may reject a valid code or accept an expired one.

is true and this is in many ways dangerous.

For instance, if the server time is one hour off, then it is or might be possible to get into a system without getting detected for one hour.

I noticed that this flaw was present in Plesk when - casually - playing around with MFA.

I am not sure, but I think that it is still possible to use "old" codes after a new one has been provided - that is, during a couple of seconds.

There is not much danger in this "behavior", but it might be good to check the code for any hardcoded (time) delays - it can never do harm.

Kind regards...

 

[Sebahat.hadzhi]

Thank you for the update. That's a valid concern. However, based on the extension logic, you shouldn't be able to set up MFA on the client-side device if the time is not properly synchronized. If MFA is already set and unsyncing occurs afterward, the extension does reject codes. If you found a "loophole" and can recall how exactly you performed the tests, I would be happy to attempt to reproduce. Based on a test with Google Authenticator (Android) I performed, the code are being rejected if out of sync (2 seconds) occurs after the initial configuration.

 

[trialotto]

@Sebahat.hadzhi

There are two things to distinguish :

1 - issues related to time delays, with an (authentic) MFA app on the client-side,

and this statement

Based on a test with Google Authenticator (Android) I performed, the code are being rejected if out of sync (2 seconds) occurs after the initial configuration.

addresses those issues.

I found (in the past) that the time delay is not consistent, in the sense that it was 1 second in one test, 10 seconds in another test and so on.

Testing is quite difficult, since time delays can occur for various reasons (on the server- or client-side or MFA-app-side), but the general challenge with testing is that Plesk Panel "remembers" previous MFA authentications and does not require renewals - another vector on the attack surface.

AND

2 - issues related to (false) authentication, mostly (but not always) without MFA apps on the client-side,

and this statement

However, based on the extension logic, you shouldn't be able to set up MFA on the client-side device if the time is not properly synchronized. If MFA is already set and unsyncing occurs afterward, the extension does reject codes.

is related to those issues.

In essence, it is not necessarily required to pass MFA, since there are workarounds that can be simple or quite elaborate.

The client-side device, like Google Authenticator, is designed to make access more difficult - not impossible.

The server-side code, depending on client-side input upon activation, does indeed require "synchronization".

However, the server-side code is not designed to make acces impossible - the same limitations apply to the server-side as they apply to the client-side.

As a simple explanation, imagine how many codes can be generated within a time frame of only 2 seconds - if all can be submitted, then probability certainly will increase that this brute-forcing technique can help gaining access.

As a more elaborate explanation, MFA codes can be intercepted or duplicated - this requires more skill, but even simple tricks will do.

In summary, there are (much) more ways to pass or bypass MFA, but that is another story.


In conclusion, it would be - at least in my humble opinion - a good idea if Plesk MFA is structured in such a way that

1 - MFA requires input of MFA code each and every time one has to log in - this is not the case now,

2 - Plesk closes the gap - any out of sync code should be rejected (not 2s, but zero seconds),

3 - MFA code (value) caching and caching of code underlying the MFA mechanism is completely absent,

and that should be adding some additional safety, in line with the true concept behind MFA.


It is just some food for thought.

Kind regards....