Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Let's talk about why -- do you place greater trust in AirBnB (or random websites X, Y and Z) to keep your credentials safe than you do in Google?

Do you not want the identity provider (e.g. Google) to know every place you log in? (This was something Persona solved, alas...)

Do you not want to be reliant on a megacompany like Google whose spam filters might someday hit a false positive, causing Google to ban your account, and there's nobody to call and you're locked out of everywhere?

Or is it about separation, i.e. you don't want any single notion of your identity to have too much power if compromised (and you're careful to use unrelated credentials, e.g. distinct passwords, on every website)?

Or something else?

Are you ok with the way that GitHub and Ubuntu outsource the storing of credentials to authenticate a "push" by checking against a public key, for which only the user holds the private key? What if more services worked this way?



Do you not want the identity provider (e.g. Google) to know every place you log in? (This was something Persona solved, alas...)

Do you not want to be reliant on a megacompany like Google whose spam filters might someday hit a false positive, causing Google to ban your account, and there's nobody to call and you're locked out of everywhere?

Or is it about separation, i.e. you don't want any single notion of your identity to have too much power if compromised (and you're careful to use unrelated credentials, e.g. distinct passwords, on every website)?

Indeed, those are some excellent reasons to avoid any centralized login system. :) Most people won't care, but early adopters might. Startups don't need to care about early adopters after the 'early' stage, but the early stage is critical, so it's just something to keep in mind.

Are you ok with the way that GitHub and Ubuntu outsource the storing of credentials to authenticate a "push" by checking against a public key, for which only the user holds the private key? What if more services worked this way?

That'd be lovely. Unfortunately the key management problem hasn't really been solved: there's no way to make it easy for average users to create a key and use it on a bunch of different devices. "What you know" (a password) is still way more convenient than "what you have" (a keyfile), unfortunately.

I don't think there's any way to solve that without using a third party to sync keys across your devices. Something like that might be able to be done securely, but it'd require a lot of thought and care. (Ultimately we have to trust the service provider with our credentials anyway, so trusting them to sync keys doesn't seem like too far of a stretch.)


I feel like you already answered your own question. These reasons may not apply to you, but they certainly apply to me.

No, I do not trust megacorps to keep my credentials safe.

I do not wish to use the same credentials for every site, for several reasons: in particular, worse consequences of account compromise; worse consequences of terms of service changes.

No, I definitely do not wish megacorp identity provider to be able to link information from my accounts across different websites.

No, I definitely do not want to be reliant on a megacorp. Amongst other reasons, I do not believe that a single entity can provide for all cases and competition in solutions is a good thing.

I don't want my account at random website X to be dependent on external services. Random website X will be slower and less reliable, and I will be less able to access support.

I do not want any single notion of my identity to have too much power if compromised.

I would rather accept the risk that random website Y is storing my password in plaintext rather than accept the risk of using a megacorp (or other external service).


It's about not being at the whims of another entity which doesn't give a flying fuck about you, and will (often without or with very little warning) change API, have 'maintenance' (either 'planned' or 'unplanned'), or just call it a day and close up shop (of their external sign in, that is - or maybe even all together). So then you need to provide a fallback on your own anyway, and now you have two systems to maintain - so better to just use only your own.


> Google, Facebook

Why you list some of the reasons against using those businesses, it's important to remember that some of don't have accounts with those businesses. Never have, and never will. So requiring FB or G accounts to participate ends up being is a rather offensive "we don't serve your kind here" door-slam.

You can offer them as an alternative, but requiring a troublesome 3rd-party like that is only going cause problems.

> do you place greater trust in AirBnB (or random websites X, Y and Z) to keep your credentials safe than you do in Google?

YES. By a wide margin. Some random website I can give a unique email and password, so if they do bad things, the damage is limited. I wildcard all the smail at my domain to the same place, so if I see spam addressed to e.g. "[email protected]' I know who sold the address to spammers and have an easy regex to filter on, if necessary.

With google/etc, I wouldn't have that kind of granularity. Of course, there are all the usual reasons like not wanting google to know every login I make, but that topic is already covered.

> checking against a public key

That would be outstanding. Yes, we have not solved the key-management problem yet, but that's no reason not to try. With a problem this complex, it is going to take a number of attempts anyway before we get it right. Waiting for a "perfect" solution, on the other hand (i.e. "Web-of-Trust is too complicated!") will just leave us with the current mess.


I use KeePass synced via a Truecrypt encrypted volume on Dropbox, with a copy backed up elsewhere. Separate password for every account.

I have a couple of problems with identity providers. One is that they are, by necessity, a single point of failure. And because of that, they are more jucy targets. When someone exploits the provider, all of a sudden they can access any website that I have used that provider for. When the provider goes under or decides to stop operating the service, I'm probably SOL. If the service has an outage, I cannot use any website using it.

I also have issues with companies selling my personal info. At this point, yes. I do put more trust in a random website keeping my credentials safe for that website than Google keeping my credentials safe for every website that Google has in its clutches.

Public/private key crypto can work, but has issues of its own.


I'm with 'sillysaurus3 on this one: I have no interest in using a site that only uses the likes of Facebook and Google for authentication.

You've just listed four good reasons to reject centralisation of credentials with those organisations, and any one of them would be sufficient disincentive in my case.

I can think of at least one more good reason: If I'm dealing with an organisation, particularly one I'm paying for their services, if I have unique credentials with them, and if anything goes wrong on their side, then it's going to be their responsibility to fix it and make good any damage. If I'm dealing with them and using a third party for credentials, and that third party gets compromised in some way, then it seems likely it will end up being my responsibility to sort everything out and pay any related costs.


I like to spread a little trust around, rather than dump a lot of trust on one, monolithic provider.


I don't want that if Google closes my account I'm utterly screwed up. I'd like to be able to give a fallback e-mail address for example.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: