[Defender Pro]: 2 Factor Authentication | Front-End Setup process

Hello.

I just realized that when 2 factor authentication is enabled for users then all the wp users are redirected upon login to the back-end that really is a security flaw and a loophole which defeats the whole idea of preventing users that has not authenticated by 2 factor authentication to login to your system in the first place: and especially preventing hackers and other bad people from logging in.

Also end-users has no business in your back-end and that is also a secure risk because that exposes what system you as a company are running and why should you give away that information for free, right?

So what I am suggesting is this:

Once you setup 2 Factor Authentication for all users, they are not redirected to the back-end anymore. Instead; once they use their user credentials they are only half logged in and are presented with a required setup wizard on the front-end which request that they setup 2 Factor Authentication right here and now. (They cannot get past this front end screen as this a mandatory user setup process:wink:. On that Screen is the link to google-authenticator.com and a QR code that they need to scan. Once they have setup and finalized this process they are now presented with the 2 Factor Authentication screen and can now login.

This approach is much more safe and will prevent people that have no rights to your system to login, but also stops people to procrastinate with setting up the 2 Factor Authentication.

By the way; I just got an additional idea regarding all the users that fails at setting up the 2 factor Authentication process:

What about adding a cleanup process that if the user after XYZ amount of days/1 month has not setup his/her 2 Factor Authentication from the front-end and successfully logged-in then “Defender” automatically removed and deleted these non valuable/spam accounts?

That would be an addition great feature and also make your system more safe, secure, cleaner with a leaner database too, and who would not want that right?

So that’s all for this time!

@WPMU-DEV-Community: If you like my idea then +1 it!

Kind regards

PowerQuest

  • Adam Czajczyk
    • Support Gorilla

    Hi PowerQuest

    I hope you’re well today and thank you for sharing these ideas!

    I’m not sure how you got 2FA configured but if you’re “forcing” to all users, that shouldn’t really pose much of any security issue as users that didn’t fully configured it yet are only able to access their profile page in back-end where they can set 2FA. They can’t access any other part of back-end.

    However, I do understand how it might raise security concerns and also I totally agree that it would just be easier and simpler for users to “not have to go to back-end”. I think too that it’d be great to have entire 2FA setup on front!

    I’ve already passed both these ideas (moving 2FA configuration and deleting accounts) to our Defender team for further consideration.

    Best regards,

    Adam

  • PowerQuest
    • Syntax Hero

    Thanks Adam Czajczyk :smiley:

    Well they are logged into the back-end aren’t they?

    (More than half-way)

    Hackers are some very clever bad people and if they have the foot more than half-way through the door they will get the rest of it too.

    Also exposing the back-end to random people isn’t a good idea and revealing what kind of system that you’re company is running, the same reason same goes for employees that may for whatever reason when they leave retaliate back because they have become upset about for example being fired or whatever reason they might have to justify their malicious actions, so why give that information away to them?

    So yes actually, it still a large potential security risk. :smirk:

    Kind regards

    PowerQuest

  • Adam Czajczyk
    • Support Gorilla

    Hi PowerQuest

    Thanks for response! It’s always great to get to know some other point of view to one’s own so I’m happy you shared that feedback with me :slight_smile:

    Since I passed that already to our Defender team, I’ll keep my fingers crossed for implementation then (I didn’t get any feedback from them yet but I’ll update you here when I get it).

    Best regards,

    Adam

  • PowerQuest
    • Syntax Hero

    Hi Adam Czajczyk :smiley:

    I just came to think of one an additional idea……

    How about also being able to enable/disable 2 factor authentication per site in WPMU and just network wise for all websites?

    For example:

    In my case we use custom login interface (https://white-label-login.righthere.com/) which comes shipped with 2 factor authentication too, and Defender 2 factor authentication renders the login interface useless actually; so you cannot login with Defender 2 factor authentication on the certain websites we use the login interface..

    So it would in my opinion make sense to allow this functionally in Defender. it would me the product even better! :thumbsup::smirk:

    I’m sure many others have this situation too as they use custom login interfaces and not the standard WP one and that would make people’s lifes much more easier.

    Kind regards

    PowerQuest.

  • Adam Czajczyk
    • Support Gorilla

    Hi PowerQuest

    “Instinctively” it would seem that being able to e.g. disable 2FA on some sub-sites kind of “defeats” entire purpose of the feature and creates security hole but yes – I can see the point here and that’s perfectly understandable (and probably not that uncommon) case example. I’ve already passed that over to our Defender team for further consideration :slight_smile:

    Best regards,

    Adam

  • Adam Czajczyk
    • Support Gorilla

    Hi PowerQuest

    Well, “yes and no”.

    We’re discussion options still as our developers actually raised similar concerns as I did about that if 2FA would be disabled on one sub-site, it would create security breach because it would actually mean a way to “bypass” 2FA entirely.

    Of course you’re right that this would only be true if no other tool/module is providing 2FA on such sub-site instead. If there’d be 2FA provided by other plugin or a theme on such sub-site – all would be fine. But it’s actually that – you know that and we know that but not everyone does and if there’s an option to disable 2FA for some sites only, there’s a chance that it might be disabled in many cases without providing any alternative – and without realizing that it actually opens up access.

    So, to sum it up: “options” are under discussion as if we provide that, we need to make sure that either it’s made crystal clear what’s the risk and that an alternative must be provided or somehow detect if there’s alternative solution implemented.

    Best regards,

    Adam

  • PowerQuest
    • Syntax Hero

    Hi Adam Czajczyk

    I hope you’re having a lovely day. :smiley:

    Quote:

    As our developers actually raised similar concerns as I did about that if 2FA would be disabled on one sub-site, it would create security breach

    I do agree on this one, as it does create a sort of “pseudo security breach” if:

    1.) The product (Defender), doesn’t have the correct approach, (Example: Warns the end-user, requires another solution turned on etc)

    2.) The novice end-user (Which has no clue about IT etc), disables it whithout understanding what they are doing.

    3.) The end-user just disables it for a site and is reckless to do so without enabling a login module such as White Label Login, (https://white-label-login.righthere.com) with 2 Factor Authentication.

    Quote:

    But it’s actually that – you know that and we know that but not everyone does and if there’s an option to disable 2FA for some sites only, there’s a chance that it might be disabled in many cases without providing any alternative – and without realizing that it actually opens up access.

    Well… :thinking:

    Doesn’t that boil down to that we’re supposedly adults and we’re all have 100% responsibility for our actions and as a software manufacturer such as WPMU DEV and it isn’t per see the manufacturer liability to monitor and govern the end-users action as a “surveillance big brother”?

    We have to rely on and expect that users of Defender is self-aware/bright enough (Not trying to offend anyone.. ), to make sure that they take the correct measurements so Defender is used as intended in correct, properly manner to ensure maximum security, right?

    Please do correct me If I am wrong in my last statement above, but that is my personal conviction as company you cannot be liable for people misusing your product in such way that it wasn’t intended to and such as it is their headache if lightning strikes. All you can do is to educate the end-users about how the product works and should be used, (and give them amazing customer service), but stops there in my opinion.

    What’s next after that is up the user, correct?

    Now some ideas and suggestions to implementation: :smirk:

    Quote:

    We need to make sure that either it’s made crystal clear what’s the risk and that an alternative must be provided or somehow detect if there’s alternative solution implemented.

    Right so.. Agreed! :thumbsup:

    1.) If the user disables FA2 in the system there should be some “big fat” warning telling them about the risk, followed by a additional warning saying “are your sure you want to do this?” – Maybe even in the last warning a little text window to confirm your actions like you have to type: “I confirm to disable FA2”. That would prevent that someone by sheer mistake would disable it by freak mouse click etc. Maybe even prevent a outside hacker from disable it too? (not sure about the last part, but anyways).

    2.) How about a interface option where you could have 2 options?

    Option A: Force FA2 on the whole WPMU network including all sub-sites. Maybe even password protect that option? (Not sure if that is possible)

    Option B: Disable FA2 on certain selected sub-sites, again followed maybe by password protection option? (I would suggest that it would be mandatory though)..

    Having some sort of password protection overall to protect that setting would make much sense anywyays. Maybe even support products such as YubiKey (https://www.yubico.com) and LastPass (https://www.lastpass.com) (LastPass can be configured to require Ubikey, Sesame, fingerprint readers, Transakt, Microsoft Authenticator, Google Authenticator, Duo Security and many more etc) to enhance the security even further.

    3.) I do agree that it would be the best option would be that Defender would be able to first allow disabling a sub-sites FA2 protection first at the point where it detects that there is a substitute FSA solution such as “White Label Login for WordPress” that is configured and enabled with FA2. First at this point would Defender allow that the site using Defender FA2 be disabled. Maybe this could be done through a wizard, step by step? So if Defender would maybe support the major vendors of login modules (Shipped with F2A obviously), then that would work very well.

    4.) If the Substitute FA” solution is disabled for whatever reason, then Defender would (by monitoring if it is up and running or not), step in and (either or both) warn the user/automatically enable FA2 on that sub-site so it is protected until the substitute is properly enabled again and protecting that sub- site.

    5.) An additional step in preserving and strengthening the security could be that as a last step to either deactivate Defender FA2 or as part of enable the substitute FA2 (Or even disable both.. :scream:slight_smile:, that there is sent one final email and warning to the system admin where there is also a confirmation link that you need to click on to confirm these actions.

    6.) The idea I mentioned above in the start. To improve security have Defender automatically clean up and remove users that doesn’t have FA2 enabled (For whatever reason there may be; failed signed ups, etc), after XYZ time period. This will improve the security too.

    7.) Some additional thoughts/feedback:

    By allowing the subject of this tread (Allow sub-sites to disable FA2 and enable a substitute)

    , it will strongly and ironically I would argue greatly improve the security for the site owners of WPMU systems and improve Defender. The reason are as simple as some of these “login modules” that you can buy/download and install on your system will actually circumvent Defender’s FA2 and rending it useless, making it less secure. Hence there is a security hole and the argument by not allowing this action is less valid in my opinion. Defender as product and the end-user would be better off with allowing this for the reason above; that some products out there can circumvent the Defender FA2 once installed.

    So that’s all for now from me… :smirk:

    Hopefully You might be able to use my ideas/feedback on this. :slight_smile:

    Kind regards

    PowerQuest

  • PowerQuest
    • Syntax Hero

    Hi Adam Czajczyk .

    So I’m currently in a chat with Aditya from your team and I realized there is another thing that could be improved in Defender. Basically he is trying to login to an account that a Sohag has has configured the F2A on it so now it is locked to him and the support account is now locked to him…
    So me and Aditya attempted to find in the account profile the setting to reset FA2 both on network level and site level; both main site and the sub site. But nope, no luck.

    (Hmm by way… This suggestion ticket is getting pretty deep in security of Defender, maybe we should set it to private to not reveal too much to the outside world?) :thinking:

    So my though is this:
    How about there was an option to for the super admin to be able to force a users F2A connection with Google Authenticator?

    Meaning that the user is forced to re-authenticate his/her FA2…

    Again this could be a password protected setting that the super admin needs to enter a password to access this part. (Or by any other authentication solution like Ubikey, fingerkey reader or whatever etc).

    The main point here is that there no option to reset a user in the system as of now. Which is kinda needed. if a user for example loses his cell phone, then it will be impossible to help that user regaining his access to the website and will be forced to create a new account, which potentially could mean a lost user… Because they will be annoyed about losing their account etc.

    Kind regards
    PowerQuest

  • Adam Czajczyk
    • Support Gorilla

    Hi PowerQuest

    That’s a lot of interesting feedback :slight_smile: Thank you for that! Let me, however, pass this “as is’ to our Defender team as while I can see the point here, I feel like at this level we’re going a bit beyond my area of expertise. I think it’ll be best if our developers will just read that on their own :slight_smile:

    On a side note though: there are actually some interesting improvements (that, I think, would be in line of what we were discussing here) already being consider and/or worked on – providing some more auth “types” (not only via Google Authenticator), adding additional white/black listing/reseting options… There’s also some internal discussion going on about YubiKey and similar hardware solutions :slight_smile:

    Best regards,
    Adam

  • PowerQuest
    • Syntax Hero

    Thanks Adam Czajczyk :smirk:

    That is interesting to hear that they are discussing that. Personally I have a weak point for LastPass which in enhances the general security of password management itself:
    https://www.lastpass.com/products/enterprise-password-management-and-sso
    https://www.lastpass.com/products/multifactor-authentication
    by making your management of passwords for your company very secure. Your can even share with your team or externally with a supplier/external developer and they will never even know the login credentials as they are hidden from them, but can use them until you remove the access with a mouse click.

    Pretty awesome stuff! :tada:

    Is this thread still public by the way?

    Kind regards
    PowerQuest

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.