[ANN] NameID - Use namecoin id/ to log into OpenID sites

[jprider63]

Actually, maybe storing the user's known public keys is not necessary if the challenge includes the server's public key. It could be beneficial though to detect if the server's public key has changed, but I'm not sure whether this is useful information. I'll have to think about it.

[domob]

I suppose it would be easier to reason about if the protocol was written up and published. From what I can tell, U requests a log in to A. A returns C, which is composed of U's id and a nonce. U signs the challenge and returns it to A. A verifies the challenge and logs U in.

Yes, that's surely true. The project is still in the experimental phase, though. But in principle, the "protocol" should be clear as it involves "just" signing the challenge, and the challenge is visible in the clear if a user does not use the add-on. Thus it can be seen very easily what exactly is part of it and whether or not this would be good at a different site also.

What is the trust-free library? A plug in that allows many sites to use this protocol for authentication?

Yes exactly. My server-side code to do the authentication is split off from the OpenID stuff, and I encourage website owners to include it (or something based on it) to allow direct log-in to their sites without needing to go through OpenID. If done correctly (for which some documentation exists, although just something I wrote up quickly while at it), these sites would then even work with the add-on (if the user confirms that he/she wants the add-on to be enabled on the specific URIs of those sites).

The attack I mentioned would work when a user can use this authentication protocol to log into multiple sites (ignore OpenID). Perhaps having the Mozilla add-on insert the actual URI could offer some protection, however it may still leave open social engineering attacks like phishing. Also, if the user is being man-in-the-middled, he could be tricked into signing a challenge for a different site.

A potential solution to this problem would be to include the website's public key in the challenge (or /d name so this could be recovered). Client side software (Mozilla add-on) should probably keep a list of known public keys (or /d names) like SSH does. The user can then verify a site's information and public key while logging into a site for the first time. The response could then be improved so that it is encrypted using the site's public key. Therefore the response is only good for that site since only that site can decrypt the challenge.

What you describe here sounds like a different problem, to be honest. I think that solving the possibility of a MitM attack against TLS (using rogue CAs for instance), which sites should use anyway, is not within the scope of NameID. Instead, this could be solved generally by using d/ with TLS fingerprints (which already can be done), which would also secure non-login sites.

[biolizard89]

The attack I mentioned would work when a user can use this authentication protocol to log into multiple sites (ignore OpenID). Perhaps having the Mozilla add-on insert the actual URI could offer some protection, however it may still leave open social engineering attacks like phishing. Also, if the user is being man-in-the-middled, he could be tricked into signing a challenge for a different site.

A potential solution to this problem would be to include the website's public key in the challenge (or /d name so this could be recovered). Client side software (Mozilla add-on) should probably keep a list of known public keys (or /d names) like SSH does. The user can then verify a site's information and public key while logging into a site for the first time. The response could then be improved so that it is encrypted using the site's public key. Therefore the response is only good for that site since only that site can decrypt the challenge.

What you describe here sounds like a different problem, to be honest. I think that solving the possibility of a MitM attack against TLS (using rogue CAs for instance), which sites should use anyway, is not within the scope of NameID. Instead, this could be solved generally by using d/ with TLS fingerprints (which already can be done), which would also secure non-login sites.

Agreed; using d/ names with TLS fingerprints is much more user-friendly than trying to have users verify keys.

@domob Would you be interested in writing a plugin for Drupal/WordPress/phpBB/etc. which implements the NameID trust-free library? It might help increase adoption.

[jprider63]

Hmm I suppose I need to think about this more. My intuition is that this authentication protocol does not authenticate the server sufficiently. Also, I think my previously proposed solution does not actually solve the problem.

Perhaps if the d/ name is included in the challenge and verification of the d/ name is included in the protocol, this would be sufficient.

[domob]

@domob Would you be interested in writing a plugin for Drupal/WordPress/phpBB/etc. which implements the NameID trust-free library? It might help increase adoption.

Yes, that sounds like a good idea! Note however, that I have experience with neither of those projects at the moment. I'm also quite out of time for the current and coming week, but I'll keep it on my list of things to consider when I have time!

[biolizard89]

@domob Would you be interested in writing a plugin for Drupal/WordPress/phpBB/etc. which implements the NameID trust-free library? It might help increase adoption.

Yes, that sounds like a good idea! Note however, that I have experience with neither of those projects at the moment. I'm also quite out of time for the current and coming week, but I'll keep it on my list of things to consider when I have time!

Awesome. NameID is shaping up to be a quite awesome project. If I can get my supervisor to approve getting a VPS so that I can run namecoind/nmcontrol (not certain at all giving our funding situation here), I would definitely install a Drupal module for NameID on one of our websites if such a module existed.

[khal]

Good news Khal.
I see on the bottom 2 input fields:
...
I guess this are the supported identity providers and
.icon stands for some blocked buttons.
As I see both login fields if I insert https://nameid.org/?name=namecoinidentity are redirecting to the namecoinidentity login.

I updated the form to put the real icons & an entry for the nameid provider.

Any other volunteer to test ?
https://dot-bit.org/forum/ucp.php?mode=login


ps : nameid seems to ignore the "name" field and the "name" param if you put one in the url, so you have to type it again on nameid.org.

[aristoteles]

Hi, sorry for a little break.

Not quite understand nameid, why would not the same as using a nick OpenID? And in any case, why are not totally independent of OpenID to make a kind of alternative?

Moreover, why is it free? Not be better for the economy namecoin charge something? or this is only temporary?

Sorry if the questions are very basic, but I read over and over and do not quite understand.

Thanks: D

[biolizard89]

Hi, sorry for a little break.

Not quite understand nameid, why would not the same as using a nick OpenID? And in any case, why are not totally independent of OpenID to make a kind of alternative?

Moreover, why is it free? Not be better for the economy namecoin charge something? or this is only temporary?

Sorry if the questions are very basic, but I read over and over and do not quite understand.

Thanks: D

NameID can be used independently of OpenID; there's a library on domob's GitHub for doing that. Obviously the website operator would have to choose to support this.

It's free so that people can audit it. Basic security practice requires open-source software... why would I trust someone with my login credentials when I can't audit their code?

[domob]

I've updated the server as well as the Firefox extension to support "signer". A more detailed reply has been posted in this thread at forum.namecoin.org. (Not sure which forum to prefer at the moment, though.)