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 Jan 1 '14 at 10:48
  • 1
    @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 Dec 26 '14 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 Dec 27 '14 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 Dec 28 '14 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 Apr 16 '16 at 11:50
up vote 27 down vote accepted

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 ? – demas Jan 1 '14 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 Jan 1 '14 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/… – Gregory Magarshak Mar 23 at 13:10

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.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.