Authy: Faster Two-Factor Authentication
authy.com
authy.com
Specifically, an anonymous unsigned cipher is being allowed, and a victim browser can probably be forced to use it by an attacker. From http://www.ietf.org/rfc/rfc4492.txt:
Note that the anonymous key exchange algorithm does not provide
authentication of the server or the client. Like other anonymous TLS
key exchanges, it is subject to man-in-the-middle attacks.
Implementations of this algorithm SHOULD provide authentication by
other means.Sorry for being cynical, but judging from all these services coming and going all over the place, any of the following is going to happen within a year: 1) authy gets bought by $COMPANY. With some likelihood it's not a company I want to have my phone number. 2) authy runs out of money and needs a revenue stream. Thus it changes the TOS and starts selling phone numbers. 3) authy shuts down. Who knows what's going to happen with my phone number then.
No. I'd rather use any other HOTP app that doesn't require any personal data (which is one of the basic ideas behind HOTP).
Authentication and my phone number are the two things you have to really prove you have got your act together before I trust you with them.
Never quite understood the HN fetishism about keeping emails and phone numbers private. I hand them out like candy and haven't felt a price for it.
Also, my phone number is known to some identity providers I trust. If they sent me an SMS asking me to click a link, I might be inclined to follow that link. This is quite right despite the sender being very easily spoofable because nobody but these identity providers know my phone number.
No. I'd rather be very careful with that number.
Of course you could be phished or tricked by SMS but to expect your number to be private is to expect everyone ever who you give the number to go to extreme to keep it private as well.
If you ever gave your number to someone who downloaded an app which has permission to contacts your number is no longer private (Facebook has taken big advantage of this, I'm sure there are less than reliable apps that took bigger advantage).
That's all I said. I'm not saying nobody should trust them. I'm not saying they aren't trustworthy in general.
I just said that I don't trust them with my phone number (or gmail HOTP secret for that matter).
Especially in matters of authentication services that require more private information than what's strictly needed leave a bad taste in my mouth.
It's not hard to pluck SMS out of the air and sooner rather than later that's going to be a new attack.
Great one more thing to worry about.
Anyway, you can read more about why we did this here: http://blog.authy.com/thefuture
This looks awesome.
When could we expect a Windows 7/8 app ?
Congrats
Once we have the experience nailed out, we'll ported to other platforms.
Just a quick question, under security it says:
>>". Authy Bluetooth will only talk to pre-approved computers and all messages are encrypted."
Just wondering if you can speak to what sort of encryption and safeguards you've got going on here. The docs cover how the tokens are created, but not the communication between phone and mac.
Seems like an awesome thing but I wouldn't feel comfortable using it for work without knowing a bit more.
So even if Authy does nothing special to send the data encrypted, BT itself will ensure that it's safe. Minus, of course, some malware that's running and inspecting the application in-memory or just watching the clipboard, but no encryption on earth will help you there.
Edit: suggestions - do not ask for cellphone number twice. Sending SMS PIN as a link is a bit weird.
But in general terms:
1. Authy tokens automatically sync even if you lose, change or upgrade phone.
2. Ability to do encrypted backups of Google Auth tokens. Same as above, they will sync if you lose, change or upgrade phone.
3. Bluetooth: Takes the hassle out of Two-Factor Auth.
4. Automatic time sync: Always makes sure your tokens work no matter what.
5. Key Rotation: We can automatically rotate keys if masters are compromised.
6. Privacy: WE DO NOT TRACK app usage or anything like it. We don't share data with anyone. Compare it to GAuth privacy policy.
So the tokens are stored on Authy's servers? Doesn't that defeat the purpose of two-factor? How do I (or an attacker) recover my tokens if I loose my phone?
Personally, I'd be concerned with trusting my credentials with any company unless all members of the leadership team (yes, including "nontech" people) are incredibly familiar with basic security terminology and practices.
(Note that the founder is unclear when PBKDF2 and AES are being used in the product, which is concerning, because they have very different use cases and should be hard to confuse).
I get the convenience factor, but my security relies on the absolute secrecy and control of those tokens; I'm not willing to trust those to anyone else. Any company that requires 2FA is likely to have a similar policy; leaking the keys to the kingdom to a third party which is not subject to security audits is going to be a non-starter.
Bluetooth integration is a compelling feature, though.
1. What is your business model ? The app looks great and I wouldn't want to see it go away in a couple of months.
2. There is a registration process that ties the app to my phone and there seem to be a recovery process. Does it mean that the secrets are stored on your servers ? If yes, what prevents you or one of your employees to gain access to the secret keys ?
2. The recovery process enables your phone. If you decided to enable backups(which is optional) encrypted versions of you accounts are stored in our servers (that's why it called backups). Authy employees can't gain access because only encrypted version is stored, you chose the encryption key and have to remember it.
We believe that the future of Two-Factor Auth is one were our devices will do the work for us in order to provide us a greater and simpler security.
From what I can tell, the user navigates to a site previously provisioned with Authy, they choose to authenticate via Authy, and then ??? happens resulting in their cell phone giving them a time-limited one-time passphrase.
I'm confused as to why you'd need a third-party for this.
Example of how to generate a seed and share it with an ssh server: https://scottlinux.com/2013/06/02/use-google-authenticator-f...
TOTP/HOTP is dead simple and, with the open source Google Authenticator app, great for the end user.
e.g. setting up 2-factor with MS with the same email you use for Google will overwrite the Google one unless you rename it.
The Authy app is better.
Look at the screenshots at https://itunes.apple.com/us/app/google-authenticator/id38849... . The buttons are ugly, labels are misaligned, and the colors are ghastly.
Re-ordering tokens in the Google Authenticator app is janky as hell too, and the only way you'll know if it's going to work is if the regular view switches to one with subtly different font sizes.
Authy's not without its rough edges, but it never looks that bad.
From down-thread, regarding Google Authenticator: e.g. setting up 2-factor with MS with the same email you use for Google will overwrite the Google one unless you rename it.
Authy does this correctly.
system_profiler -detailLevel full SPBluetoothDataType | grep "LMP Version"
Sure would be nice if they mentioned that anywhere at all.
I was assuming the user would have to click a button on the phone or something, but I couldn't see it in the video.
... the end user just lost, absent substantially more defense-in-depth on the provider side than just using TFA. TFA mostly helps you against "We lost credentials or a low-privilege session, let's prevent that from escalating to a high-privilege session." If your device is rooted, you'll eventually cough up a high-privilege session, either by passive monitoring or by something more clever like e.g. using your own computer as the MITM to ask you to provide a valid TFA to do something which really only requires a low-privilege session. Now the attacker has both factors. Game set match.
He can steal your cookies, keylog your password/token, poison your dns and compromise your SSL Keys or simply steal a session.
One thing that's nice about seeing a modern two-factor auth app with a solid business model behind it, is that Google seems to have abondoned their Authenticator app - no releases since 2011, doesn't yet work properly on iOS 7.
What exactly would you like improved in Google Authenticator? It's not like it does anything special, it just scans TOTP QR codes and generates TOTP codes, and it does both of those pretty well.
I actually like the fact that it has no additional functionality. Everything stays on the device itself and is not sent to Google or saved "to the cloud"[1]. The only thing I think that would be an improvement would be for it fit the entire iPhone 5 screen (it's letter boxed) but that doesn't really bother me that much.
[1]: I've heard it gets backed up to iCloud but I don't use that.
But I'd rather see something different than a (blurry) image of the founder looking somewhere off screen. I mean it's "personal", I get it - but this can be improved. While this might sound superficial, it's the first thing that came to my mind ...
As an end user, I don't want to touch your app with a 10ft pole since you're an untrusted/unvetted source holding on to some very important tokens.
For me at least (personal use, not company use) that's a worthwhile compromise: I doubt any attacker could get my main password in the time it'd take for me to change it in the unlikely event that Authy be compromised.
That being said, you probably already thought about using a centralized server or other methods of communication. Either it'll kill battery, or require some intermediary server - which would probably need two-factor authentication to authenticate.
Though, overall, I love this idea a lot more than backing up my Google Authenticator app with Titanium Backup and restoring it each time I change phones/ROMs.
USB based bluetooth dongles are dirt cheap, so this should not be an expensive or otherwise overly inconvenient issue to resolve.
Edit: According to this document iPhone 4 support all Bluetooth profiles: http://support.apple.com/kb/ht3647
However, the desktop app does not feel right. Maybe I am missing something.
- Are the HMAC keys stored or synced to the desktop?
- Is there a password protection similar to the keychain to access these passwords?
If my desktop is hacked into and a key logger has my password as they usually do, it will now also be able to copy these one time passwords at will and use it frequently to log into my account.
I would prefer to use my laptop and a separate phone for my OTPs. I like the Google Authenticator app as it does nothing more than generate OTPs, no sync to server, etc..
"- Are the HMAC keys stored or synced to the desktop? No, nothing is stored in the desktop. Everything remains on your phone."
"- Is there a password protection similar to the keychain to access these passwords? We store the pair phone details on the keychain. But this is only the phone bluetooth id etc."
"If my desktop is hacked into and a key logger has my password as they usually do, it will now also be able to copy these one time passwords at will and use it frequently to log into my account."
No, again nothing is stored on your computer.
Edit: For the reference - I went to Authy support chat room, and it seems that even though I have a 2012 Mac, system profiler says that I have LMP version 4, which means Bluetooth 2.1. That's why it doesn't work. The support was top notch though.
Another question: If for some reason, your company shut down tomorrow morning, what would that mean for users of your app? Would it stop working?
A real "something you have" in a 2 factor auth. would be a real token that has provisions to wipe itself on detecting it's being opened.
Watched in Chrome though, great stuff! Looking forward to trying it out.
More importantly, the company is run by well know and respected security researchers (Dug Song and Jon Oberheide).