Slashdot Mirror
LiveJournal Founder Launches OpenID System
geekdreams writes "Brad Fitzpatrick, the founder of LiveJournal, has launched OpenID, an 'actually distributed identity system' for websites that accept user comments. The system utilizes decentralized servers to authenticate users, and aims to replace centralized ID systems such as Microsoft's Passport and SixApart's TypeKey. The first implementation of OpenID can be seen on LiveJournal comments pages." Previously mentioned on Slashdot, now out of development.
Universal hardware tokens. Please.
One of the things I hate about internet is precisely this. Face it, how do you feel when some links in slashdot to a "register for free!" kind of link? I also hate when I go to a blog or a online forum and I'm forced to register, wait for email, login, etc. Most of the time I give up - this thing would fix those problems.
On the surface you might think that this thing would fix those problems but I highly doubt that it will change anything.
Think about it: If the New York Times wouldn't adopt Microsoft's Passport solution do you really think that they are going to adopt this solution by a (in their eyes) virtual nobody? If something with the backing of the largest software company in the World couldn't take off then I don't hold out much hope for this except perhaps for some blogs here and there -- but that hardly solves the NYT problem.
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
So your first argument is that one of the components involved had a security problem? You'd better stop using the internet then, or maybe even your own CMS.
The end goal of this is much more grandiose. One thing that is both a strength and weakness of the Internet is anonymity. Blanket anonymity has no doubt been a plus for many people over the years, but it's now much more of a problem than it's worth. The Internet in general needs a way for the average user to present credentials to internet services that is automated, fast, and simple. This would be a building block for validation of web sites, e-mail messages, decentralized public key distribution, and a lot of other useful (and badly needed) services. Removal of blanket anonymity (but not elimination of all anonymity) will improve the signal to noise ratio of internet data by several orders of magnitude.
That's why that feature of firefox gets disabled by many corporations. It's very insecure. Other options for storing long, non memorable passwords include palm pilots, dedicated password PDAs, and such. They're clunky and sooner or later passwords will become too long to type in anyway. Being able to reference the place to *get* the user's password (along with their encryption settings, public key, etc) is actually more secure.
The Internet is by its nature much more interdependent than you know. It's impossible to do anything online without using at least a few dozen interlinked systems and standards. In general, keeping it simple is a good design rule but it tends to produce simple, monolithic system designs that are unsuited to Internet scale activities. For an example of a large scale distributed service that is as simple as possible on the Internet, check out the DNS design RFC.
This is an over-generalization. True that dependence on proprietary systems is generally bad because proprietary systems are usually not subject to the public evolutionary process applied to open standards, and therefore can have more problems. In general, simplicity triumphs over complexity when two ways of doing the same work are compared. Complexity wins out if a better (faster, easier) way of doing the work happens to be more complex.
I'm presuming you mean people could send e-mails saying "go to this URL". They can do that now. This would actually help with Phishing deterrence if users learned to only trust "verified" e-mail sender identities.
No one liked Passport so that's why it didn't get used. This is a different idea which has a slim, but possible, chance of success.. even on large sites.
I'd have thought the motivation was to limit the number of separate accounts you need. Having a billion accounts running around is a massive security nightmare.
OpenID is meant to allow someone to verify they are who they are by using a Web site that is provably owned by that person. Let's say my LiveJournal id is "ANONCoward" and I want to comment on my friend "CmdTaco", whose blog is hosted on GreatestJournal. OpenID lets me log in as AnonCoward at LJ, then comment on CmdTaco's GJ, using an identifier - my Web site address - and a verifier - my LJ cookie.
However, here is the problem I have with OpenID: My ex-girlfriend, who hates me, signs up on LiveJournal with the ID "AN0NCoward" - with a zero. She copies my entries and backdates them, saves my user picture and uploads it to this dummy journal. (This is one mad woman, and this is not a hyperbole.) Before OpenID, she could just spam my LJ friends. With OpenID, she can probably fool some people most of the time, and most people some of the time, into thinking that she really is me - on GreatestJournal, DeadJournal, and, if expansion is as planned, most TypePad/Moving Type blogs, perl.org, and so on.
Granted, this would take some dumb, gullible people on the receiving end of this kind of kindergarten fraud. But we are talking about LJ here.
Not to mention, of course, that comment spam is already showing up, and unlike anonymous comment spam, there's no IP address tracking, or at least none accessible by the spam receiver.
Actually, as near as I can tell it doesn't "prove" anything. Anyone who learns or knows the URL can pretend to be me on this or any other site. Especially if you're dumb enough to use the subdomain format shown. (e.g. brad.livejournal.com)
Without a private portion (password) it fails at authentication of identity, and devolves to just being "easy"...
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
Except you can run your own OpenID server, and then *gasp* YOU know what sites you connect to. Or, Livejournal knows what sites you connect to (if you use their server), or whatever. NO ONE knows your password, except the OpenID server. NO ONE knows what sites you visited, except the OpenID server. Combine a browser cookie with the OpenID server itself asking you whether or not you want to allow site "www.imgoingtostealyouridentity.com" to have access to verify that you are, in fact, YOU, makes for a pretty safe/secure setup, in my opinion.
Note, also, that OpenID does NOT exchange profile data. OpenID is for Identification. spectral@slashdot.org (if slashdot ran an OpenID server) is guaranteed to be me. There's no information about the man (or woman?) behind the keyboard. It just says "Yup, this is that person".
You have a slashdot account. Why? Why not post everything anonymously? Why not, instead, have one account.. so now you can comment on slashdot, livejournal, the the nytimes website, any of your friends' blog pages (using Movable Type, Blogger, Whatever..), etc... without needing to make an account on each?
This is a GOOD THING.
What if we took this idea a step further and added a form of authentication, namely, signing of messages?
Here's what I have in mind, please point out any flaws in my logic:
- I log into livejournal.com using my id, "hisham".
- I post a message at foo.com using my OpenID, hisham@livejournal.com.
- foo.com sets a cookie in my browser, and issues a request to livejournal.com, with the cookie and the message.
- livejournal.com receives the request, verifies the cookie (confirming that the request from foo.com was posted by a browser who's actually currently logged as hisham in livejournal).
- livejournal.com then signs the message and sends the signature back to foo.com.
- foo.com posts the message saying that hisham@livejournal.com posted it, with the signature in the end (or most likely, accessible through a link).
- If anybody wants to verify if the message is legit, they can copy-paste the message and the signature and check it in a verification form in livejournal.com.
The system is still fully decentralized (anyone can host their own "OpenAuth" servers) and you only need to trust one of the sites (the signer), not both as in OpenID (though "trust" in the sense of OpenID means just identification, not authentication -- and I'm fine with it since that's its purpose).Off the top of my head, the only two potential issues I see are:
- the signer server would see everything you posted anywhere -- but anyway, Google see all my emails... if this is a concern, host your own server;
- the load on the servers -- would this be a big problem? most sites could use lighter, less CPU-intensive cryptography... again, if this is a concern, host your own server with 1024-bit crypto.
What do you people think? Could something like this work??The filesystem is the package manager
Problems with OpenIDI put off reading the OpenID spec because I though it was probably flawed. Now I just feel applying my head to my desk.
OpenID is led by with this philosophy:
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.
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