What really bugs me is that TOTP is objectively easier than any other form of 2fa. Just import the library, add the field on your login form, and you’re done.
Email verification is annoying to code, it requires SMTP or an email gateway, is slow for the user, is risky from a security perspective, and to generate the code you probably still have to implement TOTP.
SMS/RCS is even more annoying to code, it almost inevitably requires a third-party gateway, it can work differently if the user is in a different country or on a MVNO or in a low-signal area or just has the wrong astrological sign, is very slow for the end user, is almost useless from a security perspective, and you STILL have to implement TOTP.
WhatsApp messages are somehow even more annoying to code than that, requires an api interaction with Meta (which is never fun and poorly documented), requires the end user to have an account with a specific third party, is slow for the end user, relies on another company’s security posture to determine your own, and you STILL have to implement TOTP.
Making your own app for 2fa is undoubtedly the worst: not only is it annoying to code, it’s an ongoing annoyance that is strained through multiple app stores, adds an additional maintenance and support load, adds additional technical debt, adds an unnecessary attack vector, requires users to download another app, is often unreliable, is often pretty slow for the end user, is a total crapshoot from a security perspective, and guess what? YOU PROBABLY STILL HAVE TO IMPLEMENT TOTP.
Any company that chooses SMS or email verification over TOTP emphatically does not know what they’re doing.
2fa by email is probably slightly easier than TOTP, if the account verification via email is already implemented, but yeah, it’s not like it’s significantly easier…
You don’t have to implement totp for these alternatives… The “thing” about totp is that there’s a shared secret and a timestamp. Due to potential drift in clocks you need a window and period to know how many time steps to test, and how long each is.
But with an email/SMS/WhatsApp, there’s no shared secret. So you can simply send a random code, and store server side when it was generated. Totp makes no sense in that case.
Not that totp is difficult to implement at all. My implementation for work was what, less than 200 lines of C++ I think? I didn’t implement the sha1 myself though.
An earlier version of that comment said “something like TOTP,” but I guess I left that out while I was revising it. My point is you have to implement something that does most of what TOTP does anyway, so why not just use the version that’s already been stress tested?
What really bugs me is that TOTP is objectively easier than any other form of 2fa. Just import the library, add the field on your login form, and you’re done.
Any company that chooses SMS or email verification over TOTP emphatically does not know what they’re doing.
2fa by email is probably slightly easier than TOTP, if the account verification via email is already implemented, but yeah, it’s not like it’s significantly easier…
That is a fair point. But again, you probably have to implement TOTP or something like it anyway, to generate the code.
You don’t have to implement totp for these alternatives… The “thing” about totp is that there’s a shared secret and a timestamp. Due to potential drift in clocks you need a window and period to know how many time steps to test, and how long each is.
But with an email/SMS/WhatsApp, there’s no shared secret. So you can simply send a random code, and store server side when it was generated. Totp makes no sense in that case.
Not that totp is difficult to implement at all. My implementation for work was what, less than 200 lines of C++ I think? I didn’t implement the sha1 myself though.
An earlier version of that comment said “something like TOTP,” but I guess I left that out while I was revising it. My point is you have to implement something that does most of what TOTP does anyway, so why not just use the version that’s already been stress tested?