MFA Enrollment

[patrykczubek]

Bug report

Describe the bug

Using the MFA enroll function, the table gets spammed with new unverified factors on website refresh.

Expected behavior

If the user doesn't have the MFA enrollment started, it should work like how it does as of now. However, if there's already a enrollment process started before by the user, it should reuse the existing QR code.

Screenshots

[J0]

Hey @patrykczubek,

Thanks for the feedback! This is a good suggestion - as an immediate fix it should be possible to add a state variable in React to ensure it's only called once on the enrollment page. We'll look into the docs/lib to see if there's a better way to handle this

[tomekit]

On our side every time MFA enrolment starts, we delete all unverified factors to avoid the mess in the table and avoid exceeding maximum allowed MFAs.

Perhaps Supabase could cleanup unverified factors after some inactivity time. I don't see what's the point of having unverified factor sitting for a longer than couple minutes (unless there is some MFA workflow which is longer than that).

There is also a config param, specifying how many MFA factors user can have (default 10). I believe this setting shouldn't apply for unverified factors, because currently user can easily "lock themself" out without an option to create a new MFA.

I think reusing QR codes poses some security risks. Once QR code disappear from the screen it should never be displayed again, but that's only my opinion.

[J0]

Hey @tomekit,

Thanks for the feedback! It's helpful in deciding what to prioritize. We're planning on adding a background task of sorts to clean up unverified factors after an interval.

There is also a config param, specifying how many MFA factors user can have (default 10). I believe this setting shouldn't apply for unverified factors, because currently user can easily "lock themself" out without an option to create a new MFA.

This is also a great suggestion, the fix will probably go out with the background task mentioned above.

I think reusing QR codes poses some security risks.

Yes, this is a good point, I'd forgot to consider this and perhaps the proper fix here should be to amend the DX around registering a factors

Please do keep the feedback coming!

[bearbricknik]

Hi, have you found a solution to the problem yet? I have the same problem and cant figure out a solution that is working reliably without increasing the mac mfa limit to an absurd number but then still the user is able to log himself out

The only idea I had was setting triggers that might delete unverified mfa factors from the table after a period of time.

[J0]

Hey @bearbricknik ,

Thanks for reporting the issue you're facing! Quick question about:

cant figure out a solution that is working reliably without increasing the mac mfa limit to an absurd number but then still the user is able to log himself out

Are you primarily facing the issue of hitting the max mfa limit in development or in production? We have an existing cleanup after a factor is verified but am floating the idea of adding a cleanup at two other areas:

1. Every 24h - all unverified factors will be cleaned up
2. During enroll - all stale factors (older than five minutes, no challenges made)

This won't solve the issue of hitting max enrolled factors during development though since I guess dev might make quite a few invocations during 24h. Trying to understand the issue better before attempting to resolve that.

Lmk!

[bearbricknik]

Hello and thank you for reaching out to me. I am not primarily facing issues with hitting the max limits, however I found out that unverified tokens get stored there for a pretty long time without the actual „need“ to (as far as I can see). I made a custom solution to that for now where whenever the user starts the process to enroll a new MFA factors, its basically looping through all the unverified ones and unenrolls them first before showing a new QR code. In this way you will end up always with verified ones in the database. Your ideas are also quite good. Thank you for listening.

…

Am 19.01.2024 um 17:45 schrieb Joel Lee ***@***.***>: Hey @bearbricknik <https://github.com/bearbricknik> , Thanks for reporting the issue you're facing! Quick question about: cant figure out a solution that is working reliably without increasing the mac mfa limit to an absurd number but then still the user is able to log himself out Are you primarily facing the issue of hitting the max mfa limit in development or in production? We have an existing cleanup after a factor is verified but am floating the idea of adding a cleanup at two other areas: Every 24h - all unverified factors will be cleaned up During enroll - all stale factors (older than five minutes, no challenges made) This won't solve the issue of hitting max enrolled factors during development though since I guess dev might make quite a few invocations during 24h. Trying to understand the issue better before attempting to resolve that. Lmk! — Reply to this email directly, view it on GitHub <#979 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7JSOMIILALOVHXHAG5N3GTYPII7FAVCNFSM6AAAAAAVAXSGIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZHA2TKMJQGE>. You are receiving this because you were mentioned.

[Wamy-Dev]

I have encountered this issue during development due to refreshes. A fix for this would be awesome.

[laurencebedford]

Same here I am now getting from the server:
{"code":403,"msg":"Enrolled factors exceed allowed limit, unenroll to continue"}

how do I fix this? - if I get this error delete the factors? im confused since the docs doesn't cover this case:
https://supabase.com/docs/guides/auth/auth-mfa#apis

[J0]

Hi you can probably call unenroll on the factors. If needed you can do select id from auth.mfa_factors where status='unverified'

I'll also bump the linked PR for review today - lmk if there are other issues

[bearbricknik]

To give you guys an idea how I did it: Everytime a user enrolls a new factor, I am calling the DB and check for any unverified ones. If there are any, I call the unenroll on every single unverified one before enrolling a new one.

To be clear, its probably not an ideal solution but a little loop over the unverified ones does the job before enrolling a new one.

Hope that helps you.

[laurencebedford]

To give you guys an idea how I did it: Everytime a user enrolls a new factor, I am calling the DB and check for any unverified ones. If there are any, I call the unenroll on every single unverified one before enrolling a new one.

To be clear, its probably not an ideal solution but a little loop over the unverified ones does the job before enrolling a new one.

Hope that helps you.

thats what I was planning on doing. However, it just seems rather botched and what if a user uses this maliciously to just repeatedly refresh the page - resulting on hundreds of unenrolls / enrolls?

[kangmingtay]

i'm closing this issue since it seems to be resolved by #1371 - please feel free to reopen it if there are still any issues