Let's talk about 2FA and TOTP (Google Authenticator, Twilio Authy, etc) 🧵1/14

2FA stands for "Two Factor Authentication", that is, using two ways to authenticate yourself to a service. For example passwords is "Something you know", your cellphone is "Something you have". There is also "Something you are" (Biometrics). 2/14

Some people will tell you there is also "Somewhere you are" (Location-based authentication). This is not so simple to implement, though, so let's stick to "Something you know/have/are" 3/14

TOTP stands for "Time-Based One-Time Password Algorithm", and is derived from HOTP. Both defined at RFC 6238 and RFC 4226 https://datatracker.ietf.org/doc/html/rfc6238 https://datatracker.ietf.org/doc/html/rfc4226. 4/14

How it works? The service creates a secret and passes it to you, generally in the form of a QR code. Both have then a "shared secret". What you do when you want to authenticate is showing to the service that you HAVE this secret. 5/14

To protect this secret from prying eyes, what you and the service do, each at their side, is 1. taking this shared secret + the current timestamp 2. produce a hash, 3. truncate the hash to N digits, 4. you send the digits and the service compares it to what it's got. 6/14

Just repeating the cast above: 1. Get the secret and timestamp 2. Hash them together, 3. Truncate, 4. Send and compare. Profit 7/14

This TOTP auth factor ("Something you have" i.e. the shared secret within your device) together with your password ("Something you know") enhances the security of your authentication. So far, so good. Right? 8/14

For you to demonstrate that you have this secret, you and your service need to perform a computation everytime the challenge is issued. Meaning your service needs to have your secret available, generally in plaintext, in a DB. With all the security controls this requires. 10/14

In other words, your service is storing this secret into a DB, the same way is storing your password. 🤔 11/14

About transmission of the secret to the user: This is generally transmitted in plaintext or a QR code. The latter will just give your secret into plaintext as well. Usually protecting the data in transit with HTTPS would suffice. 12/14

And then, we have the storing of the secret into your device. You want to take the same measures you do with any device taking care of a secret key: Encrypted storage, have your backup available, and avoid non-controlled cloud copies of your secret around. 13/14

No doubt is always better to have more factors of authentication than just one! It is healthy, however, to be aware of the alternatives. Explore ways to authenticate that don't rely on centralized sources 😉 14/14

Let's break down this system in three parts: The storage of the shared secret by the service, the transmission of the shared secret to the user, and the storage of this secret into the user's device. 9/14