Slashdot Mirror

FWIW, lots of the powerful bits that make Movable Type great have been GPL'ed for some time: Data::ObjectDriver, XML::Atom, memcached. And of course, OpenID has been an open standard for a while now, too.

OpenID has made this possible for quite some time now.

How is this different from OpenID, other than that MS displays a massive not-invented-here syndrome?

I'd prefer to see the rise of OpenID. Now if Microsoft gave you an OpenID authentication point with your LiveID (preferably with something simple, like adding the OpenID <link> tags to login.live.com or even just live.com), that would be a feature worth using and supporting. And wouldn't require changing the sites that already support OpenID, including, AFAIK, the SixApart family of blogs.

With modern technology, diverse applications are a good thing (healthier market and better apps from consumer selection). Information, however, is more useful the more widely it can be read and used. Unless you are specifically trying to hide something.

Unfortunately, like Live ID, there seems to be more OpenID providers than servers that use them for authentication.

Livejournal does supports OpenID, which is basically what the site in this article is trying to do. Basically, with OpenID, if you're a member of any site that uses OpenID then you can use that login on any other site that uses it, and thus have access to information on all the participating sites. Livejournal, Wordpress, and AOL.com are a few of the sites that use it. I don't know how much use it gets; I don't think I've seen anyone post on Livejournal that doesn't actually have a LJ account, but then I don't check everyone's username. All those I've clicked on led to real LJs, though.

Livejournal does supports OpenID, which is basically what the site in this article is trying to do. Basically, with OpenID, if you're a member of any site that uses OpenID then you can use that login on any other site that uses it, and thus have access to information on all the participating sites. Livejournal, Wordpress, and AOL.com are a few of the sites that use it. I don't know how much use it gets; I don't think I've seen anyone post on Livejournal that doesn't actually have a LJ account, but then I don't check everyone's username. All those I've clicked on led to real LJs, though.

how hard is it to sign up for a facebook account now.

Why should you have to? There's no good reason to require that I have an account on every damned social web site, for the privilege of seeing what my own friends want to share with me.

I'll say that again: the customers of the web site want to share things with their friends, and the current structure makes that hard. Social networks aren't providing their users with what they want.

I'm all in favor of using a distributed identity system like OpenID so that a facebook user (for instance) can name their friends regardless of whether those friends are also facebook users, and allow those friends to see their profile/blog/videos/whatever.

Sounds like the exploit relies on auto-enter password fields for a domain, and then using javascript to transmit the value of thte password field to the attacker's machine. So, not so much a coding error as a flaw in the thinking that any password field on a site should be auto-filled in. Requiring some action on the part of the user would help with this, but a better solution would be to move to openID.

There are ideas around.. Check:
http://www.foaf-project.org/
http://openid.net/

The OpenID tells me totally different story. you can read it from here: http://openid.net/about.bml. (In short, it doens't prevent the bad people from using is).

These aliases are truly, and only, thinly veiled disguises. Unless you use aliases like a one time pad.
The proof is all through my post, at this point I must stop this charade.
I shall at some time be found out for who and what I truly am.
A very well trained Great Pyrenees. [I work for a Shepherd]
Fravia says it best [fabulous site]:

http://www.searchlores.org/noanon.htm

http://www.searchlores.org/fobegano.htm

BONUS !

http://www.searchlores.org/trolls.htm

I really like the idea of OpenID

http://openid.net/

I think it would further a type of "vetting" or track record for such discourse that requires it / be enhanced by reputations. A HOSTS file of sorts like the academics of ARPANET lore. [I was but a pup]
So, tell me whose advice would you trust concerning sheep herding? Hmmmmm? I chase them for a living, hence, you could trust my advice.

Otherwise:

http://digg.com/

For those of you that think me just another lap dog, I say, ... If only!

http://www.gailgiles.com/Jack.jpg

[I like CATS (Broadway version), long walks in the meadow, old shoes, Slashdot, ...]

You might consider using OpenID for stuff like this. I really hate having millions of passwords for millions of different sites.

Which is all the more reason to make sure that no software ever has a really huge user base. It's bad for everybody.

