Live data from Hacker News

Persona is distributed. Today.

identity.mozilla.com

81–90 of 154 posts

Re: Persona is distributed. Today.

#81

I've just read through the Persona protocol specification document at https://github.com/mozilla/id-specs/blob/prod/browserid/inde... and was quite disappointed to find RFC5785 in use, in which HTTP is abused as an infrastructure discovery protocol. This gives a lie to the identity being an "email address". It isn't. Ok, it's structured as a LHS@RHS form but the domain in the RHS isn't an email domain, it's an overlo…

>This creates a significant barrier to adoption.

No, not really. Because Mozilla is running the Fallback server in the meantime.

Re: Persona is distributed. Today.

#82

Earlier quoted context omitted.

He was just making a point that authentication protocol is a domain choice (from 2-digit passwords to retinal scan). It's up to the users to trust the domain he is going to use as identity. Just like many people trust Facebook Connect.

But facebook at least has standards (or is believed to, i have no knowledge). Why should, for example, google, ever trust, say, fred's discount web hosting, enough to let them login to gmail? Not in the sense of "these guys could compromise gmail" (which is a worry in certain elevated privileges contexts), but more in the sense that "people are still going to say 'my gmail got hacked'" if their gmail gets hacked beca…

> Why should, for example, google, ever trust, say, fred's discount web hosting, enough to let them login to gmail?

They're not. They're letting users who use Fred's discount web hosting as their authenticator to log in. Fred's discount web hosting won't even know when their users try to log in to gmail.

Letting someone authenticate that way is no different than allowing passwords than many users reuse all over the net, including on dodgy sites that might very well take that gmail address and password they were handed and see if they can log in to the gmail account with it (want to be on how many users use the same password on their e-mail and other sites they sign up to _using_ that e-mail?), or writing it down all over the place.

> Long term, how are we not going to end up with just a mishmash of who accepts what?

If we do, we're no worse off than we are today.

Re: Persona is distributed. Today.

#83

Currently wondering the most sensible approach to make a single-user website support this protocol, so that I can make my email address (the only valid email address at my domain) support Persona natively. I don't really want to have to set up a username/password system with a single user. I'd almost prefer to manually hand my identity's private key to each browser I want to use. I wonder how much work it would take…

I recently set up my personal domain as an identity provider, using static HTML/javascript files and a bit of crypto:

  https://www.rfk.id.au/blog/entry/persona-identity-provider/
There are some things to be mindful of w.r.t. security in this approach, but it seems to work very nicely for me.

Re: Persona is distributed. Today.

#84

Earlier quoted context omitted.

Honestly, I'm not sure if your counter argument is intended to be ironic. I'm used to an Internet where you're not required to be so goddamned polite. Seems to me it becomes the spidery veneer of Silicon Valley networking; insincere, self-interested, and a corruption of what it means to be 'nice.'

What's wrong with being polite? It doesn't cost any extra and there are a lot of people who appreciate it.

Not anything wrong with being polite. Plenty wrong with requiring people to be polite.

Re: Persona is distributed. Today.

#85

Earlier quoted context omitted.

But facebook at least has standards (or is believed to, i have no knowledge). Why should, for example, google, ever trust, say, fred's discount web hosting, enough to let them login to gmail? Not in the sense of "these guys could compromise gmail" (which is a worry in certain elevated privileges contexts), but more in the sense that "people are still going to say 'my gmail got hacked'" if their gmail gets hacked beca…

For most people, they already use an email account to authenticate. Pretty much every single login I have, someone with access to my primary email account could co-opt with the snap of their fingers. If your email provider is vulnerable, you're already fucked , except for those accounts which use two-factor auth. And persona isn't intended for your bank/etc.

But your argument is essentially "we're just as fucked as we are now". Okay, so then, uh, what problem have we solved?

Now we are fucked, after we're just as fucked but not using facebook as the identity provider?

I guess i don't see this as much of an improvement? Honestly, i'm not trying to be snarky. I'm just trying to understand why this seems to be presented as leaps and bounds above what we have now when it seems to be just as bad, just more distributed :)

