Two-Factor Authentication

[jasonm1]

I see no straightforward way to implement two-factor authentication (2FA) in Parse Server. Ideally this would allow:

• 2FA using one or more methods (Google authenticator, SMS, email)
• Device memory (with periodic expiration) so users don't necessarily need to enter the second factor all the time
• Any particular user to have 2FA enabled/disabled optionally

I initially started implementing this in my client-side code (PHP) for my Administrator users using Goole Authenticator, but then I realized anyone with the AppID and the Admin password can simply write their own code to get around it. Oops.

I then thought about storing a second factor, or possibly an IP whitelist, and rejecting any requests in beforeSave, beforeDelete, or beforeFind Cloud Code where the client did not provide the second factor, but that seems clunky. It is also difficult to rate-limit, since the malicious user would be able to log in and only be blocked at the point of accessing data. Further, I believe the second factor would need to be stored apart from the User object itself, since once logged in, the user can access its own data.

@flovilmart suggested using a 3rd party Auth adapter, for example Google, which could potentially work in my case since I only care about the extra security for certain users. However, I don't want to require Google login for everyone, which means native username/password login is still available. Checking triggers in Cloud Code for the particular users could be a workaround, but again, the user would be checked at the point of accessing data, not logging in. I also don't know if this solution would generalize to others' use cases.

One solution I see is to add a beforeLogin trigger in Cloud code. A routine in this trigger could check the second factor (stored with the user object) and reject the Login if it does not match or is not provided. This would also allow for IP whitelisting for certain users (reject login attempts from non-listed IPs) or any variety of custom authentication methods.

Another may be to have per-user control over the authentication method. For example, if a user can login with Google, the user can ONLY login with Google, and not username/password.

I am not familiar enough with how Parse Server handles logins to know if the beforeLogin trigger is feasible, or if some other 2FA system would be easier to implement.

[flovilmart]

We could probably bake 2FA in, with QRcode generation, and secure login/sessions. This would be a major feature where users could opt-in for 2FA. That would be quite a major development touching a few areas of the API, but that wouldn’t be anything unachievable

[jasonm1]

What do you think of the beforeLogin trigger solution? I noticed a discussion on that a few days ago but it didn't end up addressing the suggestion.

[flovilmart]

That would be kind of messy as tou’ll Need to store each user’s secret anyway, enforce etc.. that could help you, but i’d Like that to be baked in :)

[jasonm1]

I like the sound of a native 2FA solution as well! I will try to start looking into a first stab at this soon.

[montymxb]

Just bumping this, I think this would be 💯 % awesome to put this in. If I were to just brainstorm off the top of my head this is what comes to mind.

• Default adapter for 2FA, allowing other services to be added if they pop up
• optional twoFactorEnabled on _User to track whether or not this is even an option
• twoFactorSecret for this user (if the above is set), could screen this field away from querying since it's a bit sensitive.
• add some routes to UsersRouter.js like enableTwoFactor to get a QRCode/token, disableTwoFactor to remove it and verifyTwoFactor to actually run the check. Could be spread out further or consolidated into one endpoint though.
• Upon login, if twoFactorEnabled is true request that the user proceed to submit their second factor code, again this could go separately to something like verifyTwoFactor, maybe taking the username and code. The session upon login, but pending 2fa, would have to be available to the user, but locked to any further action.
• If validation succeeds clear the block and allow the user normal access with their session token.

As for blocking requests when pending 2fa, the primary concern is in making sure that until the user can authenticate themselves they should not be granted access as themselves. Since we have ACLs, this, in a nutshell, means we need to treat them like they're anonymous and subjected to the restrictions of public read/write. There are a number of ways this could be done, but I'm wondering if maybe not returning the user on successful login with 2fa enabled would be the easiest. Instead we could return something to indicate that further authentication is required.

That's a pretty rough outline, and it doesn't elaborate on how the SDKs would go about handling this, but it would be a start in the right direction 👍 .

[flovilmart]

That would be at session token emission level, when enabling 2FA, all sessions would be destroyed, the 2FA logIn flow could force having an additional ‘code’ property alongside username/email + password, I dot believe there’s a need for a temporary state (valid username + pass) waiting for ussename + password. Also, providing username + code only should work instead of username + password ?

[flovilmart]

Perhaps providing the 2FA code in je password field would be ok-ish, not sure...

[montymxb]

The username and the code combined would have to be something separate, but it would use some stage so you can't just jump to it unless you've already logged in.

The thought of having 2FA directly with the username and password did occur to me as well. Normally it's requested separately, but honestly I can't think of a good reason why it's not requested up front. If we did, we just authorize on an all or none basis, either it matches password and the 2F code or it fails. That could make it a lot easier to do this, no extraneous 'stage' or 'steps' required (beyond the step of validating the 2F token itself).

[montymxb]

The thing above would have to be something like login and then validateTwoFactor being the second required step, if it were separate that is.

The only issue with having the password and two factor go together is when your 2nd factor is something like a static code that's generated upon successful login. You wouldn't be able to get your code to login with until you had successfully logged in in the first place. If we did an adapter to allow extra 2FA methods that could screw things up if someone did something like an SMS or email code.

[flovilmart]

To enable2FA you usually have to provide the generate code to guarantee he user has property setup his account, so no chance to get locked out. Maybe an endpoint /enable2FA that takes the sessionToken (you need to be loggedin) and the 2FA code, if you fail to provide a valid code, your account stays 1FA secured, upon success, the sessionToken gets regenerated, and 2FA is enforced

[montymxb]

Yep, for setting it up the user would have to successfully provide the proper 2F code at least once before it can be enabled. Could split that up into something like requestEnableTwoFactor and enableTwoFactor. The first endpoint taking the current sessionToken and returning anything necessary to setup 2FA on their second factor. The second endpoint taking the expected 2F token from that user and enabling it on success!

We would need to save and track that a user is in a state of:

• enabling two factor (turning it on)
• pending two factor (normal authentication)

Maybe could add a step for disabling two factor if we want to keep it strict.

[mnlbox]

@flovilmart, @jasonm1, @montymxb
Any news about this?
Is it possible to do this with cloud code?
If yes, did you provide some example app or blog post about this?

[flovilmart]

We haven’t worked on it, it’s still up for grabs