Right now, one major thing that keeps Myspace's user base so incredibly high is the lack of a widely adopted technology like OpenID. Many people get Myspace accounts because they're forced into it in order to communicate reasonably with a friend, and then decide "Oh, what the heck." and build content of their own there as well. I know that's why I have a MySpace account (and, strangely enough, Omnifarious on MySpace isn't me).

What's the difference between the Higgins project and OpenID?

Actually, the problem is that the OpenID specification is very poorly written and is extremely complicated. It's as though a couple of kids wanted to put together an RFC but didn't really understand how to express a specification is a logical form. If you don't believe me, just take a look; you'll see what I mean just by glancing through it: http://openid.net/specs/openid-authentication-1_1. txt

Anyway, then, as kids are wont to do, they have followed it up with a series of new specifications, each one more complicated than the last. There are five specifications in draft form right now, each to cover some different aspect of what should be a fairly simple protocol. They reference and make use of HTTP, HTML, XHTML, XML, XRIs, XRDS, S/MIME, XSLT, and some other, similar ID specification called Yadis. Implementing all this thing requires gobs of software libraries (each with security holes and bugs) and expertise (and who has time to learn the latest X??? spec?). And we're supposed to believe that it's possible to do this securely? We can barely make secure web servers, much less SSI systems which require almost 100 pages of specifications, plus thousands of pages of supporting specifications!

What's sad is that the authors are not just a couple of kids that discovered XML and had a field day. The authors are associated with companies. The primary author works for VeriSign. Presumably, he should know better than to make such a jumbled mess.

But I think we all know what's really going on here. These idiots put together an incomprehensible specification. It is poorly defined, ambigious, and relies on lots of supporting technologies. It is impossible to implement securely, completely, and correctly. Security holes and interoperability issues will be the only real standard. And guess whose jobs are secure? Guess who gets lots of contracting jobs? Guess who is needed to write new specifications so that they can get it Right the next time?

It's too late to turn this one around. Hopefully OpenID will die a horrible death and we'll never hear of it again. But please, please, if anyone else reading this feels compelled to write a specification in the future, learn from OpenID's mistakes and keep it simple, stupid. Because OpenID is setting itself up for disaster.

Your knee is jerking. You're reacting to the centralized authentication systems like MS Passport that we've seen in the past, which would indeed make it easier to track people. OpenID is fundamentally different in that there is no one centralized identity provider. You can use AOL as your OpenID provider, or another provider, or even set up your own OpenID server on your own hardware and use that if you can't find one you can trust -- hard to think of a scenario that would be more tracking-proof than that. Read more about OpenID, it's not what you think it is.

Has anyone got any precise insight on the difference between OpenPrivacy and OpenID goals? :)

There are two parts to this - one is getting a list of which web pages contain the search terms, and the second is ranking them. The first is easy (ish) to achieve. For the second, rather than fancy algorithms like Google page rank which can be manipulated by SEO, just let the people decide. Everyone gets to vote just once on the ranking for a particular web page. To prevent abuse make use of something like OpenID to authenticate users. Sure you might see very popular pages at the top of the list that don't have much relevancy but better that than the current system and anyway suitable choice of keywords should filter out most of the fluff.

Has anyone got any precise insight on the difference between OpenPrivacy and OpenID goals? :)

The wikipedia entry is quite informative. With OpenID, unlike XNS.org (for those who remember), you need an 'identity provider': A service provider offering the service of registering OpenID URLs or XRIs and providing OpenID authentication (and possibly other identity services), and here's the official list of identity providers. And while we're at it, the list of services that support OpenID.

I mean what's new in this compared to current LiveJournal's OpenID ?

The hard work would appear to be done already:
OpenID http://openid.net/
FOAF http://www.foaf-project.org/

It sounds like I could get Sharepoint by installing MoinMoin, Word Press, and integrating the two with something like OpenID for single sign-on.

How is this some spectacular whizzy thing that nobody else is doing? Could you please enlighten us all as to what makes it so fantastically juicy to the CIO set?

