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.
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
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.
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.
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 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.
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...
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."
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.
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
* 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).
#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 email@example.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
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.
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).
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'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.
Might want to just turn that off now and hack around with Blossome in-depth later ;)
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)?
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.
> 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?
This would be the equivalent of having 2 passwords, one of which you change every-time you use it and it's fully random.
However, if the original secret is compromised (K), then could an attacker easily generate OTPs?
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.
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".
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.
I think there's some value in that though.