2FAuth is now available

[lukas]

@timconsidine mobile

[timconsidine]

@lukas I think I recall not currently because they don’t see a need for one being browser.
But anyone please do correct me.
But a mobile app could be built to wrap the page but I think Apple and Google resist such apps. I’ll try to research.

[fbartels]

@timconsidine it is rather Apple that is resisting here, even going as far as almost removing support for pwas https://open-web-advocacy.org/blog/apple-backs-off-killing-web-apps/

[murgero]

@timconsidine This likely has a PWA you can install to your phone on Android you just open it in chrome and select install web app from the three dot menu.

On iOS you open it in safari, and bookmark -> Add to home screen to install the PWA.

[AmbroiseUnly]

Great! I see it's currently marked as "Unstable", I'll wait for a stable version, but definitely interested in this (I also need to migrate from Authy...)

[scooke]

My question might be similar to an above poster, but how does an web account know that I am using this and not Authy or Google ? When I register the site with my self-hosted (Cloudron hosted) 2FAuth, (how) does the website know that only 2FAuth will be issuing the 2fa's?

[Kubernetes]

@scooke When you set up two-factor authentication (2FA) for a website using a specific authenticator app, such as Authy or Google Authenticator, the website generates a unique secret key that is shared securely between the website and the authenticator app. This secret key is used to generate the one-time codes that you enter when logging in.

If you are using a self-hosted 2FA solution on Cloudron, the website follows a similar process. When you set up 2FA with your self-hosted 2FA solution, the website provides you with a unique secret key that is used by your self-hosted 2FA solution to generate the one-time codes.

The website does not necessarily know which specific authenticator app or method you are using to generate the 2FA codes. Instead, it relies on the secret key that is securely shared between the website and your chosen 2FA method to verify the code you enter during the login process. As long as the code generated by your self-hosted 2FA solution matches the expected code based on the shared secret key, the website will authenticate you successfully.

In summary, the website identifies you based on the secret key provided during the 2FA setup process, regardless of the specific 2FA method or app you use to generate the codes.

[murgero]

I know @Kubernetes gave a really thought out response but for anyone that isn't technical the gist is this:

TOTP (Time-based One Time Password) is a way to generate a 6 digit number based on the current time.
For example if the time is 12:30PM the code could be 123-456 and at 12:31 it could be 987-654. (This is a lose example)

The app itself follows a set algorithm which uses a secret key that only the app and the website know. This is algorithm is the same across ALL TOTP based apps (Examples are Google/Microsoft Authenticator, Authy, & 2FAuth). The same algorithm is used to verify the 6 digit code on the website as well.

Using TOTP, the website doesn't care what app you use, so long as the clock on your device where the app is installed is correct and the secret key matches so the 6 digit code works.

All of the above is the same no matter what app, website, or hosting service you do or do not use.

[scooke]

Thank you for the answer. Does this then explain why, after I had bought a new phone and tried to login to Twitter, then realized I had to "connect" Twitter back with Google Auth, and it wouldn't work on the new phone, it was already connected to the old phone. And that phone had died, so I had no way to ever verify on Twitter. I'd like to avoid that.

( I eventually did log back in by finding an even older phone that somehow miraculously was still logged into Twitter, and from within some option deep within it's bowels I could find something like an emergency login code, and that worked on the new phone, from which I turned off 2FA so that I could redo it on the new phone.)

[Kubernetes]

@scooke Yes, your experience with Twitter and Google Authenticator highlights a common issue with 2FA when switching to a new device. In your case, since your old phone with Google Authenticator had died and you were unable to access the codes to verify your identity on Twitter, you were locked out of your account.

This is one reason why a App like 2FAuth might be useful.

[lukas]

Hm, I changed my password and now I can't login because I'm already logged-in? But I'm not
And it seems that long passwords like 64 characters are not accepted

[nebulon]

@lukas said in 2FAuth is now available:

Hm, I changed my password and now I can't login because I'm already logged-in? But I'm not
And it seems that long passwords like 64 characters are not accepted

Probably a good thing to report upstream then.

[lukas]

@nebulon said in 2FAuth is now available:

Probably a good thing to report upstream then.

Where I can report it?

[jdaviescoates]

@lukas said in 2FAuth is now available:

Where I can report it?

Search on here https://github.com/Bubka/2FAuth/issues and if there isn't a similar issue, add it there.

[sponch]

that a web only thing or can it be synced with the mobile client?

[murgero]

@sponch TOTP can be used on any device or site that supports it. Just need the right app. In this case, 2FAuth is a web app that can be used for storing your TOTP codes in the cloud.

[scooke]

@lukas Good thing you have this set up on Cloudron then! Just restore to a backup before the password change and keep on rollin'!

[RazielKanos]

I moved all my 2FA to bitwarden

[girish]

@girish said in 2FAuth is now available:

The registration flow is a bit glitchy. We have reported this upstream at https://github.com/Bubka/2FAuth/discussions/313

The upstream author has fixed this and it works very well now!