They can try, and good luck to them if they do, but OpenID is an open standard (hence "Open" in the name) created by people with no relationship to Verisign. They can't co-opt it any more than they could any other free, open standard out there, and you can use OpenID service from any provider you want.

Personally, I think it's great that they've adopted it. The more organizations using it the better. I don't plan to use them for my OpenID service -- I already have it elsewhere -- but their name will hopefully help it gain momentum with others.

The problem is, it won't be only sites you don't care about using it.

Yes, it will be.

OpenID is not intended for eBay, Amazon, or anything else where money changes hands, or that otherwise requires absolute identity, tied to a physical human being in the real world. OpenID does not (and is not intended to) establish absolute identity; its goal is to establish relative identity among multiple websites where absolute identity isn't so important.

See also their FAQ of sorts, second heading.

I'm glad to announce, that I have installed a new OpenID Server for anybody to use. This is a supper-trooper and absolutely cool OpenID server, since it doesn't require you to sign up, register or anything...Total privacy! You can choose any user name and change the name every time if you wish, all you have to do, is to provide at LiveJournal or other blog/forum, a URI like http://123.no-password.com...everyhting/ works, no questions asked! You can even choose a user name somebody else used previously. This is specially interesting, since viagra.no-password.com will become reusable...

I simply downloaded one of the libraries from the OpenID web site and removed any authentication checking (patch available), so that when you have to authenticate with no-password.com the web site simply post's you back to LiveJournal with is_valid="true". Also I removed the association for shared secrets with the RP, since there is nothing here to protect and completely optional according to the specs. This makes no-password.com the fastest OpenID server, since we don't use SSL and have no need to create the assoc_handle. I'm sure we gained about 10 milliseconds on this! BTW, did I tell you, that no-password.com is completely private and anonymous? Any log files created by the server are directed to /dev/null so that any traces of your visit at no-password.com are destroyed immediately! This is much better that the PiP offered from Verisign, since they probably keep log files and make back ups of their databases ;-) and because according to the specs the IdP establishes whether the End User is authorized to perform OpenID Authentication and wishes to do so and the manner in which the End User authenticates to their IdP is beyond the scope of the OpenID Authentication 2.0 Specifications, all users are authorized at no-password.com without questions asked. Cool, isn't it?

I'm sure you now understand how useful the OpenID framework is and you decided to add OpenID login to your forum immediately. There are no requirements on your part, but you should....well, really you should make a small form at your forum, so the user can enter the no-password.com URI. It's also recommended that you place the OpenID logo
However, I'm not sure, if I'll keep no-password.com, since I just bought it and can return the domain within 10 days without getting charged. Anyway, perhaps I'll get another one (no-questions-asked.com is free) in ten days....I'll keep you updated on this!

Source: http://openid.net/pipermail/security/2006-November /000165.html

I'm glad to announce, that I have installed a new OpenID Server for anybody to use. This is a supper-trooper and absolutely cool OpenID server, since it doesn't require you to sign up, register or anything...Total privacy! You can choose any user name and change the name every time if you wish, all you have to do, is to provide at LiveJournal or other blog/forum, a URI like http://123.no-password.com...everyhting/ works, no questions asked! You can even choose a user name somebody else used previously. This is specially interesting, since viagra.no-password.com will become reusable...

I simply downloaded one of the libraries from the OpenID web site and removed any authentication checking (patch available), so that when you have to authenticate with no-password.com the web site simply post's you back to LiveJournal with is_valid="true". Also I removed the association for shared secrets with the RP, since there is nothing here to protect and completely optional according to the specs. This makes no-password.com the fastest OpenID server, since we don't use SSL and have no need to create the assoc_handle. I'm sure we gained about 10 milliseconds on this! BTW, did I tell you, that no-password.com is completely private and anonymous? Any log files created by the server are directed to /dev/null so that any traces of your visit at no-password.com are destroyed immediately! This is much better that the PiP offered from Verisign, since they probably keep log files and make back ups of their databases ;-) and because according to the specs the IdP establishes whether the End User is authorized to perform OpenID Authentication and wishes to do so and the manner in which the End User authenticates to their IdP is beyond the scope of the OpenID Authentication 2.0 Specifications, all users are authorized at no-password.com without questions asked. Cool, isn't it?

