Two Factor Authentication

[BradNut]

Title: Feature Request: Add Two-Factor Authentication (2FA) Support

Type: Enhancement
Priority: High

Overview

Yuvomi is functioning excellently as a personal data management application. However, I'd like to propose the addition of two-factor authentication (2FA) support to strengthen account security, particularly for self-hosted deployments.

Problem Statement

Many users, myself included, plan to self-host Yuvomi on infrastructure accessible over the internet (e.g., dedicated VPS instances). While the application works well, the current authentication mechanism relies solely on username/password credentials.

Given the sensitive nature of the data Yuvomi manages—including contact information, daily life events, uploaded documents, medical records, receipts, and other personal information—the absence of 2FA represents a notable security gap that could expose users to unauthorized access risks.

Proposed Solution

Implement two-factor authentication as an optional enhancement, allowing users to enable additional verification beyond passwords. Ideally, this would include support for:

• TOTP-based authenticator apps (e.g., Authy, Google Authenticator)
• Backup/recovery codes for account recovery scenarios
• Optional enforcement at the instance level for self-hosted deployments

Benefits

Aspect	Impact
Security	Significantly reduces risk of credential-based attacks
User Trust	Demonstrates commitment to protecting sensitive personal data
Self-hosting Viability	Makes internet-exposed deployments safer for privacy-conscious users
Competitive Parity	Aligns with security standards expected in similar applications

Additional Context

This feature would be particularly valuable for the self-hosting community, where administrators manage public-facing instances. Even for local deployments, 2FA provides defense-in-depth against compromised credentials.

Questions for Maintainers

1. Is this something you'd consider for the roadmap?
2. Are there any security considerations or constraints I should be aware of?
3. Would the community be interested in contributing to this feature if supported?

[schuster-cb]

@ulsklyc I’d really like to see MFA/2FA support available. Would it be something I could contribute or implement?

Our instance is currently accessible only through NetBird. While this works well, it requires us to manage NetBird access for all family members and ensure the client is running whenever they need access.

Built-in MFA would give us the option to expose the instance publicly while adding a meaningful layer of protection beyond password-only authentication. It would not protect against zero-day vulnerabilities or application-level flaws, but it would significantly reduce the risk of account compromise through leaked, weak, or reused passwords.

For our use case, this would make public access much more practical without having to rely on a VPN overlay for every family member.

[BradNut]

I see this was implements in the latest release! Thank you so much! 🙂

[ulsklyc]

Shipped in v2.37.0. Thanks to both of you - @BradNut for laying out the case so precisely, and @schuster-cb for the offer to build it and for describing a setup that made the priority obvious.

To your three questions, in order.

Is this on the roadmap? It is in, not on. Each member turns on a second factor for themselves under Settings -> Personal -> Account: scan the QR code with any authenticator app, enter the six-digit code once, and keep the ten recovery codes that appear. They are shown exactly once; afterwards the server holds only their hashes. Eight new endpoints under /api/v1/auth/2fa, all described in the OpenAPI document.

Security considerations - the four decisions worth knowing about:

No new dependency, and nothing leaves the machine. There is no environment variable and no network call. A time-based code is an HMAC over a counter, which node:crypto already does, and QR has been a frozen standard since 2000. Both the TOTP arithmetic and the QR encoder are part of the app. That deliberately shifts the burden of proof onto the tests rather than onto an upstream, so they carry the full vector sets from RFC 4226 and RFC 6238, and the QR output is read back by a second, independently written decoder across every length it can produce.

Turning it off asks for a code, not the password. Against a hijacked session only the second factor helps, and accounts that sign in through SSO have no password to prove anything with. Whoever loses their device uses a recovery code instead.

Single sign-on does not skip it. One could argue the provider already authenticated, possibly with a second factor of its own. But a promise that depends on how you signed in is not a promise, and the household-wide requirement below would otherwise bind only those who take the password route.

An admin can require it household-wide under Settings -> Administration -> Family, where the same card also shows who has already set one up - making that call without seeing who it affects would be a blind one. The requirement blocks turning off and puts a notice on every account page without a second factor. It deliberately does not reject sessions that already exist: in a household where nobody has set one up yet, that would lock everyone out, the admin included.

Would the community be interested in contributing? @schuster-cb, yes, and the offer is genuinely appreciated - it is the reason I want to be precise about where this leaves you. Your own assessment was right and I will not oversell past it: this raises the cost of a leaked, weak or reused password. It does nothing against an application-level flaw. So it makes public exposure more defensible, not free - the honest recommendation for a family instance on the open internet is still a reverse proxy you keep patched, and 2FA as the layer behind it rather than instead of it. If NetBird is working for you, the thing 2FA changes is that dropping it is now a considered trade rather than a step down.

@BradNut has already closed this, so this is for the record and for anyone who finds the thread later. If you turn it on and something reads wrong - the enrolment flow, the recovery-code copy, the admin card - open a new discussion and I will take it from there.