Authy: One token to rule them all | Hacker News Reader

Authy: One token to rule them all

blog.authy.com

55 pointsdcu63 comments

I may be dense but if you back up the tokens and protect that online backup with a password, don't you eliminate the second factor?

Now the attacker just needs to get two passwords (to the backup at Authy and to whatever account) so it's reduced to just something you (may) know.

Not at all. The attacker would need to get the encryption key and also access to the Authy Backup. Then they also need the password for your account. That said, backups are optional, you can skip them and your account will remain on your phone only.

No they don't need the encryption key just like you don't if you get a new phone. They just need to know your password, send it to Authy, and Authy will decrypt the backup and send it to them.

Edit: I can't reply to the comments on this but they contain the exact procedure an attacker would have to go through, which, if correct, is much more difficult than just knowing the password.

That's not at all how backups work. In order for a hacker to download the and decrypt the account they would need to:

1. Access to your e-mail to click a link confirming you changed your cellphone.

2. Access to your phone # to be able to get the SMS message with the registration key.

3. The encryption key you used.

If they can do all 3 they would get access to your account. If you feel that the level of security there is not good enough for you, you can disable the backups and key will never ever leave your phone

I like how there is a nice catch-22 there ... I may need access to my OTP to gain access to 1, yet I need access to 1 to get access to my OTP.

How are you encrypting the backups? You recommend a passcode of at least 8 characters, which is only 64 bits. Are you at least running it through some sort of key strengthening algorithm like PBKDF2 to generate the actual encryption key?

We're not using PBKDF2. Were using AES-256, we pad the extra bits and use a random IV for each account. However you can enter a 32 character encryption key and you will get a full 256 bit key for encryption.

You know those aren't even the same kind of thing, right?