I'm sure you now understand how useful the OpenID framework is and you decided to add OpenID login to your forum immediately. There are no requirements on your part, but you should....well, really you should make a small form at your forum, so the user can enter the no-password.com URI. It's also recommended that you place the OpenID logo
However, I'm not sure, if I'll keep no-password.com, since I just bought it and can return the domain within 10 days without getting charged. Anyway, perhaps I'll get another one (no-questions-asked.com is free) in ten days....I'll keep you updated on this!

Source: http://openid.net/pipermail/security/2006-November /000165.html

I'm glad to announce, that I have installed a new OpenID Server for anybody to use. This is a supper-trooper and absolutely cool OpenID server, since it doesn't require you to sign up, register or anything...Total privacy! You can choose any user name and change the name every time if you wish, all you have to do, is to provide at LiveJournal or other blog/forum, a URI like http://123.no-password.com...everyhting/ works, no questions asked! You can even choose a user name somebody else used previously. This is specially interesting, since viagra.no-password.com will become reusable...

I simply downloaded one of the libraries from the OpenID web site and removed any authentication checking (patch available), so that when you have to authenticate with no-password.com the web site simply post's you back to LiveJournal with is_valid="true". Also I removed the association for shared secrets with the RP, since there is nothing here to protect and completely optional according to the specs. This makes no-password.com the fastest OpenID server, since we don't use SSL and have no need to create the assoc_handle. I'm sure we gained about 10 milliseconds on this! BTW, did I tell you, that no-password.com is completely private and anonymous? Any log files created by the server are directed to /dev/null so that any traces of your visit at no-password.com are destroyed immediately! This is much better that the PiP offered from Verisign, since they probably keep log files and make back ups of their databases ;-) and because according to the specs the IdP establishes whether the End User is authorized to perform OpenID Authentication and wishes to do so and the manner in which the End User authenticates to their IdP is beyond the scope of the OpenID Authentication 2.0 Specifications, all users are authorized at no-password.com without questions asked. Cool, isn't it?

I'm sure you now understand how useful the OpenID framework is and you decided to add OpenID login to your forum immediately. There are no requirements on your part, but you should....well, really you should make a small form at your forum, so the user can enter the no-password.com URI. It's also recommended that you place the OpenID logo
However, I'm not sure, if I'll keep no-password.com, since I just bought it and can return the domain within 10 days without getting charged. Anyway, perhaps I'll get another one (no-questions-asked.com is free) in ten days....I'll keep you updated on this!

Source: http://openid.net/pipermail/security/2006-November /000165.html

I am getting all of my data about this system from http://openid.net/about.bml. There it says that the foreign server B asks my local server A if server B is designated as "allowed." If A says that B is allowed, B believes that I'm me and lets me continue. Otherwise B says, "Uhm, A doesn't know wtf you're talking about. You'd better go register me on A."

So I go register B on A, right? And now all I have to do to login is type larko.A.com into the little login box on B?

Why can't SpammerX type in larko.A.com now?


Maybe there's more information about this deeper in the site that I didn't see, or maybe I'm an idiot. Anyone know?

Rogue OpenID providers are dealt with by configuring your OpenID consumer not to trust that server anymore.

See "what about spam?" on the OpenID project's About OpenID page.

I loathe CAPTCHA, although I may end up implementing it on my system. I could also be convinced that a "which of these N pictures are kittens?" test might work.

I run a small old-school weblog on my own content management system. Middling PageRank (6 or so), a couple of hundred readers. I just had the spambots discover my Wiki, but in the process of cleaning up that mess I was shocked and amazed by the emergent behavior I'm seeing in spambots. Every form on my site that could get random info plugged into it, including search fields and new user account information; I'm going to have to make new user accounts far less easy to get. All of a sudden I'd ballooned from under a thousand registered users to forty-five hundred.