Re: Persona is distributed. Today.

#86

I've just read through the Persona protocol specification document at https://github.com/mozilla/id-specs/blob/prod/browserid/inde... and was quite disappointed to find RFC5785 in use, in which HTTP is abused as an infrastructure discovery protocol. This gives a lie to the identity being an "email address". It isn't. Ok, it's structured as a LHS@RHS form but the domain in the RHS isn't an email domain, it's an overlo…

We're discussing the addition of a DNS discovery option. Not clear yet that this is something that can be secured as well as HTTPS discovery (which I don't consider abusive, given the number of systems that do it already.) But it's on our radar: https://github.com/mozilla/browserid/issues/1523

Re: Persona is distributed. Today.

#87
post #48

Earlier quoted context omitted.

The service you log into knows the identity provider's public key and a cert for the user (the user's public key signed by the identity provider). The service can verify the user's cert against the identity provider's public key with this information. The service initially contacts the identity provider to get the provider's public key, so the identity provider can infer that someone is attempting to log into the ser…

Does this mean that your browser can cache the signed cert and log in to websites automatically without needing to even contact the provider again? I'm guessing there's some sort of timestamp there, to prevent someone from just stealing the cert and logging in to whatever they want as that user.

Yes, that is exactly right, and it's also why certs are short-lived (hours). When certs are renewed, the site the user plans on logging into is not revealed to the Identity Provider.

Re: Persona is distributed. Today.

#88
post #48

Earlier quoted context omitted.

The service you log into knows the identity provider's public key and a cert for the user (the user's public key signed by the identity provider). The service can verify the user's cert against the identity provider's public key with this information. The service initially contacts the identity provider to get the provider's public key, so the identity provider can infer that someone is attempting to log into the ser…

Does this mean that your browser can cache the signed cert and log in to websites automatically without needing to even contact the provider again? I'm guessing there's some sort of timestamp there, to prevent someone from just stealing the cert and logging in to whatever they want as that user.

By my understanding, yes and yes. The third-party service caches the public key (with timestamp) and the browser caches the signed certificate (with timestamp). The timestamp gives the credentials a relatively short TTL to prevent a stolen cert from being used indefinitely.

Re: Persona is distributed. Today.

#89
post #12

How is this different from OpenID? EDIT: Seriously, this question was downvoted within two minutes? Why? EDIT again: The best I've been able to come up with by reading the comments and docs is that they attempt to solve the same problem, but OpenID is based on the backend of the website you're logging into issuing a request to the auth server over HTTP, while Persona has the auth server issue a very-short-duration ce…

One way it'll be different is (presumably) users won't be confronted with a wall of possible OpenID providers. You asked a good question. HN's not very good at self-regulating. Negativity is regarded negatively in some bizarre self-perpetuation cycle.

Exactly right: we hate the NASCAR array of buttons that is publisher-centric, rather than user-centric. I wrote about this a few days ago on the Persona blog:

http://identity.mozilla.com/post/45842909320/users-dont-like...

Re: Persona is distributed. Today.

#90

Earlier quoted context omitted.

For most people, they already use an email account to authenticate. Pretty much every single login I have, someone with access to my primary email account could co-opt with the snap of their fingers. If your email provider is vulnerable, you're already fucked , except for those accounts which use two-factor auth. And persona isn't intended for your bank/etc.

But your argument is essentially "we're just as fucked as we are now". Okay, so then, uh, what problem have we solved? Now we are fucked, after we're just as fucked but not using facebook as the identity provider? I guess i don't see this as much of an improvement? Honestly, i'm not trying to be snarky. I'm just trying to understand why this seems to be presented as leaps and bounds above what we have now when it see…

No, if you choose a shitty email provider you're fucked. But currenty, you're also fucked on a site by site basis if whoever you have an account stores your password in plaintext/etc.

It's an improvement on having dozens of accounts on dozens of sites, both from a security standpoint and a UX one.

Post reply on HN