Pretty much every site with a login facility has an "I forgot my password" option where you put in your username or email address, and it sends you a link to reset your password. This is effectively a second form of authentication - the ability to receive email at that address implies the ability to log in to that account.
So what about an authentication mechanism that works as follows:
1. You type in your username
2. The site emails you a one-time authentication token (as part of a link)
3. You click on that link and then you're logged into the site
Of course, there are a few obvious problems with this: it's a bit cumbersome to have to do for every login, email is unencrypted, and message reception uses a pull-based mechanism.
So I could envisage a standard, incorporated into browsers, as follows:
1. When you first launch your browser, you log into an authentication server S, supplying your password (either manually, or automatically via a saved password)
2. When you want to log in to a site, you type in your username, and the site sends an authentication token to the server S
3. S sends a push notification to your browser with the authentication token
4. Your browser passes this token to the site, and you're logged in
This way, your (hashed + salted) password need only be stored on server S (in the first example, this corresponds to your email server). This means that apart from S, none of the sites you use need to store any password information at all.
I'm sure this basic idea has been implemented previously in other contexts. Why are we not using for all our web logins?
The role of server S would be analogous to that of your email server, which you already trust. Just like email, it would be a decentralised system - with numerous public providers, as well as servers that organisations and individuals have set up themselves.
You could also have multiple accounts with different S servers, e.g. one for work and another personal use.
I agree with the single point of failure regarding availability - if your authentication server is down, you won't be able to log into anything. Though we already have the single point of failure with the existing system, in that once someone has your email password, they can obtain password reset messages from any site that you've registered on with that account.
So you gladly replace that single point of failure with two points of complete failure? You can't conceive of any problem with that reasoning?
You could also have multiple accounts with different S servers, e.g. one for work and another personal use.
If I was forced to use such a service I'd make a service that made it easy to automatically create one "S-server account" for each "real" account and continue to use passwords for those accounts as if nothing had happened.
In practice, BrowserID doesn't solve anything for me - at the cost of reduced security, availability and integrity - as well as forcing me put trust in a third party.
There is a huge difference between my mail server and the S server. If someone uses my mail to reset passwords I will notice, since my credentials won't work anymore. Also there are different levels of security, I value my mail account more than say my account on hacker news. Which I haven't even entrusted with my mail-address - love that you don't have to supply even a fake one and considering that I don't forget my password (or allow anyone to hijack my session) I can't possibly gain anything from supplying it.
Which is the key point, rather than me not trusting ycombinator there is just no incentive for me to supply it - so why should I? Maybe ycombinator gets hacked and my mail gets leaked, I might thus end up with spam - no need to take that miniscule risk when there is nothing to gain. Just as I see no reason to link independent accounts together with a service such as BrowserID.
Hehe, I was expecting to get an "X already does that" reply pretty quickly.
Surely this needs to be promoted more heavily to website developers, especially those behind major sites like linkedin. I'd never heard of it myself and I'm sure a lot of others haven't either.
If some of the bigger sites started adopting it, awareness would grow very quickly and we could greatly reduce the risks involved with every website storing password info for all their users.
A clarification of the second point 2: The site needs to know the address of server S, and your account name on that server (i.e. just like username@domain.com with email). So the system doesn't have to be centralised.
Pretty much every site with a login facility has an "I forgot my password" option where you put in your username or email address, and it sends you a link to reset your password. This is effectively a second form of authentication - the ability to receive email at that address implies the ability to log in to that account.
So what about an authentication mechanism that works as follows:
1. You type in your username
2. The site emails you a one-time authentication token (as part of a link)
3. You click on that link and then you're logged into the site
Of course, there are a few obvious problems with this: it's a bit cumbersome to have to do for every login, email is unencrypted, and message reception uses a pull-based mechanism.
So I could envisage a standard, incorporated into browsers, as follows:
1. When you first launch your browser, you log into an authentication server S, supplying your password (either manually, or automatically via a saved password)
2. When you want to log in to a site, you type in your username, and the site sends an authentication token to the server S
3. S sends a push notification to your browser with the authentication token
4. Your browser passes this token to the site, and you're logged in
This way, your (hashed + salted) password need only be stored on server S (in the first example, this corresponds to your email server). This means that apart from S, none of the sites you use need to store any password information at all.
I'm sure this basic idea has been implemented previously in other contexts. Why are we not using for all our web logins?