I thought I knew how two-factor authentication works:

  • I enter the password.
  • Server generates a random number (token) and sends it to me via SMS.
  • I enter this token.
  • Server checks that the token I entered matches the one generated for my earlier 2FA request.

But today, I discovered Authy, and it looks like I don't know how this program's two-factor authentication (2FA) works.

Authy shows me secret numbers (2FA tokens) without any connection with the server. How can this be?

I suppose these tokens are not random? Maybe it is some kind of a number sequence, where knowing initial seeding parameters makes this a deterministic process? Maybe this sequence is a function of time? Is that how it works?

Is it secure? Can I, for example, determine next 2FA tokens, if I know a N number of previous tokens?

  • 3
    Irrelevant of Authy (I am not familiar), your statement of understanding of two factor authentication is pretty mistaken. To begin with, SMS is not two factor, but it is out of band verification. Needs moar magik crypto dust.
    – AviD
    Commented Jan 1, 2014 at 10:48
  • 2
    @AviD actually, password + SMS verification is 2-factor auth. The password is 'what you know', and the SMS is 'what you have', since you must have the phone that receives it. The thing is, if Authy syncs to a server, isn't it transforming the 'what you have' part into 'what you know' (since you don't need your phone anymore if you know the password to authy), thus ending up with two 'know' factors, which kinda kills the whole point of 2-factor auth?
    – tetsuo
    Commented Dec 26, 2014 at 5:20
  • @tetsuo that's what I was saying - SMS can never be a 2nd factor (at least not the "something you have" part), since that's not how SMS really works - you don't actually have to have the designated phone to receive it. Your explanation of Authy just proves this... Or anyway, it would be a pretty poor implementation of "something you have" if you do try it...
    – AviD
    Commented Dec 27, 2014 at 22:51
  • Well, I 'own' my phone number. Of course it would be possible to hijack my line, but this would require a targeted attack - more analoguous to stealing the device itself - in contrast to stealing passwords, which is fairly easy to do in a 'setup a trap and wait for random prey' (specially from non-techies). The Google Auth app illustrates the 'something I have' case is more concrete. I have an app in my phone, that uses a secret key that I don't know, and that only exists in this device. Thus, I must have it. But if this secret key is stored in the cloud, I just have to know the password.
    – tetsuo
    Commented Dec 28, 2014 at 6:16
  • 1
    Your shortest question is the best one: "Is it Secure?" - that's easy. No. This (11 years old!) article by the industry's' most respected expert explains why OTP like Authy is useless (has been for 21+ years now): The Failure of Two-Factor Authentication (schneier.com/blog/archives/2005/03/the_failure_of.html)
    – cnd
    Commented Apr 16, 2016 at 11:50

2 Answers 2


Authy show me secret numbers without any connection with server. How can it do it ?

Authy is using a one-time passcode (OTP) algorithm which come in a number of flavors, the two most popular being HMAC-based OTP (HOTP) and Time-based OTP (TOTP). Authy is using TOTP.

Both algorithms are essentially the same; they require some seed data and a counter to generate the next passcode in the series. HOTP implementations increment the counter each time the user requests/uses a passcode, TOTP increments the counter after a given time interval.

In Authy's case, when the user submits a passcode to the server, the server looks up the user's seed data, calculates the counter value based on the timestamp of the request and then generates the proper passcode. The server then checks that the generated passcode matches the user-submitted passcode.

Is it secure ? Can I know next number if I know N previous numbers ?

Yes and no, it depends on whether or not you trust the server's security.

Given N previous tokens an attacker still shouldn't be able to recover the seed data. However, these algorithms require the server to store the seed data for all of the users. If an attacker is able to compromise the database (through SQL injection, etc.) then they will be able to generate valid passcodes. This is what happened to RSA and their SecurID tokens (http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-compromised/)

Some companies like Duo Security (https://www.duosecurity.com/) and Twitter (https://blog.twitter.com/2013/login-verification-on-twitter-for-iphone-and-android) are tackling this issue by implementing challenge-response two-factor authentication with asymmetric key encryption. They only need to store public keys in this case, meaning that if their database is leaked an attacker doesn't have the private keys necessary to generate valid responses.

Disclaimer, I worked at Duo.

Updated based on questions in the comments

The algorithms (HOTP or TOTP) must be the same on the server and the client application?

The algorithm is identical, just the way the counter value is generated is different. If Google were HOTP and Authy wanted to support Google accounts, their app would have to generate and store the counter value differently from TOTP accounts.

Does HOTP client require connection with server to get next passcode (because it doesn't know how much requests was made from last time), while TOTP doesn't require it?

No, HOTP doesn't require a connection to work, but HOTP is generally not used because it's easy for the phone and server to fall out of sync.

Say both the server and app start out with a counter value of 0. The server usually has a window, maybe the next 10 passcodes, that it will consider valid. When the user submits a passcode, the server will compare the submitted passcode with the next 10 generated passcodes. If any of the 10 match, the server can update the stored counter value and remain in sync.

The problem though, is that the user may be able to generate too many passcodes in the app without using them. If the user is able to increment the counter beyond the passcode window size, then the server can no longer verify that the passcodes are valid.

To see in detail how the OTP tokens are generated, see this informative blogpost.

  • Thanks for your answer! 1. The algorithms (HOTP or TOTP) must be the same on the server and the client application? For example, is it impossible that Google use HOTP on the server, but Authy use TOTP on iPhone, right? 2. Does HOTP client require connection with server to get next passcode (because it doesn't know how much requests was made from last time), while TOTP doesn't require it ?
    – ceth
    Commented Jan 1, 2014 at 10:56
  • 1
    No problem, my response was a bit too long for a comment, so I've updated the answer to include your follow up questions, cheers!
    – JackWink
    Commented Jan 1, 2014 at 16:06
  • Hey all! Is anything from this parented, or can I implement the same thing in my app without a license? Asking here as well: patents.stackexchange.com/questions/19326/… Commented Mar 23, 2018 at 13:10
  • @JackWink why doesn’t Authy do it the other way, so it doesn’t have to trust any servers and share any secret keys? I wrote it up here: crypto.stackexchange.com/questions/71695/… Commented Jul 1, 2019 at 18:41

It looks like it communicates using a simple REST API. In terms of how secure the tokens are -

The token is generated using a 1 way function (SHA-2) and a 256 Bits key. Even if the attacker had access to hundreds of Tokens, it would still be mathematically impossible for him to generate a new valid Token. If you are inclined to know more, Authy is based on RFC4426 ( http://www.ietf.org/rfc/rfc4226.txt ).

In short - Yes it uses a secure method to generate a token.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .