That will not really work, as the lifetime of the TOTP can be too narrow for such unreliable messaging system like SMS.
hauleth
John-Goff
I’ve never implemented such a system myself so you’re probably right, but I know that I can get a text message with a 2fa code from basically every provider who offers 2fa, so there must be a way to do that.
0
hauleth
It probably uses exactly what OP is trying to do - generate token that have some timeout and is assigned to your account. Now you just send message and wait for a code. The problem with using TOTP is that these have (by default) have 30s lifetime, and using the same secret with different lifetimes can cause problems AFAIK. Of course you could generate several secrets and then just use different when trying different auth method (with different lifetimes).
0
WestKeys
Pretty sure NimbleTOTP and TOTP in general requires authenticator app, and can’t support SMS workflow. The verification code is actually generated by the authenticator app itself, based on the secret provided to it by, in this case, NimbleTOTP.
I may be wrong. All ears.
0
WestKeys
I’m building a chat app. Imagine the onboarding friction of having to download a 2nd app for 95% of users.
I do agree though that TOTP is cheaper, easier and much more secure.
0
hauleth
If that is corporate, then screw all that and force SAML/LDAP/OpenID/other centralised corporate authentication system. Also many password managers already support TOTP generators (for example 1password does) and some corporations require usage of such.
If it is “civil” user facing, then it can be a little bit irritating, but maybe email would be easier in such environment instead of SMS (I assume that login is email-based, if it is phone-based, then SMS probably make more sense).
2
thinkingcat
Do we also store the secrets from the TOTP algorithm in the same table or separate? Thanks!!
EDIT: just found this and it suggests that we would store it in a separate table:
super helpful reference in case anyone else needs it!
1