What's impractical about it ? I'm very comfortable with separate identities per-site.
If your site isn't worth a separate identity, why am I interacting with it in the first place?
If your site isn't worth a separate identity, why am I interacting with it in the first place?
- Maintain a separate login and password for every site. This requires a lot of memorization and is a pain in the ass when you find yourself trying four passwords because you forgot which you used.
- Use password management software or a naming system that lets you keep track. This is effective but is a bit much for a majority of people who do not, and probably never will, use tools and reasoning to help them do things on their own volition.
- Use the same login and password almost everywhere. This is easy but is shitty security.
You might claim that using a third-party authenticator is just like option #3, but it's not. Option #3 above means that your single credentials are under the control of the least secure site you use them on, so if someone cracks some install of PHPBB version 0.0001 that you logged into, you're fucked. Using a third-party auth provider relieves you from this worry. It even means that you can switch at your leisure and start using a hardware generator or a long passphrase if the provider supports it.
This sort of authentication system should be built into the browser, entirely under my control, and every site should be given a separate identity token.
Not saying it's not possible - not trying to shoot this down at all - just I think it's a major issue.
The difference is that you control the connection and your information directly. With OpenID or Facebook the connection is directly between those entities and site you are visiting. With a browser-based system, the connection is always between the site and you or the cloud and you.
Here's what I do. I have two branches of passwords: one unsecure and easy to dictionary attack, another that was randomly generated and I got into muscle memory when I was a boy. Each secure site gets its own slightly different version of the password, with an additional suffix which is usually a small word.
It's a system that's served me well. Are there some glaring weaknesses that I should take account of and switch to something else?
Here's one possible scenario: let's say that I happened to be a member of a website that unfortunately allows an attacker to hit their login form as many times as they like and as fast as they like with various username/password combinations, and by brute forcing this login page in this way, they manage to determine what my username/password actually is. Now the attacker does know my username/password for one website I belong to and - if they're smart and determined - it may occur to them that now they know one of my usernames/passwords they might use these details as a starting point in trying to brute force other accounts that I may have on other websites.
I used to run these kinds of brute force attacks against websites back in the day when I had nothing better to do and before I had to work for a living. Often I was quite successful, but I wasn't targeting specific users and even back then I could tell that websites were getting more savvy in terms of detecting and defeating such attacks. So no doubt it would be harder to pull this kind of thing off now and it would probably depend a lot on which website(s) you targeted. But surely it wouldn't be impossible.
[1] http://blog.moertel.com/articles/2006/12/15/never-store-pass...
The harder you make it for us to visit, even if it's a minor inconvenience, the less likely we will.
Yes, it's a ridiculous example, but the vast majority of end users keep the same username and password for all of their online services. Obtain one U/P pair and you could conceivably access their identity anywhere. A centralized, specialized authentication provider could maintain multiple levels of authentication depending on what the service demanded. Perhaps your favorite news aggregator only required that you be authenticated with a username and password, but your bank could be using the same authentication service and demand a physical token or one-time password to continue to the service.
The idea is to maintain the convenience we already demand and practice in a manner which is orders of magnitude more secure.