I don't like verified email accounts, and I think those are going to get attacked fairly soon too, but some sort of way to more strongly tie an identifier to an actual human has to fit into the mix.

One of the things I'm excited about is the notion of cross-site identifiers, like OpenID, and distributed reputation. Something that lets my site collaborate with other sites and say "I trust this URL". Users will still have to jump through the "are you a human" test, but will only have to do so once within the confines of a trust network.

You mean something openid?

also, your website spits out this:

Warning: main(inc/header.inc): failed to open stream: No such file or directory in /home/groups/a/ap/appleseed/htdocs/index.php on line 2

Warning: main(): Failed opening 'inc/header.inc' for inclusion (include_path='') in /home/groups/a/ap/appleseed/htdocs/index.php on line 2

The spec I'm reading uses three servers, none of which are authenticated. It also uses plain old HTTP, which is wide open to tampering.

So, the system is vulnerable to at least DNS poisioning (or simply a domain expiring) and man-in-the-middle attacks in several places:

• Consumer fetches the identity page
• Consumer contacts the server
• User-agent contacts the server

The protocol has an "associate" mode that provides some semblance of authentication, but it seems to be temporary (OpenID::Server in CPAN defaults to 14 days). There's also this bit in the protocol that blows it away: "if you use an assoc_handle the server doesn't know about, it'll pick its own and you'll have to use dumb mode as well."

My bank, on the other hand, uses SSL or TLS with an X.509 certificate signed by another company whose sole purpose is to verify identities. If I don't trust that, I can at least check the certificate fingerprint every time I connect (like SSH), so I verify that I'm connecting to the same server. As for authenticating myself, I present information that only I should know (this part is weakest). There is authentication, encryption, and integrity.

I'm not asking for a full-blown PKI; simply verifying that each machine is the same would probably be sufficient. Encryption isn't necessary because the information transferred (your OpenID server and the answer it gives) is not confidential.

IE has password memory. So does Mozilla / Firefox, Opera, Safari, and a host of other browsers. It's a feature to make it easier to access sites, but users with high authentication should know that that ease comes at a cost of security. Admittedly many non-IE browsers have a "master password" structure whereby you type one password for it to remember all of your passwords on demand (as mentioned by a sibling post about Safari), but said poster also recognized that most of these systems ship with the feature off by default, and even if it is on, you're still doing a balancing act with security and ease -- if a cracker finds your master password, they've found ALL your passwords.

And I believe you're referring to FindFast, Microsoft's indexing tool that they shipped with Office. As I remember it, FindFast indexed documents (i.e. Microsoft Word, Excel, etc. files) so they could be found easier later, as well as have quicker in-file searching (i.e. searching for a word inside all your documents). It never stored your domain passwords or any such security-related tokens. Once again, though, you're only screwed if you put your password inside a Word file in your system... and why the hell would you do that if you're concerned about security? (P.S.: Anyone who had even a bit of technical acument would turn FindFast off back in the time when it was used, as it made your system horribly slow when it was indexing and tended to do so at inopportune times.)

Passport only works on sites that explicitly choose to support it, and generally only if you register yourself that way: most will give you an option for a registration in their site database only (eBay did this previously if I remember correctly). Several alternatives have been attempted at Passport-like solutions as well, to be fair, including some open source options. Once again, Microsoft isn't forcing you to use their solution, and I doubt a lot of systems use Passport authentication for high-level access anyway.

Normally I wouldn't be so argumentative, but you made a sweeping generalization when you said that "non Microsoft tools have taken local and remote attack into consideration". You made your bias quite clear in that statement. Next time you want to post attacks, at least back them up with some proof or evidence.

Anyway, I have yet to form an opinion on this InfoCard thing, but seeing as how it'll likely be Microsoft-proprietary and they'll probably have something to gain from it, I doubt I'll be either signing up for one (unless I have to in order to access a system, and even then I'll resist quite vocally) or deploying it on my own login systems.

Well, microsoft tried that with the "passport" - of course, nobody uses it.

There's also Open ID http://openid.net/ which is trying something similar, but I don't know if its going anywhere.