Ok, please don't take this the wrong way, but you guys don't seem to know enough about security to be running this kind of service. Being able to access your MFA token from multiple devices defeats the purpose of it being a second factor (since it's must exist only in a single place to be "something you have"), and now you're recommending a backup passcode with less security than WPA2 - a passcode to a backup that by definition should not be allowed to exist.

It's bad enough that Google's TOTP keys are too short (80 bits, below the required 128 and recommended 160+), especially given the clarity of the spec and the size of their organization, nevermind being the first large-scale rollout. It's also unfortunate that they half-assed their Authenticator app, which hasn't seen an update in over two years. At least they've had the good sense to improve the workflow of regenerating a token for a new device.

I appreciate the problem you're trying to solve and am aware that there tends to be a lot of headache in additional security, but doing this kind of thing provides a false sense of security if not outright lowering the security of what already existed. If I can get access to my MFA tokens by typing in a password, then it's a knowledge factor and not a possession factor. That's one-factor auth with two passwords, like the "security" questions on many banks.

We were limited by Google Authenticator usage, so yes, backups are absolutely awful, but it was the only way we saw fit in case you had to upgrade/lost your phone.

Now our service Authy and it's Tokens are completely different. If you sign-up to Authy.com and use our Tokens, those are:

1. Full 256 bits secret seeds.

2. They are never backed-up.

3. Guaranteed to only exist on 1 phone at any given time.

4. We not only regenerate new tokens for new device, we also allow 1 click remote reset of the device tokens.

5. We have a huge number of improvements over Google Authenticator.

7. Tokens are not 6 but 7 digits long.

This version added support for legacy Authenticator Tokens. The existing Authy tokens like CloudFlare, DNSimple etc are not limited to the Google Authenticator addon.

You don't access the token from multiple devices, just one(your phone).

Google's secret keys are weak but Authy's ones are 256 bits.

And finally, Daniel was wrong about the key derivation, we are actually using PBKDF2. Sorry for the misunderstanding.

I don't think just having two devices with the same google authenticator seed key is inherently horrible (e.g. my phone and my ipad). It's a security compromise, but not a huge one. I just need to keep both devices physically secure and put a decent passcode on them.

I do this manually when setting up the account, I don't do online backups with a third-party service using their crypto code of my google authenticator seeds, though.

PBKDF2 is a key strengthening algorithm, used to generate a key from a shared secret. AES is a block cipher. I'm not a security expert, but simply padding out the password to the right number of bits seems like a huge no-no. Instead, you should be generating a key of the correct length using something like PBKDF2.

Everything I've learned about encryption, I've learned from cperciva. This presentation in particular might be worth your time: http://www.bsdcan.org/2010/schedule/attachments/135_crypto1h...

Recording: http://blip.tv/fosslc/everything-you-need-to-know-about-cryp...

This in particular: "DO: Avoid using passwords whenever possible. DO: Use a key derivation function to convert passwords into keys as soon as possible. DO: Use PBKDF2 if you want to be buzzword-compliant. DO: Use scrypt if you want to be ≈ 2^8 times more secure against serious attackers."

I was looking at Authy, thinking may it could be part of a solution to a problem I was looking to solve for a customer, but this comment right here shows that you and or your company has absolutely no idea what you are doing with crypto and or how to implement it securely and safely.

:-(

My mistake we are using PBKDF2 already on both iOS and Android.

One of the developers added PBKDF2 while doing the implementation. I didn't know exactly how they had implemented the encryption - so I asked to clarify.

So to be completely clear:

1. We use a 256 bit key derived using a salt and PBKDF2.

2. AES is used in CBC mode with a different IV for each account.

3. The key is store on the cellphone only and is never transmitted

Looks like the someone from Authy is reading this thread so here goes...

Feedback:

* Registration is a bit complex; all texts to my phone (with the exception of the registration code) are completely useless as the real info is sent to my email address

* Why is my backup encryption key in plain text? A dual-password field with sameness-checks would be better.

* Restoring from backup is... painful.

- I cannot just reregister my phone, I have to go through a reset process online. Ok, fine. I got texts to my phone instantly but the reset email took almost 15 minutes to reach me.

- The app crashes tapping any "GA" item other than the first one.

- I have to type in my encryption key for each "GA" item and the app crashes each and every time.

- The first time I tried to restore authy, after typing in my encryption key to recover the first "GA" item, the app crashed and wouldn't let me recover any of the other items... I had to do the whole process all over again.

* Aside from the above, the app looks and works so much better than Google Authenticator on my iPhone (5). Especially considering I'll be able to recover my tokens when switching phones -- Google Authenticator completely screws this up (broken phone? Get a replacement phone from Apple? Upgrade? All your tokens in Google Authenticator are lost, even if you recover from backup).

#1. Agree. Although non-technical people do find them useful. You yourself are just a bit more technical and have a better grasp. Problem is some of our users didn't even know how to install an App etc. We are thinking of ways of making registration easier.

#2. Because you only have to enter it once and it's a complex field, you should see what you are typing.

#3. App shouldn't crash. The reason you have to go through the online process is mostly for security, you wouldn't want it to be just super easy. The other problems seem like bugs.? We'll fix those, can you e-mail me at support@authy.com, i'd like to get repro steps.

#4 Thanks!. Let's get the above fixed.

    All your tokens in Google Authenticator are lost, even
    if you recover from backup

So restoring from an iCloud back-up won't save my bacon in this case?

Nope :/

I've had to do it twice now (once for an upgrade and once for a defective-phone replacement) and both times, after restoring from iCloud, Google Authenticator was empty.

It's not a dealbreaker, but it's still a big inconvenience. I had to use recovery passwords in two locations and convince another to disable two-factor auth so that I could reset it.

If you use Google Authenticator App this is true. If you use Authy App without backups, this is also true. But if you enable Authy Backups then you will always be able to get your accounts back, no matter what.

This isn't true on Android - if you've done a full backup, you can restore Google Authenticator without disabling and re-enabling the service.

This doesn't work the way you think it does. The app itself it's backed up by Android OS, who know were, with every single account without any encryption.

I don't know what you're talking about - the kind of backup I'm talking about isn't a built-in Android feature, as far as I'm aware. There's no "who knows where" - if you back it up, you know where you're putting that backup.

Furthermore, Titanium Backup (and the like) provide you with the option to encrypt your backups.

Finally, Android ICS and later also provides full-disk encryption of the application storage area (which iOS does not).

I'm not sure what you mean on the last point -- iOS user storage is all encrypted with a key inside the device since the 3GS, and meaningfully since the 4S, which is unlocked in hardware whenever you enter your passcode. Everything is actually encrypted (except parts of the kernel, I think, but the bootloader is signed and does signature checks), but there are 4 classes of files, ranging from always encrypted to encrypted just with a key also stored on disk.

No Android devices (as far as I know) have hardware data protection; there is software full-disk encryption, but with that, you can extract the encrypted image and then brute force it at your leisure offline (or in EC2, FPGA cloud, etc.) (the S3 might or might not, but it's not officially supported in the APIs last time I checked)

It's a meaningful distinction because you have to enter passcodes to unlock ~frequently on a small screen, so they tend to be shorter than even screen saver passwords on desktops.

As far as I know, blackberry is still the only mobile OS which does full device encryption with a user key natively with platform security, but the parts of iOS which are not encrypted (some OS parts and the application binaries) aren't particularly security sensitive. It would be better if they had encryption as well -- I'm not sure if there is any protection applied to them for integrity.

I could be wrong; I haven't checked on the details recently, especially on Android, although I need to do so in the next few weeks for a talk at RSA 2013.

I'm still basically amazed at how good a job Apple did on iOS security on the 3GS and later. I wish Google would step their game up and implement NSA SE Android features and some hardware data protection (just buy RIM if you have to!).

I wish it worked that way on iOS; I'm not sure what Google is doing with the app that prevents it ... other apps+accounts work just fine after restoring from backup.

It works without issues for me when doing it locally using iTunes, not sure what would be different about iCloud based backups ...

iCloud backups don't include all keychain items, while iTunes encrypted backups do: https://ssl.apple.com/ipad/business/docs/iOS_Security_May12.... page 12.

Restoring locally from an iTunes account will (at least, the two times that I have done so it worked flawlessly)

I factory reset my iPhone when I got it unlocked, and synced it with iTunes. I had it make a backup before doing so off course, after this iTunes told me it was unlocked, and restored the backup. My tokens continued to exist within the Google Authenticator app, and I was able to log-in/out of gmail without issues.

You better replace your development error pages with proper 404 Take a look at http://blog.authy.com/feed

Thanks!. We're using Blossome, a blog engine I wrote for developers:

https://github.com/danpal/blossome

I've been meaning to add lots of features, I jsut haven't had the time. This holiday vacations I am going to the beach, so I'll be hacking on Blossome there a lot.

Bottom of the error page says "You're seeing this error because you have enabled the show_exceptions setting."

Might want to just turn that off now and hack around with Blossome in-depth later ;)

This is interesting, I've never considered using an alternative app for google 2fa tokens.. mostly because the app Just Works. It's literally one tap and it shows the token I need to type into the website, I'm not sure how it could get any simpler.

Since the authy guys seem to be around, if the only 2fa I have is on my Google accounts, what is the advantage of using Authy over the standard Google Authenticator app (on Android, fwiw)?

Is this "condoned" by Google or does Authy just emulate the algorithm that Google uses? If they are just implementing their own version, then what secret info do they need for the algorithm?

Both Authy and Google are based on open standards:

Specifically: http://tools.ietf.org/html/rfc6238

So you can add support as long as you support the standard.

When you scan the QR Code with you camera we read a secret key and store it inside your phone securely.

Ok that makes sense, thanks.

I'm reading RFC 6238 and it looks like it's based on a single shared secret:

> Basically, the output of the HMAC-SHA-1 calculation is truncated to > obtain user-friendly values: > > HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)) > > where Truncate represents the function that can convert an HMAC-SHA-1 > value into an HOTP value. K and C represent the shared secret and > counter value;

