danielpal

The + means at the plan we you can buy more auth's granularly. So you can buy 5000 more auth's if you need or users too. Prices depend on volume.

#1. We wish. We use around 14 different cellphone # to bypass Spam etc on SMS. Most people don't understand how hard is to reliably send SMS internationally (twilio makes it look easy in the US :))

2. Auth's are times you call the verify/token API. Since it's an API you can decide when exactly when to call it. Most our clients authenticate tokens every 14 - 30 days. So people can authentication to your app via username - password or cookies and then sometimes via username - password - token. We only count an Auth when they do username - password - token.

1. There is a window of tokens valid at any given time, its called: look-ahead synchronization window size (http://www.ietf.org/rfc/rfc4226.txt)

2. The synced time value should also be encrypted and authenticated.

No exactly what you are thinking. Time is transfered using https, so it's encrypted by that protocol, not our own.

3. Yes there is a slight delay, but see look-ahead synchronization window.

4. 2. If my phone doesn't have Internet connections, the code is only refreshed in ~5s.

No. The code is refreshed same way as if it had internet connection. It's just we used previous information on how your device clock works to make educated guesses on synchronization.

5. When the server wants to verify the received code it will check whether it matches with the codes generated in 0s, 5s, 10s, 15s and 20s.

Yeah something very similar to this.

Read the RFC, we follow it very closely:

http://www.ietf.org/rfc/rfc4226.txt

We don't transfer any resources over HTTP on www.authy.com, we even use HSTS on www.authy.com.

Demo is over http because it's not meant to be a secure site, only something you use to see how it works. Database is destroyed daily, but I agree we should change it to https.

It is based solely on time. The reason we refresh the time as you screen off and on is so that you always have 20 seconds ( I hate it when I open google authenticator and I have to wait for it to refresh).

We do some complex things to make sure time is always synced in the background. If you are in airplane mode obviously we can't contact the server. But if you do have connection, contact our server in the background and sync it. We also store the delta of how much was your time desynchronize so that next time you are in airplane mode we can do a good guess of how much your time might be off by, and then we use that. We don't expose this to the user, it should just "WORK"

Passwords are useful, but impossible to enforce. If anyone decides not to use the passwords for their key you are in the same spot. You need better tools, something you can enforce server side. We use two-factor: (note that I founded Authy) http://blog.authy.com/two-factor-ssh-in-thirty-seconds

Thanks!!! This is beyond awesome.

Anyone know's how Evernote develops their multi-platform App? Do they just write from scratch for each platform or do they have some framework in between?

I bought SnapHeal a few weeks back, but is nothing like an inexpensive photoshop alternative. Photoshop is extremely powerful, snapheal feels extremely underpowered. In fact I used snapheal in a few photos, with such terrible results that I deleted the app. My experience certainly didn't match the results that the app screenshots showed, even after spending hours trying to do so.

Yeah we'll release a PAM module soon so you can do this. If you don't want to wait, you could write one. Just look at this module, it's fairly simple. The API is really straight forward.

We make it really easy for anyone to use 2FA. The reason 2FA is not popular is not because there aren't enough solutions out there, it's because all of them are basically really hard to use. Specially those that claim to be easy, they are the opposite.

The basic reason is because we don't use passwords. We always use public/private certificates on all of our machines. With PAM you have to use passwords. We'll release a version soon that works with PAM, but I recommend you switch to using authorized_keys with certificates. Not only is it much more secure, it's also much nicer to use.

Not at all. We understand PAM and we plan to release a version that works with PAM. But we don't like passwords, we much rather use public/private ssh keys instead of users with passwords. It's not only much better user experience but is also much more secure.

Yeah but in reality no-one writes it down. I actually use Google-Auth for my Gmail, but I forgot were I wrote this number down(it was a couple of years ago). Keeping a scratch code for each new server is a pain.

The biggest problems is you can't use ssh_keys with this setup. Its too restrictive, and certificates are a must for ssh.

Also what happens if you loose your cellphone? We thought about this and for us the possibility of loosing access to the server fully was too much.

You are right. Best for your infrastructure is to fork it and modify it. We for example have a different version we use for chef and that already include everyone's keys.

No, when you add a new user you don't need to restart. Only restart the server when you install the plugin.

I'd love to buy, but this flash site is just not working.

Two-factor makes more sense. Relying on your database never getting hacked is nonsense. Is not a matter of are you getting hacked but when are you going to get hacked... expect getting hacked.

(disclaimer: I am the founder of Authy.com a two-factor auth API)

"You will notice there is one dot way out on the boundaries of the distribution in each chart. It turns out this dot represents the same accelerator each time, Y-Combinator. Indeed, Christiansen himself points out that Y-Combinator is an outlier."

I do. Have you ever just bought something on Amazon because it's just easier? Wouldn't you buy at Startbucks instead of seattle best coffee if it were "easier"?

A lot of the tokens(Google Auth included) follow http://www.ietf.org/rfc/rfc4226.txt. Problem is everyone has a different way of provisioning the secure key. Some of which are unsafe (I am looking at you Google Authenticator!. Yes a qrcode is kool idea but theres no guarantee that you are the only one who provisions the key using the image.)

I designed Authy with that in mind. I wanted a way to have a 1 token for all accounts. Maybe we will add support for Google Authenticator, so you could import your Google Auth token into the app.

Although enabling two-factor auth in gmail is great, I still fail to see how it would have protected his iCloud account. Sure his gmail account wouldn't have been compromised, but what about his his iCloud and twitter?. Why doesn't apple and twitter provide two-factor authentication? Why doesn't everyone do it this days?

I hear you. I designed authy so that 1 token would work accross sites for this same reason.

Unfortunately its not technically possible for us to allow you to install RSA, Google in our App, as that would mean we would need access to their private seed, which they don't allow.

Thats the problem. Probably investors didn't get the return they expected. Google bought sparrow's for the team, not the tech. So what likely happen is Google payed a small sum for Sparrow and instead gave huge sign-in bonuses to the team. Thus investors don't ge a huge return, the team does.

This pisses me off. It's irresponsible to the current customers. I hope other startups don't follow.

Its OK to sell, but they should have pushed Google to maintain an support Sparrow for at least 2 more years.

Great job ad. Journalism is historically a career were people are very unhappy. This is due to many many facts, which are hinted in the post. I bet theres a lot of great journalist that will read this and would want to jump into such opportunity.

Both Github and Dropbox offer a free plan plus they don't need the network effect. If I were the only user on Dropbox I would still find it valuable. Same on github.

However the service you are proposing does have a huge network effect. Twitter/e-mail without users is not valuable.

So whats your plan to get to a million paid users?

NOTE: Pandora had about 71 Million on October 2010 but only about 700,000 paying users. So not even Pandora has been able to get to 1 million paying customers. Just look at the financials. 14% of revenue came from paid users and 84.6% came from ad's. Which supports Fred Wilson point that the majority prefers ad supported services.

I am going to support App.net. I still want to see you try. But I am afraid you don't really have a good answer on how you plan to build the network and Fred Wilson is trying to warn because you will probably fail. But something tells me you don't care if you fail, thats why I'll support you.

I didn't see your refutal of why is he wrong. He argues that when scale and network effects matter, free services supported by ad's win.

How's is he wrong about that? Your article seems to focus on service quality (specifically to developers). You keep saying that you could provide a "better" service if you are not ad supported. Perhaps you can and I assume Spotify/Pandora paid service is better than their free service, but they don't have the network effect problem.

What I have not yet seen you explain is: How do you plan to get millions of users putting a big paywall between the user's and the service?

Title is quite misleading. It seems to imply we should build companies like they used to in 1999 (webvan style). What he is actually saying is that is now time to build companies that people tried in 1999 but were too early. It's now time to revisit all of those ideas. This is actually quite obvious to most people by now.