Google should probably do something like this, people would actually be likely to use it.

If there were someone running an OpenID site that had an accessible but spammer-unfriendly login mechanism, that site could serve as an alternative login for visually-impaired users. That admittedly just punts the issue, but the nice thing about that solution is that if there was a trusted site that most blind people would feel comfortable registering with, that site could vet the visually impaired. The OpenID solution wouldn't have to be limited to the blind, but that seems the easiest bootstrapping mechanism, as the blind are probably more motivated to promote/use something like OpenID than people who are perfectly happy with Captcha.

Rob

Exactly. When LiveJournal has technical problems for a few days, people don't leave LiveJournal en masse -- they wait it out. Because the whole point of being on LiveJournal is the community. Their friends, readers, etc. are all on the same service, and moving to a new one is going to involve dragging them along. On the other hand, if you and a bunch of friends do decide to leave, you'll probably end up migrating together.

Ever tried using a LiveJournal account to comment on a Myspace blog? Not gonna work. (Ironically, the people behind LiveJournal are the ones who set up OpenID, which may make this possible some day.)

This is, of course, a generalization. You can find blogs on LiveJournal, TypePad, Blogger, etc. that are aimed at a general audience and have simply chosen a hosting provider. But in most cases, you'll find that the active readers -- the ones who hold conversations in the comment threads -- are all on the same blogging service.

This is an upside to OpenID.
Nicknames can clash, doesn't matter.

Because domain names won't.

Yes, I realize this won't make a difference with WoW, but on the subject of 'identity' in the rest of the web world, this is very applicable.

I thought about this a while back. I couldn't think of a way to solve the "i don't know the ip address" and dynamic ip problem...then I saw openid.

OpenID is not ideally suited to IM, but the idea of using an XML file on a website as your identitiy could be adapted to instant messaging fairly esaily.

One day, when I have a bit more free time, I will have another play with this idea - sort out thigns like authentication and identity checking (so that user A can confirm that user B is who he says he is)

How is it that no one has mentioned distributed identity protocols, such as Open ID? That would solve the problem for the web, at least.

could potentially have enabled the forces of computing darkness to obtain the username and password of every registered SpreadFirefox user, as well as any other optional information that users may have provided

I argued that this should be a prime reason for OpenID or some other distributed authentication system should start being used on the web. That way, you never have to give any unnecessary sensitive information to any website.

The point of OpenID is to be dead simple, short-comings and all, so it's actually adopted.

The above is taken from a discussion of vulnerabilities. The problem with this lowest common denominator approach is that it's horribly broken. OpenID is currently no better than just giving the URL of your blog.

The number one problem is the complete lack of integrity checking. Everything in OpenID seems to be perfectly happy to let their requests be modified in transit. I think the problem with this are pretty damn obvious: nothing can be trusted. Fortunately, fixing this is pretty simple: use TLS. In today's shared hosting environment, you probably want to require support for server name indication.

Another brilliant idea: transmit the key that you'll use for signing later in plaintext.

Yes, you can ask for DH-SHA1 encryption and get back a plaintext secret. If this troubles you, don't use the handle and instead use dumb mode with that server. (and if somebody sniffed the plaintext secret, it won't matter, since you'll never accept queries using that assoc_handle). If the server can't do DH, it's probably limited in some way, but using dumb mode is still safe, if not a little slower.

I believe "limited in some way" means "completely insecure." "Dumb mode" is not safe because there's no key associated with the server, so there's no way to ensure you're talking to the same one or that someone isn't tampering.

I also don't see much point in using a symmetric key for speed and security when you're just encrypting a short string. It's so tiny that both improvements are similarly small.

Perhaps the biggest problem with OpenID is it's reliance on sending a user to another page to login. It's just too easy to spoof a page and fool most people. Even better, you can open a window using Javascript and hide the location bar. Even if you normally use TLS, most people probably won't notice if it's missing or the certificate is different. Also, most sites (including LiveJournal) include a completely insecure assurance that you're secure. For example, LiveJournal says "LiveJournal Secure Site "