Does that mean it's formally/theoretically equivalent to simply having two separate passwords?

Absolutly not. It's one secret seed but you use the time to generate different One Time Passwords every 10 seconds, which means you never reuse passwords.

This would be the equivalent of having 2 passwords, one of which you change every-time you use it and it's fully random.

So just to rephrase it to make sure I understand, it's more secure because even if the OTP is compromised, the entire system is not compromised, is that correct?

However, if the original secret is compromised (K), then could an attacker easily generate OTPs?

Yes. Just like with a physical RSA hardware token ...

It seems like the algorithm is actually fairly simple, according to the wikipedia page: http://en.wikipedia.org/wiki/Google_Authenticator

It is very simple, as it should be.

There is only one semi-reliable auth method: deep body scan + DNA + mitochondrial RNA + retina scan fuzzy match. Passwords and 2 factor auth suck. And so will embedded/mark IDs, which I will never, ever use.

This is a good idea- everyone worth their salt wants a third-party single auth service, perhaps one that we pay an annual fee for, however this ain't it yet. You should not piggyback. Don't.

Looks like the back button is broken on the Android app. I can't hit the back button and leave the app from the registration Activity.

I don't know if likening yourselves to Sauron will assuage our caution to adopt your tool. :)

Just FYI, the images look terribly stretched on my iPhone

