This completely misses the point of Two-factor authentication, though.

Two-factor authentication is all about increasing security by combining two separate factors: something you know (password), and something you have (phone). From what I can tell, you're just switching from relying on one factor (password) to relying on the other factor (phone). It's just a different one-factor authentication paradigm.

Unfortunately, this leaves several gaps. For example, what happens when I lose my phone, or someone takes it from me? Can that other person log in immediately?

I can potentially understand an argument that this is more secure than solely password-based solutions (although I don't think it would be for me, where I use complex random passwords), but I certainly wouldn't consider it an alternative to two-factor authentication.

1) Screw outsourcing your authentication database to a third party, or incorporating third-party JS, as a mandatory thing. It's ok if you build something (like OATH) which allows a third-party service provider, but it shouldn't be mandatory; you should be able to implement the entire thing on your own infrastructure, and ideally play nicely with other sites in a user-selected client (potentially a browser).

2) I'd rather just do N-factor using a client cert stored in the web browser (mobile or desktop), combined with a password. x509 is probably terminally defective in desktop browsers due to historical accident and a messy protocol, but it could work on mobile, and stuff like OneID or BrowserID could meet the same need for regular browsers.

I don't believe in desktop + cellphone both being required to log into every site every time. The OATH compromise (using the phone periodically, along with a desktop password, and caching something in the browser) is an acceptable compromise for some apps.

Ultimately what I want is trusted keystore of asymmetric private keys on devices, and then multifactor auth to the keystore (biometric, password, location/time based heuristics, etc.), and reasonable management of keystores and keys (so I can for instance revoke every key on my phone if stolen, or disallow ipad and iphone but not mba13 for dropbox, but allow all 3 for linkedin)

The technical problem is relatively simple; it's an integration program (the auth libraries used by every site, plus mobile OSes, maybe desktop OSes, and hardware in phones and computers).

Give users the ability to make their own choices, and let sites establish minimum standards as well. I should be allowed to make a site depend on fingerprint swipe + physical location + specific machine if I want, but it shouldn't be mandatory for a random game site for everyone/anyone.

I've never heard of Rublon before now, but this post has started me off with a pretty negative impression.

I'd suggest you work on your elevator pitch a bit more.

Thanks for your opinion guys. Looks like we'll have to invest much more time in creating a new website that will explain Rublon more precisely. I can see that there is way too much confusion and misunderstanding about the product.

How entering 6 digits hard for users?

You have to log in with your username and password first and then you have to enter another password (those digits that you're talking about). With Rublon you just scan a Rublon Code and that's it.

But in another post, you say that you are planning to add a second factor to Rublon, so that the user must enter a PIN when scanning the Rublon code. So it doesn't appear to be any more convenient that Google Authenticator, which is widely-supported, produced by someone I trust, and open source.

The idea of using QR codes for authentication is interesting, but I would be very careful in selling this as a highly-secure system that is capable of replacing two-factor auth.

To me, this appears no more secure than leaving a copy of your password in plain text on the phone - if someone gets access to your phone, they have access to all of your Rublon accounts. Compare this to Google Authenticator - in the same scenario, the attacker would still need to know my password as well as the token.

So you've invented one-factor authentication?

This is neat but only requires a phone, there's no second factor.

Right now the second factor can be the PIN code that you set up for your phone. Soon we'll add an optional intelligent PIN option for the app itself.

How about this for a novel idea. Stop inventing new mechanisms for autentication, and let ME choose how I authenticate myself to your service (to gain access to MY data). http://ragmondocom.appspot.com/2012/03/My-Stuff-My-Lock

how is the phone not a second factor?

Because there is no first factor. You don't log into Dropbox or Google with only your OTP, you use a password and OTP. With the method above, you scan a code with your phone instead of using a password or OTP.

Rublon replaces passwords with cryptographic keys that are partially stored on your phone. This is a completely new approach to user authentication.

It's not a completely new anything, it's a password on your phone.

> Two-Factor authentication sucks. It's too hard for users.

It must be easier to build a startup on the assumption that your users are incompetent mouthbreathers. Respecting your users is hard work :-/