hmmm ... lots of thoughts about both your recent posts mostly along the lines of "we kind of already have this" ... better/more open standards and better/more open source software can help make these things more resilient.

Also, we should get together some time and I'll sketch out my "how to build an open twitter" architecture idea which might be interesting...

--sstrudeau

Asking people to decrypt data and send it back via OpenPGP might be vulnerable to some nasty attacks: for instance, if i knew that someone had just sent you an encrypted message that i wanted to read (and i'd sniffed the message on the network), i could just give you the encrypted message as something to decrypt. You'd then face the choice of either decrypting the message and sending me the cleartext, or failing to authenticate. Worse, if you didn't read what you had decrypted before sending it back, you might not even know that you'd given away the secret!

It also allows for a proxied attack: say i control a server (A) that you log into. I want to pretend that i'm you to a server (B) that i have no control over, but uses the same protocol. When you ask to log into A, i have the server immediately pretend to log into B as you, and fetch the encrypted challenge. I feed you that exact encrypted challenge, you decrypt it, and offer it to me. I pass it back to B, and can now operate as you on that server.

Better would be to provide a short token to the end user, and ask the user to sign it. The token should contain the requesting URL, the current timestamp, and probably a random string (a so-called "nonce value"). The user could then append text of their choice to the token, and then sign the resultant string and return it. These elements are important because:

requesting URL

you don't want arbitrary sites to be able to re-use the signed to "authenticate" as you with the same signed token.

timestamp

this is another measure against replay attacks: you wouldn't want someone sniffing this transaction to be able to replay it later against the same server

nonce value

This allows you as the user to control specifically what you're signing. This way, even if the underlying hash used is compromised (i.e. the server can create two messages which hash to the same value, one of which looks like a legit challenge, and the other looks like a message that the server wants to pretend that you've signed), you can append your nonce value before signing, so that you're effectively choosing the hash to sign, not the remote server.

Once you see this whole framework, it starts to make more sense for the challenge to be a standardized one based on the requested page. This would allow a client-side implementation that wouldn't require an explicit challenge from the server at all.

An interesting attempt to implement this model is mod_openpgp, coupled with the enigform browser extension. Getting this sort of authentication built into the browser/server combination cuts down on the amount of manual goofiness each user needs to tolerate to get it to work.

I'm too tired to address your distribution and aggregation sections right now, but i hope this is good food for thought at the moment, anyway.

--dkg

Thanks dkg for those pointers - about the dangers of the authentication model I suggested - and for pointing to mod_opengpg and engiform - that's really promising stuff!

OpenID has the advantage of working with any browser - but the gpg approach to authentication ultimately seems like the best way to go.

--jamie

I really love it when I post a message saying how the world needs X and then someone comes along and points out how X already exists :)!

As for twitter - Are you referring to twitter.com? I never heard of it, but just read a quick over view. It looks interesting, but still trying to wrap my head around what it does.

--jamie