Hm, which iPhone do you have? Is it a 3GS? We use very detailed images etc that just don't look great on non-retina display. Retina images will look great.

Authy, Google, and Dropbox all adhere to the same pre-existing open standard. This just lets you generate different auth keys for different tokens from the same app, instead of having to have multiple native apps (Dropbox, Google Authenticator, etc) to each generate their own key using the same algorithm.

EXACTLY!

Not to discredit Authy here, given they're admirably embracing the open standard, but Google Authenticator happily takes any OTP code.

But their iOS app is 1000x uglier. Swapped my Google Auth credentials into Authy as soon as I realized I had the option.

Seems like a complicated way to turn two factor off while leaking information to yet another 3rd party.

Now if it can import all my RSA key fobs...

What could possibly go wrong when using a device that is connected to the Internet as a 2nd form factor?

That's not just a criticism of this app: all the apps that advertize a device that is connected to the Internet as a "2nd form factor" is using deception to lure people in.

There's no way this is "Two-Factor" in the same way that a physical RSA token is "Two-Factor".

I'm not sure what you mean here. Everything is stored locally, so it's not like it's going off to a website to get your token.

Are you saying that because the device is networked it is by definition vulnerable to hackers and so cannot be a high quality 2FA device?

If so I completely agree, except to point out that if I use a couple of banks (some are better for cards, some are better for savings), and Google and I play WoW and I (insert other service that uses 2FA here) then that's going to be a lot of physical doo-dads I have to keep track of. It's an unfortunate reality, but having all these things attached to one 'smart' device is the only real way of making them viable after you get more than one.

Keep in mind that you're usually expected to enter the OTP generated by the RSA token into the same web browser that sees your password. It just makes it so the attacker has to exploit the stolen credentials right away, instead of storing them for later use.

I think there's some value in that though.

Can someone put a moratorium on startup names that end in "-y" or "-ly"? After a few of these it gets irritating. Maybe the next one will be called "obnoxiously".

Feel free to get started on that. You already have.

Got some downvotes pretty quick. Didn't expect such a negative reaction so fast. I'm relatively new on this site; now I have some idea of how well the HN community takes this kind of humor. So thanks.

Hmmm, I wonder if "downvotely.com" is available ...

I like Authy, but more importantly I simply refused to pay domain squatters for domains.

To be clear my comment was meant to be taken as a joke, not meant to be hostile.

Reply on news.ycombinator.com