A simpler and more secure alternativeThe only way to fix this is (gasp) get users to carry their own keys. If you stored your key in a bookmarklet or extension, you could sign something with it. This is completely feasible because Javascript cryptography implementation is done. You could submit your public key with the signed comment. If you wanted to associate yourself with a URL, all you need to do is link to a page with the public key. If the same public key can be used for the signature.. That's right, no special identity server is needed. The public key could be submitted directly or it can be linked to. It might be a pain to write out the entire URL to the key, so perhaps autodiscovery-from-HTML should be supported:
<link rel="openpgp.key" href="http://www.livejournal.com/pubkey.bml?user=a trustheotaku" />
Note that no TLS is needed. The signature is secure in and of itself. If you want to support all the fanciness (e.g. revocation) of OpenPGP (spec), then you just need the

The point of OpenID is to be dead simple, short-comings and all, so it's actually adopted.

The above is taken from a discussion of vulnerabilities. The problem with this lowest common denominator approach is that it's horribly broken. OpenID is currently no better than just giving the URL of your blog.

The number one problem is the complete lack of integrity checking. Everything in OpenID seems to be perfectly happy to let their requests be modified in transit. I think the problem with this are pretty damn obvious: nothing can be trusted. Fortunately, fixing this is pretty simple: use TLS. In today's shared hosting environment, you probably want to require support for server name indication.

Another brilliant idea: transmit the key that you'll use for signing later in plaintext.

Yes, you can ask for DH-SHA1 encryption and get back a plaintext secret. If this troubles you, don't use the handle and instead use dumb mode with that server. (and if somebody sniffed the plaintext secret, it won't matter, since you'll never accept queries using that assoc_handle). If the server can't do DH, it's probably limited in some way, but using dumb mode is still safe, if not a little slower.

I believe "limited in some way" means "completely insecure." "Dumb mode" is not safe because there's no key associated with the server, so there's no way to ensure you're talking to the same one or that someone isn't tampering.

I also don't see much point in using a symmetric key for speed and security when you're just encrypting a short string. It's so tiny that both improvements are similarly small.

Perhaps the biggest problem with OpenID is it's reliance on sending a user to another page to login. It's just too easy to spoof a page and fool most people. Even better, you can open a window using Javascript and hide the location bar. Even if you normally use TLS, most people probably won't notice if it's missing or the certificate is different. Also, most sites (including LiveJournal) include a completely insecure assurance that you're secure. For example, LiveJournal says "LiveJournal Secure Site "

A simpler and more secure alternativeThe only way to fix this is (gasp) get users to carry their own keys. If you stored your key in a bookmarklet or extension, you could sign something with it. This is completely feasible because Javascript cryptography implementation is done. You could submit your public key with the signed comment. If you wanted to associate yourself with a URL, all you need to do is link to a page with the public key. If the same public key can be used for the signature.. That's right, no special identity server is needed. The public key could be submitted directly or it can be linked to. It might be a pain to write out the entire URL to the key, so perhaps autodiscovery-from-HTML should be supported:
<link rel="openpgp.key" href="http://www.livejournal.com/pubkey.bml?user=a trustheotaku" />
Note that no TLS is needed. The signature is secure in and of itself. If you want to support all the fanciness (e.g. revocation) of OpenPGP (spec), then you just need the

Ok I'm sold! I already thought it was a good idea, but the best part is, if you are worried about the stability of an OpenID server [and want your personal URL] it is convenient even if you don't have the ability to run your own OpenID server! You can just DELEGATE! Enter your personal URL, but it will do the actual identification from whatever OpenID server you point it to [say livejournal]. That way, if LJ [or your chosen OpenID server] goes away, you simply change your delegation to point to another OpenID server [where you will need an account of course], but you will still have your own URL as your identity. You don't have to change it just because your OpenID server doesn't exist anymore. Very nice!

On the http://openid.net/ page, it suggests that untrusted websites might popup a login dialog for your own trusted server. That would open a huge hole for man-in-the-middle attacks based on the various browser "url hiding" vulnerabilities. The fact that that behavior is suggested as canonical seems unwise.