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.
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?
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?
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
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.
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.
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.
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
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.
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".
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.
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.
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.
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 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.
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.
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.
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)?
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.
reply