Comment authentication

How do you authenticate when posting comments?
How do you follow up on comments you posted?

Simon's comment authentication via url ownership
Simon Willison designed and prototyped a nice solution to authenticate yourself by a url (say your blog's address).

The bookmarklet and your home server share a secret (a key). This secret is used when posting a comment, which will allow the comment server to verify that the home url you used knows the same secret.
Something unique to the transaction is signed using that secret key by the bookmarklet. It can be the comment itself, the url for comment form or some random challenge issued by the comment server. The comment server will then find the signature verification url responsible for your home address and submit it the same challenge. If a matching signature is returned, the owner of this home page did in fact post the comment.

The verification server is linked by your home page, using a link tag like <link rel="sigserver" href="http://signature-verification-url" />.

Flow:
I'm going to make a little diagram for this (on my Tablet, tonight), but for now, here are the steps in Simon's comment authentication (to prove you own a url). It involves the user/browser, the comment server (where the comment is posted), the user's homepage and the user's signature server (sigserver).

1. Get comment form
2. Get back comment form and challenge (may be implicit)
3. Fill comment and "homepage" url
4. Run bookmarklet (includes a solution/signature in the comment form, using the secret key against the challenge)
5. Post comment + challenge (may be implicit) + solution/signature
6. Comment server queries homepage to get sigserver url
7. Comment server submits challenge to sigserver
8. Comment server gets signature back and compares with user submitted signature

Click for larger view.

Notes:
The challenge is implicit if it is the url for the comment form, for example.

I think there is a flaw in this protocol though, as I could use Simon's sigserver to sign something for me (using the signature verification interface) and post a comment with the provided signature. The most straight forward fix is to have the sigserver output a hash of the signature instead of the signature itself.

A limitation of this system is that it requires a bookmarklet that contains secret information. First bookmarklets may be sensitive to browser compatibility issues, then it may be inconvenient to use a bookmarklet on a public computer.

Alternative url ownership proof solution
The Padawan proposed verifying your email address instead of your url. Although I like verifying your url better (since you probably don't want to display your email address in the comment and url verification can be synchronous), it got me thinking.

Validating an email address means you have access to this email storage. Validating your url could mean your able to post something to that url, or store something there. For example, the comment server could challenge you to post the number 1234AFFDEC to your sigserver, so that it can then check you actually managed to do it.
Here is my solution, using this principle and using cookies and redirects rather than the bookmarklet (which introduces one extra hit on the comment server and another one on the sigserver).

Flow:

1. Get form from comment server
2. Fill the comment form, specify your homepage url and whether you want to sign
3. Post the comment
4. Stop here if you didn't select the "sign this comment" checkbox
5. The comment server gets the sigserver for your homepage and saves the comment
6. The comment redirects you to your sigserver url with some standard querystring parameters: SubmitChallenge (some random number) and ReturnURL
7. Your sigserver verifies your identity (using cookies and showing a prompt if necessary), saves the challenge and redirects back to the ReturnURL (which is hosted by the comment server)
8. Get redirected to the comment server with the querystring parameters included in the ReturnURL (which we'll specify in the next paragraph)
9. The comment server verifies the querystring (since it generated it, it may be signed with the comment server's secret key)
10. Verify whether you passed the challenge, by doing a server to server HTTP request to the sigserver with the querystring parameter VerifyChallenge
11. The sigserver can remove the challenge from its storage and answers with HTTP 200 SigVerified (or some other code if the verification failed)
12. The comment server can now mark the comment as "homepage verified" and can decide what to display to you

Click for larger view.

Notes:
The ReturnURL is generated by the comment server and needs to contain enough context information, like the comment id, the challenge, the sigserver's url and some signature (so the comment server knows this url hasn't been tampered with).

If the first request to the sigserver contains the CommentURL in addition to the SubmitChallenge and ReturnURL, then the sigserver can track all my comments. Also the sigserver now shares a secret with the comment server, namely the challenge token, which can be used for further trusted notifications.

If you are not using your own computer, you probably don't want to leave the authenticating cookie used by your sigserver. This can be solved by using a "use session cookies" checkbox on the authentication form of your sigserver.

If for some reason the flow fails and the comment doesn't get verified, the comment server could trigger the flow again when you click on the "url not yet verified" link.

Afterthoughts:
I've been thinking about this since yesterday and I decided I like Simon's solution better. I doesn't add many server hits (only one on the homepage and one on the sigserver) and requires minimal change in the comment server code. Also, I use my own computers most of the time and don't browse with lynx very often ;-)

As I mentioned, to make Simon's protocol more secure, the sigserver shouldn't return signatures but instead hashed signatures. This proves the comment server that the sigserver knows it, without revealing it.
Similarly, I think the comment server should prove the sigserver that it also knows the signature, during the signature verification exchange. This can be done by passing a salted hash of the signature along with the salt used. At the end of the verification request both the comment server and the sigserver share a secret: the signature. This can be used for further interactions, like notifications of replies.

Links:
I need to look at Dave Winer's "You Know Me" button and Ben Hammersley's variant, but I didn't have time today.

Also I have seen some mentions of ShareID which I didn't look at in details too much yet (it seems partly centralized).

Commentblogger bookmarklet, a simple but a bit limited (manual) way of logging the comments you post.

There is a draft for an entity header for linked resources. Instead of using <link> tags, the links could be returned in the HTTP headers, as in Link: <compact.css>; rel="stylesheet"; title="compact".

A PGP-based auth-by-URL solution, which is similar to Simon's solution, except with asymmetric cryptography (PKI). The homepage/auth server doesn't need to have a signature verification service, it just needs to publish a public key.
The downside is that more complex computation (with libraries that aren't necessarly provided by most hosting services) is done by the comment server, and the client needs to run some PGP software, instead of a simple bookmarklet with an MD5 javascript library.

Update:
A comment tracking system proposal called talkr.net, based on the flickr authentication service.
The description of SimpleID and it's implementation. SimpleID is not really an authentication solution, mostly a de-centralized form pre-filling system.

I would think that with SimpleID it is already true that you ``have write access'' to your URL by virtue of said URL containing a link to the authentication server.

Furthermore, it is such that regardless of your proposed challenge that the owner of the URL can implement as much or as little security as they desire. Concrete and for example, a port of the FOAF identification server ported to your protocol would need only to cache challenges. No security would be gained. For the security-consious URL owner no gains are added either.

I don't see this as a problem though. Where SimpleID makes it obvious that the integrity of a proof of authentication is relative to an URL, such integrity has always been and will always be relative to the user's security conciousness. In fact, there are only implementation difference between using that FOAF identification server and writing down your MSN passport's username and password on your homepage.

Understanding that FOAF identification server as merely a technical demonstration and not as a secure authentication solution, I have to disagree that SimpleID can not be used as an authentication system.

Of all authentication schemes outlines in your post (which has been helpful by the way), I like the email authentication best because it requires the least thinking on the part of (non-technical) posters. Mind you, I'm possible biased because I've had thought of a similar system myself some time ago.

Ultimately I figure that a succesful scheme will have to support authentication against as much schemes as possible in an as smart way as possible.

It will also need to be extremely easy to setup, perhaps using a mix of SimpleID and that email authentication scheme.

1. User fills in homepage and/or email
2. Check homepage and use SimpleID if possible
3. Email challenge otherwise

The email challenge message could then contain a message like 'Next time you can choose to use SimpleID by entering as homepage the URL http://my-server/simpleid/user@foobar.be and entering the password RandomToken'; in effect automatically creating a user account on some authentication server.

Regards

Thanks for your feedback.

With SimpleID, there is no proof that I have write access to the url. To demonstrate that: I went to Eric Sigler's blog (that supports SimpleID) and posted a message authenticating as himself, using his SimpleID url.
Check out the message posted on March 30th by "Eric Sigler" that says "no security?!" http://esigler.2nw.net/blog/2004/03/11/simpleid

What SimpleID just does is prefill your Profile information from a url. This may be identification but definitely not authentication (the identification isn't verified and secure).

My proposal adds security, and it is up to me (the owner of my identity) to keep it secure. Only the comment server, my website and my authentication server are involved, so only if one of them has a security problem can somebody claim to be me.

The problem with the email authentication system is that it is asynchronous, also the email be lost or spam-filtered out. And an email-based solution doesn't help you by pre-filling the form ;-)

I wish you would have left your email address so we could pursue this discussion. I hope you'll come back (thus the need for tracking comments that we post on other people's sites ;-)

[... Dove's email removed by Dumky. I didn't think foobar.de was your legit domain ;-) ...]

While you're right that currently SimpleID offers no security with its FOAF example, it is absolutely possible to implement a real authentication solution using only the current SimpleID spec. This is, of course, a crucial difference because the reason that you could fake Eric Sigler's identity is that he explicitly linked to the insecure FOAF script from his blog/homepage. Had he instead linked to a script that asked for a username and password then that would have been no easyer to bypass than the proposal you came up with.

It is as you say, up to me (the owner of my identity) to keep it secure, and if I'm using Eric's FOAF example then I'm just not keeping it secure. Again, this has nothing to do with a shortcoming of the spec as I understand it.

You're correct about the downsides of email auth but I mostly see it as a fallback method. For those who don't usually post to blogs, or for when you're on the road and forgot your password.

I had begun explaining why your proposal does not add security but now I think I've noticed some incongruities between your explanation and the drawing. It's 2 AM here so I'll just defer this until tomorrow.

Cya.

[Dove and I clarified the issue by email]

Even if the FOAF file is password protected on your auth server, SimpleID is still easily hackable (ie. the comment server shouldn't consider the authentication secure).
Eric replied to my email confirming this as well.

To sum up:
The comment server challenges you to put a token at the url you claim you own, so that he can later check that you did put it. The url you claim you own should defend itself against anybody but you putting tokens there, and it may delegate all of this to another url (the auth server).

Willison’s method can be viewed as:
Your homepage delegates the authentication responsibilities to an auth server. You share a secret with your auth server. The comment challenges you to prove that you know the auth server’s secret (without revealing the secret) and then verifies the answer you provided against the answer the auth server provides.

Note that the PGP Comment-Authentication scheme offers something that the others don't.

There are situations (rarer, but still common enough) where you (the reader) know and trust the commenter, but not necessarily the blog owner. If you have any doubts about the comment's authenticity, you can always check the PGP signature "by hand." (The "raw" signed comment is available on the signature-verification page.)

The blog owner can't "edit" the comment, or post a bogus one, and attribute it to your friend, under such a scheme.

You didn't like the bookmarklet in Simon's idea: Why has there to be one at all?

My proposition:
You enter the comment, your name and url manually. Then there is a input-field where your enter your secret, press a button next to it that activates a javascript. This javascript takes all the data, merges and md5s it (or however the signatur is generated). The secret code you entered is removed and the signature pasted into the input field.

No more bookmarklet but still secure. Not?

In your solution you write: "they share a secret token [...] which can be used for further trusted notifications." Could you please explain this?

Bookmarklet or client UI is still better in terms of security, because if I enter my key in a webpage, who knows if that webpage isn't going to send a copy of it to the server?
Also, the bookmarklet could contain a "larger" secret (more random bits) than a user could memorize, and the user would just need a simple password/passphrase to unlock that secret.

The idea of using the signature verification to establish a shared secret:
Assume that the verification request contains the following parameters: plain hash of the comment, some random salt and the salted hash of the signature of the plain hash. That "signature hash" is computed by signing the plain hash, salting the result and hashing the whole thing.
The sig server can then use the plain hash to compute the signature. And it can use it along with the salt to check the "signature hash" from the comment server request. It can also generate its own salt and salted hash of the signature, so that the comment server can do a similar check.

Now both the comment server and the sigserver verified that each one of them knew the signature for that given comment hash.
But the comment server didn't reveal the signature, and neither did the sigserver. Yet they both know it and proved it to each other.

So if they can store that signature, it can be used as a shared secret that would allow the comment server to send a secure notification to the sigserver, when a reply is posted on the discussion. Without that shared secret, anyone can ping your sigserver, and in effect spam you.

It's very possible that the "hash of the salted signature of the plain hash" is overkill and there is another simpler way to obtain the same property. Let me know if you have a better idea for that :-)

Oh, your're right. I forgot that the remote Javascript could paste a copy of the secret into a hidden input-field when pasting the computed signature into the old, viewable input-field. Okay - my idea is shit :)

Sorry, I should have accented the "further trusted notifications" in my comment. I only wanted to know what you meant with this, I understood the rest. And now you typed so much... Thank you anyway.
Are there other possible "further trusted notifications" a weblog software could do?

On http://commentstrack.net we are developing something to keep track of comments, and so I'm reading lots of old ideas about authentication, identification and so on. I discovered that your second solution is quite similar to a specification called SORUA (sorua.net). There, one of the readers discovered a possible scenario to attack the system: http://www.sorua.net/stories/259605/#287708 - Perhaps thats also interesting for you.

Oh I just saw "dumky" posted there already... so you know it.

You can use an image authentication. I think that would work nice.

Yes, a simple image authentication is very useful in fact.

You didn't like the bookmarklet in Simon's idea: Why has there to be one at all?

My proposition:
You enter the comment, your name and url manually. Then there is a input-field where your enter your secret, press a button next to it that activates a javascript. This javascript takes all the data, merges and md5s it (or however the signatur is generated). The secret code you entered is removed and the signature pasted into the input field.

No more bookmarklet but still secure. Not?

In your solution you write: "they share a secret token [...] which can be used for further trusted notifications." Could you please explain this?

[Edited] : This is a generated token used to the authentication. The token is associated with the url's poster.

I do not experience big problems with comments, but I agree with previous guys - Image authentication is more simple to use. For sure.

Some other ideas were to have a "filter" or sorts to scan the comments for heuristics to see what the content is, and then reject those.