

Mozilla Persona for the non-web - rnyman
https://hacks.mozilla.org/2013/04/mozilla-persona-for-the-non-web/

======
BenoitEssiambre
I recently investigated using Persona for a web service and mobile app that I
am building. I think I will be using it. However there is one aspect that bugs
me. I'm not very knowledgeable about crypto stuff so maybe someone else here
can enlighten me.

The part that bugs me is that it seems to rely on clients keeping a private
key secret and I'm not sure we can trust clients that are often programs
downloaded off the internet to do so. What stops a maliciously coded BrowserID
client from sending the user generated private key to a web service (the RP)
along with the identity assertion?

Wouldn't this allow this malicious RP to login to other services that support
Persona on the user's behalf and read and write info from his other accounts
at least for the duration of the certificate?

This certainly wouldn't happen in the Mozilla implementation of the browserID
client and I'm not sure it's a huge concern. Since the certificates are of
short duration it's certainly not as bad as people using the same password
across different services. And of course all single signin systems have risks
when malicious services are involved such as the impersonation of the login
page to get users to reveal their passwords but still, can someone put my mind
at ease about this particular case?

~~~
anonymoushn
Services should reject any "identity assertion" that claims to be for the
wrong service, so having a malicious client log in to my LivingBook won't
allow you to compromise my Twindr account. You can read more if you like:
[https://developer.mozilla.org/en-
US/docs/Persona/Protocol_Ov...](https://developer.mozilla.org/en-
US/docs/Persona/Protocol_Overview)

Edit: Before I talked about some stuff that you obviously already knew :)

~~~
BenoitEssiambre
What I'm talking about here is a malicious service (Relying Party) that
provides his own malicious BrowserID client to the user. Web services or
mobile apps often provide their own clients. If the user's private key is
leaked to a malicious RP when the user logs in this RP, can't it generate fake
identity assertions (using the leaked key) to use along with the user
certificate to login to any other Persona account? The faked identity
assertion can claim to be for any service.

~~~
anonymoushn
Ah, yes, a valid user certificate and the corresponding private key would
allow you to impersonate the user for other RPs for the duration of the cert.
That is troublesome.

Edited more: If you ship the user a malicious client and the user runs it, you
can just keep his email password. This probably grants you access to all of
his accounts for longer than the cert would last anyway. If the user uses
2-factor auth, the private key + cert combo is more useful than the password
though.

~~~
lukeh
Having a browser native client will help.

------
AndrewDucker
Persona, in some ways, seems to be filling the PKI gap.

It's a simple method for any email supplier to supply a key asserting that a
particular email address is owned by a particular person, that that person can
then use to authenticate elsewhere.

I'm actually somewhat baffled that it's taken this long for someone to come up
with it!

~~~
lukeh
Likewise. We want to extend it to non-web protocols where other attempts such
as SPKM and PKU2U have either failed or not got much traction beyond a
particular vendor implementation (respectively).

------
anonymoushn
It's nice to know that this is being worked on. As a web app there are several
ways to punt on managing user accounts (though some of them will earn you a
lot of HN comments saying "I can't use it due to facebook auth"). It would be
great to be able to do this for native apps as well.

~~~
lukeh
Article author here. Many native apps of course will use HTTPS and will be
able to use ordinary Persona. The protocol described in the article is for
native applications that need replay detection, key exchange, mutual
authentication, etc (particularly those that already use SASL and/or cannot
use TLS).

------
lucb1e
The title sounded very promising. The "proof of identity" system we use in the
"non-web" is very crude: Handwritten signatures are about the cheapest and
most easily forged type of authentication you can think of, and yet they are
(combined with your full name), usually legally valid and binding. A picture
of someone holding up a purse with his driver's licence, back of a debit card,
passport or identity card is all it takes.

But it turns out they mean "non-web" as in "ssh, imap, etc."

I keep waiting for someone to come up with something better than handwritten
signatures; a (H)MAC of some sorts seems the way to go. It just doesn't
come... And yes, I've also tried to devise my own system to cryptographically
sign documents, but it's not practical yet. Basically you're converting the
document to a digital format before generating a 128-bit signature (that you
can then put on the paper as 16 Unicode characters), which is not really
ideal.

~~~
maxerickson
I'm pretty sure that in most places, your signature is only legally binding
when you are the one that signed it. It doesn't particularly provide
authentication, but in cases of fraud it provides some evidence of intent.

~~~
lucb1e
Of course, but the signature is the proof that you are the one that signed it.

~~~
maxerickson
I don't think it is used that way very often.

~~~
lucb1e
Besides on every exam I've attended (school and for driver's license), and
pretty much everywhere else where I had to prove my identity.

~~~
maxerickson
So for how many of your school exams do you think someone actually
authenticated your signature? If it is never checked, it is reasonable to
argue that it isn't being used to verify anything. Also, on things like exams,
it is being used to encourage the test takers to take the honesty pledge
seriously (and again, if someone signs a wrong name, it shows deceitful
intent).

Identity is much more slippery than you are making it out to be. A signature
doesn't prove it. An authentic government document doesn't prove it (it just
verifies that you went through that particular identity verfication process).

