Good questions

The private keys are generated and stored on the phone -- on iOS we get to use hardware encryption and on Android we use PIN-based encryption (though we're considering using something like Rivetz here).

We use the standard system libraries for both platforms to generate the keys which offer plenty of entropy for this kind of usage (http://android-developers.blogspot.de/2013/08/some-securerandom-thoughts.html -- the SecureRandom patch of course happening after August 2013).

As for being Internet connected -- when we talk about theoretical security, an Internet-connected phone will never provide the same level of protection as a dedicated offline device. That said, dedicated devices as they exist today are all seed-based (and so must have a server counterpart that stores the exact same seed and which IS Internet connected as well as centralized). A key based, dedicated offline device is definitely possible, but the infeasibility of distributing them along with the increased burden of training people how to use them make them pretty farfetched for a broad audience.

Yeah, the tradeoff for all of this is how much Clef manages vs. how much users manage their own security process. Tools like Google Authenticator give you more control over the technical process, but that's a lot of rope to let users hang themselves with. The result is that most sites see <1% of users opt-in to using two-factor, and even in Bitcoin that number is less than 15%. For the few users who are technical enough, that helps protect their accounts (unless there is a server breach, phishing, or bucket brigade attack).

Clef sees more than 50% of users opt-in because they don't need to manage any of the process. At the site level, that means a whole lot more users are actually safe and we can reduce fraud by a much more significant factor (as well as protect from more common attacks).

For account reactivation, that focus on usability means we never ask users to write down their key (of the few people who use token-based two-factor, less than 1% write down their backup codes). Instead, we set them up with a new key pair once we confirm their identity with the process I described before.

A little while ago, I had a conversation with 5 ex-DOD white hats about Clef's architecture. At the end of my overview, one of them asked "How do you handle nation-state attacks when they're willing to used advanced interrogation to compromise an account." I told him we weren't solving for that yet

There are a lot of ways to make theoretical security gains, but the only security that matters is the security you use. 

Thanks for the questions! These are both really interesting things that we think a lot about.

We don't have a bare-bones open source client, but we are working on open sourcing all of Clef. While a bare-bones client might be appealing to some really technical users, it could lead to some really confusing (and malicious) options for non-technical users. If there are a plethora of apps that "work" with Clef, how is the average user supposed to know which ones are generating and protecting their keys correctly?

Even open source, we could be compiling something extra into the app, but you can always look at the outgoing traffic from Clef on your phone to see that we're not sending the private keys.

As for lost phones -- right now you can deactivate a phone by confirming an email and the four digit PIN used to set up the Clef account (this is heavily rate-limited and zero PIN attempts can be made until after the email has been confirmed). In the next few months we'll be rolling out some additional layers of proof to give users more options for resetting their account -- this'll include letting users download their private key and disable all other forms of deactivation/reactivation.

Hey dooglas, using Clef definitely strengthens your overall security!

Instead of using passwords and seeds (which need to be stored centrally and can be stolen), Clef uses public-key crypto to log users in. That means that most hacks against a Clef-protected account are completely impossible (you can see more at getclef.com/security). If Clef is hacked, we only have the public keys and so there’s nothing for an attacker to steal or use against the user. 

You do need to trust Clef for us to provide that protection. In the pre-Clef model, every developer is asked to stay informed about and re-implement best security practices on their own and we know that many developers are making mistakes or falling out of date. At Clef, we’re focused on doing one thing well and we’re much more likely to get it right.

As for whether you can trust that we’re not a malicious company — there are a couple of useful pieces of information:
    * We’re a venture-backed company, so we’ve passed background checks and the company is well documented
    * Our address and the names of our team are all listed on our about page (getclef.com/about)
    * Clef has been around for more than 2 years and protects nearly 50,000 sites

Early on, we experimented with sharing public keys with sites that implemented Clef so that they could verify signatures (so they could trust us even less). We found that most sites preferred a simpler integration and that the sites that did the extra work frequently messed up some of the crypto because they didn’t understand it. That lowered the security and the usability of the system, so we stopped sharing them, but it’s something we still think about. I’d be happy to hear your thoughts about this.



tl;dr - to use Clef, you have to trust us, but public key auth is much harder to hack, so the overall security is way stronger