> No, I don't know what would be better than passwords.

I'm quite happy with Google's Implementation of http://en.wikipedia.org/wiki/Two-factor_authentication called "2-step verification".

And if Mozilla's BrowserID proves as secure as it looks and becomes widespread, we can combine those two and breathe a lot easier.

I don't have the solution, but I have part of it: http://www.emailambush.com

I started this just a short while ago in response to all the Lulzsec email/password combo DB dumps that were released.

In short, you keep an email in your inbox that looks tempting for hackers that - if any images are loaded or links are followed - sends a text message immediately to your phone, allowing you to quickly change your password and/or alert your administrator.

Reminds me of John Graham-Cumming's email canary:

http://blog.jgc.org/2011/06/my-email-canary.html ( discussed at http://news.ycombinator.com/item?id=2636685 )

It was actually the inspiration. I'd been doing this myself for a while, but hadn't thought about making an actual product out of it. When I saw the incredible response from the HN community to email canary, I realized I should really take a swing at this.

I think phones might be an interesting possibility. Granted, you can lose one or have it stolen, but for most people that's probably less of a risk than using bad passwords that are the same over multiple sites.

Of course, there are all kinds of things I'm not thinking of, because... it's not my area of expertise. It just seems like it might be something that's potentially doable and a decent compromise between security and usability.

If you have a smartphone, chances are your account to whatever is already compromised by the ability to reset via email, unless you are good about signing out of your email application.

So a phone solution sounds like a pretty good solution, since it's not any worse than the current situation. However, a fair number of people still have a 10 cent/message SMS plan, and would be unhappy if they had to start paying $1+ a day to log into all their accounts, so using SMS seems less than ideal in that respect.

I'm thinking something a bit more high tech, like using NFC or Bluetooth so that you have to have the phone in range of the computer.

What would be better than passwords? Public-key crypto. The password/phrase is only used to protect the private key, so there's only ever one password to remember. Of course, validation of the owner becomes the troublesome point here.

I predict that these problems will be finally solved when commodity webcams are good enough for secure retina/iris scanning.

Biometrics might be useful as one component of security. But if someone ever gets a copy of my iris/fingerprint/face etc., they shouldn't be able to log in as me forever. I want a password (or key or something) that I can change or revoke. I can't revoke my retina!

Unfortunately, this doesn't solve the problem:

To do iris-scanning security, there must be a back-end database with the characteristics ("fingerprint") of each user's iris.

This database will be secured as strongly/effectively as a password database because it contains authentication credentials.

Unfortunately, password databases get broken into, and similarly iris databases will also get broken into.

The attacker then has to simply convert the iris fingerprint back into an image to replay to the authentication process.

This is probably easier than reversing a password hash (because the fingerprinting algorithm is unlikely to be optimised against reversing), and certainly no harder.

(This is assuming untrusted client-side hardware.)

Ideally, you wouldn't store the iris fingerprint itself - that's just as bad as storing a cleartext password today.

Rather, a good solution would involve deriving a (site-specific) token from the fingerprint and handing it off to the remote service, which then deals with it in much the same way we expect sites to deal with passwords.

This, of course, presupposes that we can retrieve a consistent and unique fingerprint from the same iris from various different images of it, and breaks down if all we can do is check an iris image to see if it matches a fingerprint.

The problem with biometrics is that once they are faked, and they can all be faked, You Have Lost. Once I've managed to acquire a picture of your iris (and somewhere in the system one must exist, even if you hash it ASAP I can still grab it straight from the camera if I've hacked your box), what will you do?

Biometrics are pretty much useless in consumers hands; they're more security theater than anything else. I do mean "pretty much"; if you fiddle around the edges of the problem you can with some work construct a use case where they really are the best solution to a problem, but as something that can just be deployed on a wide scale for general purposes? No.

You appear to be suggesting that the real security benefit would come from off-loading the authentication process onto a third party, but we can already do that with password authentication by using OpenID / Facebook Connect / whatever.

It's not clear how using iris fingerprints rather than passwords really adds anything other than to increase the risk of a false negative, and introducing a third party dependency.

(I do take your point about storing a hash of the iris fingerprint, though. How this would intefere with the matching process is, I guess, outside of both our areas.)

The real security benefit, I guess, is that people don't need to remember any passwords. The biggest weakness of password schemes is that most people choose weak passwords that they can remember, rather than strong passwords. If you could consistently derive a password from biometric data, then that sidesteps the entire issue (there are no "weak fingerprints").

And if you could consistently derive the key from the biometric data entirely on the client, then you wouldn't even need an authentication provider, instead transparently treating the resulting authentication token as a password.

If you use a biometric fingerprint instead of a password you will soon find that passwords can be changed, but biometrics can't.

If a password database is compromised, you have a problem, but you can change everyone's passwords.

If an iris database is compromised, you really have a problem.

Biometrics are also susceptible to replay attacks, where sort-of-alternatives (such as tokens) aren't.

Which is why, as I mentioned, you don't store the biometrics. You don't even send them to the remote service.

Hash + Salt on the client, submit the result. Unique salt for each remote service, and you can change it for a particular remote service if it turns out they do stupid shit with it.