[CLOSED] 2FA for accounts

[StorytellerCZ]

Create a new package that would enable 2 Factor Authentication for accounts. As I see it there are 3 that should be implemented in some way:

• e-mail
• phone (SMS)
• authenticator

The idea is that if enabled the login into the account is going to be delayed until a correct code is entered. In basic accounts there should be hooks/methods that account for this and make it easy for apps to implement their own methods. By default there should be provider for e-mail authentication like we see with Meteor Cloud. I would see authentication via phone (SMS) and/or authenticator app (QR code) as a stretch goal as those would have to leave space for implementation of SMS sender provider and the application of QR code for authenticator apps.

So as I see it:

Phase 1 - extend accounts system to support 2FA

Extend the account system for the data needed for 2FA. This would require accounting for and management of the additional DB fields (something like Accounts.add2FAToUser(userId, 'email', options) and remove function). Following that the login function should either return user object on success or some sort of a message to proceed to 2FA part if the user has 2FA enabled. Then have a function that will receive the code, check its validity and if correct log the user in.
Update: As per @denihs suggestion, this should also have backup codes functionality.

Phase 2 - create e-mail 2FA

Create a package for e-mail 2FA. This one would send the code for 2FA to the primary e-mail of the user, using the email package. There should be an editable template available like with the other system e-mails.

Notes and thoughts

• We should also add function to select primary e-mail for user if the user has multiple e-mails
• Another way of 2FA would be to receive approval from authentication app. For example, I try to login on web, the attempt is added to the DB, then my mobile app detects the login request and displays a confirmation menu in the mobile app. Once I approve it in the mobile app it will confirm this to the server which then logs me in. Wise for example uses it, but I think that is bit beyond what I describe here.
• For the e-mail 2FA we should also finish upgrading the email package that would easily allow sending the messages in a custom way, it is partially there, but could be improved.

[filipenevola]

This idea is nice and needed IMO.

I believe we could have this as a community package but we would need a few hooks in the core package for accounts in order to require an extra step in the authentication process.

@denihs could also provide more insights into this as he implemented the 2FA in Meteor Cloud. And Meteor Cloud 2FA is working along side with Meteor Developer accounts so maybe we don't need any new hooks at all.

Maybe we are missing other important aspects here.

[jankapunkt]

@filipenevola I also implemented 2Fa with the NPM otplib package for one project and it used only Meteor Accounts builtins so I think it's already possible with current state of Accounts.

Edit: I would Not introduce a dependency to otplib but I want to say that Accounts ist already capable for several 2Fa Setups. We just need a good Interface that works with many Workflow Implementations

[denihs]

Yeah, maybe for a first version we could use the code that I implemented on Meteor Cloud. Today it just does the authentication by email, but I think it's a start. And I think that from there we already would have the base to the other two methods. These are the functions that I export to use it, so you can get a base:

• generateNewBackupCodes
• cleanAndGenerateNewBackupCodes
• generateSignInCode
• checkAndDiscardCode
• cleanBackupCodes

We even use two email services, postmark, and mandril. So when you request a code for the first time I send the code using one, but when you request it again I send it using the other. Maybe the package should also have this option. If you want I can share the code that implements all these functions... I would just need @filipenevola's approval as it's in a private repo 🙂.

[satyavh]

Great idea, I would even suggest to always enable this to make all (new) Meteor apps more secure by default.

However, I do know a lot of people roll their own auth, so I'm not sure if this should have the highest priority to be picked up. It's not that difficult to do. Could be helpful to check with community first (as not everybody knows how to find this discussion board yet).

[StorytellerCZ]

I think we should keep things simple with the e-mails and just use the email package. The new version will offer features that should make additional customization easy.

[jkasevits]

I would be very much interested in seeing 2FA support added to accounts. The accounts system is a major benefit of Meteor and making it easier to add 2FA into it is a good step forward. Was planning to look into building something on my own, but now will see what happens here.

[harryadel]

A question out of sheer curiosity, if https://github.com/accounts-js/accounts can be integrated in a backwards compatible way would you guys be ok with deprecating Meteor accounts system?

[StorytellerCZ]

I've taken a quick look and I don't think that is possible now without a significant effort. If it was it would be worth a discussion.

[DavidSichau]

I would really like to see support for webauth as an second factor.

I think there are two different ways for making use of webauth depending on the security requirements.

• Use it during login as a second factor (avoid password stealing or pishing attacks).
• Use it to secure the meteor session. (make sure that the user with a valid second factor is actually in front of the computer).

Due to the nature of the webauth protocoll and the currently support by all major browsers in our opinion this is superior to authenticator or email bases second factors.

[DavidSichau]

@StorytellerCZ

Here is our code for some inspiration, we struggled sometimes to get everything working as one needs to pass the correct binary data from client to server and vice versa. Maybe this helps.

methods: https://gist.github.com/DavidSichau/e2c4d2ed52eff34489205546b31471a4
registerClient: https://gist.github.com/DavidSichau/73ae8f69421006a8345357c38e267b0c
loginClient: https://gist.github.com/DavidSichau/625c90cf7e935d3651c8506cbb888cb6
webauthCollection: https://gist.github.com/DavidSichau/b05f77106df6c6e7a409e986ac031d4d

We need arrayBufferBase64 to decode and encode the binary data, as it is currently not possible to send binary data via methods.

[jankapunkt]

as it is currently not possible to send binary data via methods

I thought EJSON supports base64-encoded binary?

[StorytellerCZ]

I've found passkeys today. Later on I find there is also usernameless and other build on top of webauthn, though support for these new options is rather limited:

Still I think we'll have a package that will handle the webauthn api and from that we can have additional packages for all the different options. Playing with it now, though with the passkeys I run into problem that they are not supported on Ubuntu and the Typescript libraries that are listed require at least Node 16 or 19, so I'll have to pass on those so I will try to get at least a bit of hardware keys done.

[rj-david]

@StorytellerCZ, with Ubuntu, you can do the following related to passkeys/webauthn

1. Chrome supports development webauthn credentials through dev tools
2. You can use Chrome 108+ and an android phone. You only need to be logged in to the same Google account. I stopped using my yubikey and now used my phone as my "hardware key"

On a related news, windows 11 update last september 26 now supports cross-device passkeys. All major OS: android, ios/macos, and windows now support cross-device passkeys.

But yes, the node 14 limitation is an issue. We are using an old version of simplewebauthn just because of node 14

[StorytellerCZ]

Saw this today: https://oslo.js.org/

[filipenevola]

Hi, the new package 2fa-accounts is already available in beta.

You can understand how it works in this preview of the docs.

Also, let's centralize the feedback in the PR for 2.6.1.