google-authenticator VS two-factor-auth

otpauth:// is a de-factor standard, since Google Authenticator uses it: https://github.com/google/google-authenticator/wiki/Key-Uri-...

Random question if you're using TOTP why not just give the user the secret when signing up as a Google Authenticator URI encoded in a QR code? Then you won't need to futz around with sending it to them afterwards. You can even use a library like qrcode.js so you don't generate the barcode server side either.

Locker can generate Time Based OTP codes parsing TOTP urls stored under a special key named totp.

(Examples> https://github.com/google/google-authenticator/wiki/Key-Uri-Format)

If we're talking about the encrypted Authy TOTP secrets and IF they get cracked or guessed, Authy does store the email in the name of the item. Having the name, service and the secret within the QR code's URI is normal and the standard for TOTP. The only thing the hackers won't have is the password.

It's really easy to integrate into websites as well. I did so a few years ago. The TOTP algorithm is just a few lines of code. I adapted this implementation https://github.com/j256/two-factor-auth at the time. There are similar libraries available for lots of languages.

You need a library like that and a way to convert an otp:// url into a QR code, for which there are many libaries as well. The rest is just implementing a sane UX around this. Storing the user's TOTP secret server side is a bit tricky. I suspect a plain text field in a database is quite common for this; which of course would be disastrous if that database were ever stolen. Secret stores don't scale for this as they tend to be designed for just a handful of secrets. We ended up encrypting these totp secrets using a key from our secret store.