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.
I really don't like giving out my phone number to a small company with no apparent revenue model, no matter what they are saying they are going to do or not do with that number.
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.
They already answered on these comments with regards to their already functioning revenue model. Banks pay them for securing their sites. They're a YC startup. You're on HN and you're afraid of trying out new technologies because they're offered by new startups?
No. I'm not afraid at all. Indeed I have accounts with most of the projects that are being shown off here. Some paid, some just trials. Some I still use, some I don't. However, I'm very cautious with entrusting my phone number or authentication related applications to a startup.
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.
Cellphone numbers can very easily be abused to steal money (premium SMS), to steal my identity, to spam me in the middle of the night, to pull me out of the "zone" by calling me/messaging me during work hours, to track my location while roaming and probably a lot more stuff that's not currently apparent to me.
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.
It is ridiculous to think that your number is private and even moreso to think that someone can steal money with just your cellphone 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).
It's actually fairly easy in some cases. If the user is with Virgin mobile, their 6 digit password can be bruteforced in a couple of minutes, and then every text and call they've ever made is public. I've made a fuss to them about this quite a few times, but they've never done anything to fix it.
This is a fair point - not the flakiness or otherwise of Authy, but giving out a phone number. I hand it out like confetti, it being, well a phone number. But now it is the key to my google account.
It's not hard to pluck SMS out of the air and sooner rather than later that's going to be a new attack.
A lot of us are familiar with two factor authentication with Google Authenticator. Could you give us a run through of the differences between GA and Authy? What are the advantages of Authy over GA?
Edit: suggestions - do not ask for cellphone number twice. Sending SMS PIN as a link is a bit weird.
> 1. Authy tokens automatically sync even if you lose, change or upgrade phone.
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).
My tokens being sent to an external server that I don't control is a dealbreaker for me, sorry.
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.
>>". 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.
We use Elliptic Diffie Hellman when you are pairing your iPhone to your Mac. The key is stored on both iPhone and Mac KeyChains. Every message between them is encrypted/signed using that key.
I don't know about the internals of Authy, but Bluetooth encrypts by default and so far it has not been shown to be terrible (if you use a sufficiently random key while pairing).
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.
I'm having a tough time understanding all the moving parts involved. Could you post some drawings of what happens in different scenarios? 'cause I'm more of a visual learner.
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.
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 ?
Business Model: We have an API that companies use to add two-factor auth to their sites/infrastructure. We charge for that. see www.authy.com/developer/pricing
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.
Probably. At this point we are testings things out and want to move as fast as possible. We want to make Two-Factor Authentication completely transparent, and we'll be launching other exciting things to see how they work in the real world.
Once we have the experience nailed out, we'll ported to other platforms.
I hope you are planning a Linux release too. So many companies leave us out, even though we're even more willing to work past bugs and set things up correctly.
Worth noting: The Google Authenticator app lets _anyone_ generate a shared secret seed that can be added to the app (which, afaict, does not communicate with the network at all).
I'm confused as to why you'd need a third-party for this.
The Google Authenticator app is great. I recently got (TOTP) 2-factor auth for an IRC bot going with Google Authenticator; took about 5 minutes to code it up and set it up. It doesn't use any sort of 3rd party service, just the application running locally on my phone.
TOTP/HOTP is dead simple and, with the open source Google Authenticator app, great for the end user.
There is one terrible thing which is that adding an account for a different service but with the same email will overwrite any account with the same email without prompting you.
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.
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.
Assuming an attacker has complete control over your computer, and your phone is within bluetooth range, can he make the phone generate a token without user interaction?
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.
Assuming the attacker has complete control over your computer...
... 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.
I've been using Authy for all my accounts that support 2-factor auth for a while now and it's awesome! Google's app is crap and Authy's app is sexy and fast. It really kinda annoys me now when websites don't support 2-factor auth. It's easy enough for them with the Authy API and adds so much for me. More and more I see major websites having their hashed password databases stolen (just search HN). The situation's only getting worse.
I've been using authy for months since it handles 2-factor auth for dnsimple. Just saw the update that supports bluetooth come in on the App Store this morning. Congrats to the team on this big release!
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.
> ... Google seems to have abondoned their Authenticator app
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.
All this nonsense about applications not working on iOS 7 is beginning to grind my gears. Developers aren't currently allowed to submit their apps for iOS 7. The beta is still in early stages. It'll change. A lot. Chances are that if you're complaining about applications not working on iOS 7 you shouldn't have the beta build on your phone in the first place.
A word about the website: The video is really great, enjoyable and fresh (very positive vibe, extremely well executed).
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 long as they don't hold onto your passwords too, then it's not too bad right? A compromise for the sake of convenience, to be sure, but even in the worst case – if all Authy tokens are compromised – people still shouldn't have access to your accounts.
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.
I love the concept of this, but I'm out of the use case for the time being (Windows / Linux user). The other key annoyance is that none of my desktop computers have bluetooth, because I built them for gaming, not wireless peripherals.
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.
I like the design, the website, the phone app, etc.
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."
I've tried to setup Authy using bluetooth, but I failed :(. Mac OSX 10.8 on Macbook Air, iOS 7 on iPhone 4S. It did ask me on the phone to give access for Bluetooth to Authy, which I approved. But On the desktop app there is an empty list of devices and nothing else shows on my phone's screen.
Hi Maver, unfortunately is likely your Mac doesn't have a Bluetooth 4.0 chip and Apple doesn't have an API on the iPhone to talk via 2.0. It will work on an Android though.
It's a 2012 Macbook Air, so it should have Bluetooth 4.0 chip. Any other thoughts?
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.
Possibly silly question, but how do you intend to make money from this?
The mobile app is free, the desktop app is free, and once I have them installed, I don't have any more communication with you or your servers, right?
I've met Daniel and implemented Authy on a web site before. It was super simple, and it's super simple from the user perspective as well. This update makes it even easier. Congrats on this launch!
Is it just copying a totp auth token over bt to the desktop app (which would be most compatible on the backed) or doing something different than totp (hotp or some kind of PK thing)?
I highly recommend Duo Security, the guys behind have a solid track record in the industry. They started it first with phones. Prior to that everyone else was using expensive RSA like secureid tokens that take more to deploy. Read the man page for ssh and you see Dug's name in there. Jon has a solid track record on the mobile side. They just developed Rekey to fix the Android master key vulnerability issue about 2 weeks ago.
We use Duo for various things around here. Love it. It's much more feature complete than Authy (which, unfortunately will not work for any of our use cases).
More importantly, the company is run by well know and respected security researchers (Dug Song and Jon Oberheide).
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: