Hacker News Reader

I'm comfortable with separate identities per site, but it is impractical for most people. You have three general choices:

- 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.

Choice. Let people choose if they want to use Facebook, or if they want to log in directly. Allowing people to log in directly should be the minimum requirement. Facebook should be an addon authentication system, not the only.

Oh, I think Facebook is much worse. I'm just pointing out that there really is a problem to be solved; separate authentication for every site is not obviously the best possible experience. Choice is a fine answer, if the developers are willing to spend the extra time implementing and maintaining the choices.

I'm not comfortable using any sort of 3rd party service. I also don't like that I have any kind of connected identity across multiple sites.

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.

Sounds good, but what happens when you reinstall your OS, or change your OS or browser?

Not saying it's not possible - not trying to shoot this down at all - just I think it's a major issue.

One could use a cloud service like Xmarks which already syncs bookmarks and browser passwords. Just because it's built into the browser doesn't mean that you can store the information in the cloud and sync it between browsers.

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.

Xmarks is shutting down in 90 days, apparently. =\

Option 4: use an address book, spreadsheet, or database to list passwords.

wtf? You know browsers can just remember this stuff these days, right? Or if you log in from multiple places and don't want to export your browser passwords then you can use e.g. Password1

If you keep your passwords in the browsers, you expose yourself to trojans that once they get access to your computer will harvest all your passwords from the browser and send them to some overseas hacker.

I think this is an issue that needs to be dealt with in schools, because it's going to be VERY important by the time current kids grow up, and most of them don't know what they're doing.

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?

I use pretty much the exact same system that you do and have done so for many years as well. Recently though, I'm starting to think I might try out the password management software route. I've haven't yet had a problem with any of my accounts being brute forced and I guess there's something to be said for "if it 'aint broke...", but reviewing the passwords I use, even the more secure ones, I have this nagging feeling that they are more similar to each other than they should be. If a resourceful and determined attacker was to somehow figure out one of my secure passwords, then that would be a good ways towards figuring out all of my secure passwords and I don't like that possibility, however remote it may actually be.

As long as each of your secure sites has encrypted the password in their database, which they damn well should be doing, an attacker wouldn't be able to benefit from any similarities because they wouldn't know what your password actually is. Right?

That would be right assuming passwords were always encrypted - and we know that unfortunately even some of the biggest sites have been bitten by not encrypting passwords in their database[1] - but that's not actually the case I was thinking of when I said "brute forced".

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...

Furthermore, makes it harder for some of us to use your service at work. My work will let me visit Facebook, but each access is logged and IT does track it. While I can notify IT that it's a valid work use, doing this for every site that causes a similar reaction from the firewall gets tiring after a while.

The harder you make it for us to visit, even if it's a minor inconvenience, the less likely we will.

Well, for one thing, this becomes a bigger and bigger problem: http://www.xkcd.com/792/

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.

That XKCD made me go back through a whole lot of my "low security" sites and change the password away from the same old thing I'd used for ages. Still funny though :)

whether having separate identities is a net win or a net lose depends on N. Having to maintain say 3 separate identities (N=3) on the web (roughly: one for public social, one for private/secret, one for money/utilities) is a much lower burden than having to maintain say 30 or 300 separate unconnected identities, each with their own username/password/profile/messaging/eventstreams/community-connections.