Add 2FA to the phx.gen.auth generator

[RobinBoers]

Hi! I’ve been working on adding 2FA to the phx.gen.auth generator and wondered whether I could maybe contribute my changes back to the upstream. I already posted about it on the Elixir forum a few weeks back, but I didn't get much feedback there.

My fork currently has:

• Scannable QR code on the settings page (can be used with any authenticator app).
• Codes can only be used once (as required by the spec).
• Checks account for differences in time between devices and slow typing, by also allowing 30 secs before and after expiration.

Feedback is greatly appreciated! I’m looking for feedback on code quality, proper style and security. In particular, I have a few questions:

• Is the way the User module currently uses the Accounts module okay?
• I’m manually Base64 {en,de}coding the secret before storing it using Ecto. Is there a better way to do this?
• Is the way I’ve implemented this secure? To me it seems pretty solid, but I’m not a security expert.
• I noticed the hashing library in the generator is dynamic. Is it desirable to also make the TOTP and QR-code generator libraries dynamic like that?

I haven't written any tests yet, but am willing to do that if it's required to get it merged.

Edit:

Here's a demo repo generated like this:

cd installer
mix phx.new dev_app --dev
cd dev_app
mix phx.gen.auth Accounts User users

Edit 2

@dvic said I should post screenshots, so here's a few:

[janwillemvd]

Nice work @RobinBoers!

[wtcross]

Great work. I think it would be best to make this feature optional and disabled by default. It would be nice to have a flag (ex: --with-totp) on the phx.gen.auth task.

[wtcross]

One more bit of feedback. TOTP is probably what most people want, but HOTP is valid in a lot of scenarios. I'd use "totp" in file names and references to the implementation instead of "second-factor". This great code you have written could be one of many factors (not just 2nd).

[wtcross]

If this PR is not accepted into Phoenix (I think it's a good idea to accept it) my suggestion would be to make this its own repo. I suspect it would still see adoption and it doesn't seem very tightly coupled with the rest of the phx.gen.auth code.

[mughees936]

This is awesome! I was actually about to start working on something similar myself, so it’s great to see you've already put on some good work. I’d love to help out if I can!

Just a few quick thoughts on your questions:

• User module using Accounts seems like a good idea to keep the logic in the Accounts context. It keeps things clean and fits the Phoenix pattern, so I’d say stick with that.

• What you're doing for encoding/decoding Base64 makes sense! One suggestion though—you could create a custom Ecto type to handle the Base64 encoding/decoding automatically, just to keep things neat and avoid manual handling.

• Sticking to one solid library for now is probably the best approach unless there’s a strong use case for more flexibility.

I’d be happy to pitch in. Let me know if I can help—this would be a cool feature to get merged!

[RobinBoers]

Thanks for the feedback guys! I've renamed all references to second_factor, otp and 2fa, to totp, as you suggested. I also moved the base64 {en,de}coding to a custom Ecto type (I couldn't find an existing implementation, so I wrote my own).

I fully agree that this should be behind a feature flag, but I first wanted to know if the 2FA implementation was wanted and whether it was technically sound. It might take me a while to figure out how to add it, because the phx.gen.auth generator is pretty complicated. Probably somewhere next week.

@mughees936 Thanks for the offer! I'll let you know if I need help with something.

[ponychicken]

Since passkeys are now quickly getting adopted in a variety of browser, I'm wondering if that would not be the more future proof approach...

[RobinBoers]

Took a bit longer than expected, but I moved everything behind a feature flag. I couldn't figure out how to add a CLI argument, so it's only a prompt right now. Next would be tests I think, but I'm not very good at writing those. Help appreciated!

[shiroyasha]

@RobinBoers wow, this is awesome! I was just looking around for a solution to add 2fa to our app and people from ElixirForums sent me this way. This could be just what we need.

Do you need any extra help testing it out, or feedback about usage? I'm happy to help out in any way.

[RobinBoers]

Hi @shiroyasha, feedback and help is greatly appreciated! I'd love to get this merged. I think the most important thing is to get some basic tests, but I haven't had time to actually write those. Other than that, I'm happy to hear whether it works for you!

Edit: I see now that I have a few merge conflicts, I'll get around to fixing those later today.

Edit again: sorry, it took a little longer!

[stevegrossi]

Thanks for your work on this! I've used this code as a template to add 2FA to an app generated with phx.gen.auth and it works perfectly. One potential issue you may want to consider is LiveView 1.0's migration from phx-feedback-for to Phoenix.Component.used_input?.

After making the changes to CoreComponents recommended by the LiveView 1.0 migration guide I no longer get error feedback (the red text below the input) for invalid TOTP codes on this settings form when enabling or disabling 2FA.

phx.gen.auth had this same problem with error feedback for current_password on this page and recommends solving it by adding a virtual current_password field to the schema and casting it. I've not been able to make that work with the @totp_changeset's code but will report back here if I do.

[greven]

I think this is something really useful to have as a base in phx.gen.auth, at least as an option in the generator, since this is pretty much almost standard nowadays.

Now, I would maybe wait for the PR for this issue (#6041) and rebase on top of that work?