Atom Authentication (for reference)

[mdlbear]

XML.com: Atom Authentication

I wish I didn't need to write this article. My life would be much simpler if Atom could just use existing HTTP authentication, as-is. But it can't; I'm going to tell you why and then I'm going to tell you what we're doing instead.

It's a simple, secure authentication technique that works when talking to CGI scripts hanging off of servers you don't control, which is convenient sometimes.

It does have a number of drawbacks. It requires the server to know the password rather than a hash of it; that's a problem (though easily fixed). WSSE authentication, which this is based on, may or may not be supported by browsers, though it's certainly easy enough to implement in clients. It's also not at all clear how closely related this is to any current version of Atom; it's dated 2003.

Comments

[technoshaman.livejournal.com]

I assume Atom will work over an encrypted link?

[mdlbear]

Yes, but the authentication mechanism doesn't require encryption, because most hosting services don't provide it. (As the article mentions, https requires a dedicated IP address.)

Encryption isn't terribly useful for a publication protocol except for things like locked posts and limited-distribution comments; I'd be inclined to do those differently. This method is almost ideal for a protocol that uses end-to-end encryption over open links: the client encrypts a file and sends it to a server that then stores it, still encrypted, under a filename derived from the (encrypted) file's hash. Interested clients retrieve it and decrypt it locally. Great for off-site backups, and various forms of limited-distribution publishing.

The place where you need authentication is preventing a denial-of-service attack where the attacker uploads huge amounts of garbage and runs you out of storage space.