Slashdot Mirror

← Back to Stories (view on slashdot.org)

LiveJournal Founder Launches OpenID System

Posted by ryuzaki0 on from the who-are-you? dept.

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.

11 of 172 comments (clear)

  1. Re:Not really that good, IMHO. by outZider · · Score: 4, Informative

    Just as an aside, the XML-RPC vulnerability was based on items in the PHP community, and not in the module used within Perl. Danga and the LiveJournal team have been working with XML-RPC for quite some time, and they tend to be nazis about the security of their implementation.

    --
    - oZ
    // i am here.
  2. Re:Rivalry by Ingolfke · · Score: 2, Informative
    Although he's competing it sounds like he's also willing to cooperate with SixApart
    TypeKey -- Centralized registry. Not everybody trusts SixApart to control their identity. (But if you already use TypeKey, there's a good chance a future version of TypeKey will also be an OpenID server... I'm pushing for it at least, and volunteered to do the work.)

    and his comments about spam and trust lead one to believe that these are area's SixApart's service could fill.
  3. Re:Not really that good, IMHO. by Xepo · · Score: 4, Informative

    First of all, look at the reason this was created. There are hundreds of livejournal clones out there, and a lot of them run the livejournal software (deadjournal, blurty, etc.). I'm not going to create a new journal on each one of those sites just so I can view the friends-only posts of my friends on those sites, and especially not just so I can comment. This provides a way to link all of those sites together, and it does it openly, in a way that sites that don't use LJ's software can use.

    Secondly, addressing your remember passwords comment, it's a complete waste of resources for the system for these users, who just may want to leave a comment, to force them to sign up for an account. Why not just let them provide a reference URL which represents them, and let that server verify that the provided URL is the user's?

    Many of your points were simply "This is complex", or "This requires relying on more systems", and conclude that it's bad. Firstly, I think 'rely' is the wrong word for this. You're using these other systems, yes, but if these other systems go down, it doesn't stop you from doing anything. It's similar, though not a perfect analogy, to saying that having more IRC servers in a given network is bad because you're relying on more servers.

    Also, imagine the advantages this gives when designing around this system. Forums which are really only for one topic, such as an official forum for a specific piece of software, don't even need to store any user or password information (and therefore don't have any sensitive data). The forum can simply store the OpenID URL for the admins and allow anyone who can verify with that URL do all of the admin work.

    It's the first step to providing a true roaming profile, and single sign-on for the web, and it's done in an open manner. I think it's a step in the right direction.

  4. Re:Insecure by design by Ingolfke · · Score: 2, Informative

    I am in total agreement with you, but such a system would be a frequent target for identity theft attacks. Therefore such a system should have multiple biometric security measures, including fingerprints, DNA, retnal scans, and voice samples.

    Such a system would be the foundation of a new set of services as well. For example, if all the citizens of the world would wear a GPS transmitting necklace or under-the-skin implant no one would ever be wrongly accused of a crime or be accidentally lost in the wilderness. With bio-scanning technology the government could ensure that you're vital signs were normal and if they became erratic they could send aid.

    Only with a wonderful benevolent government like the United Nations can we ever begin to see the wonders of these technologies and rid ourselves of all the risks of the dangerous ideas of freedom and privacy.

  5. Re:A good Idea... by kurtras · · Score: 2, Informative

    Did you even read any of the linked materials? No part of the OpenID system stores your personal details. The only thing OpenID does is allow you to prove that you own a URL. There is no such thing as an 'OpenID profile'--an OpenID producer and consumer just don't exchange that kind of information.

    And if you read the specs, I think you will see that OpenID is designed from the ground up with security in mind.

  6. Re:The point? by jfengel · · Score: 4, Informative

    Captcha solves a different problem. Captcha proves that you're a human (more or less). OpenID proves that you are you. That doesn't prove that you're a human; it just proves that you know a password. But since you're the only one who knows that password, you're uniquely you and you don't have to create a separate account on each system you visit.

    So it's a convenience for users, not to prevent spammers. This does have spam implications: you can blacklist/whitelist ID servers and you don't have to give your email to every site you visit, but it's not really about preventing spam. It's about simplifying the mass of passwords and accounts you have.

  7. Re:What this is actually good for by annodomini · · Score: 2, Informative
    What this is good for is being able to say "I trust comments posted from LiveJournal, SixApart, Yahoo, MSN, Google, and Mac.com users to not be spam." (this isn't a list of places that support this yet, just a random list of large providers that could support it). Then anyone who has an account from those providers can log into your blog and post comments that are authenticated as being from them. Have problem with too much spam from some domain? Blacklist that domain, or remove it from your whitelist. Now, instead of every user who wants to post on your blog having to create a new account, they can just use their account from one of the sites that supports it.
    ... you have no definitive authority to say "this user is who he/she says they are."
    You do have a definitive authority; their identity is a URL, and you ask the server if they really are who they say they are. You do this by going to the URL, looking for a META tag that specifies the identity server to use, and having a talk with that identity server. On LiveJournal, the only major site that actually implements this, your identity is simply the address of your journal, so if your username is foo, your identity would be livejournal.com/~foo (or livejournal.com/users/foo, or foo.livejournal.com if you have a paid account; there is no effort to give everyone a single unique identity). Read the article for the details.
  8. Re:A bad idea... by kurtras · · Score: 2, Informative
    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)
    Not really. After you enter a URL in an OpenID login box, the OpenID producer will confirm that you've already logged in to the producer site. OpenID is essentially a single sign-on solution. You log in to the producer site once, then you can use your URL to log in to any OpenID consumer site.
  9. Re:We just need to kill passwords by CoughDropAddict · · Score: 2, Informative

    1. Tokens don't imply a database of owners -- it's just a way to prove that you're talking to the same token you talked to yesterday. Instead of asking you to create a username and password for an account with a web site, it would ask you to insert your token.

    2. No -- done right, a hardware token would have a private key that never leaves the token. It would authenticate itself by signing challenge data on command.

    3. The private key would never leave the device. It would erase its memory if tampering is detected (there are devices that do this today).

  10. Re:Not really that good, IMHO. by spectral · · Score: 2, Informative

    That is precisely what OpenID isn't. They mentioned that there's no profile exchange.. OpenID just makes sure that shakrai@slashdot.org is that person. Doesn't say anything ABOUT that person.

    They wanted ot keep the protocol simple and easy. Another layer can be added on top of it, later on, for profile exchange.. but they specifically avoided doing it in this version.

    The problem with profile exchange is, it's hard to maintain. Once you give them information, they can keep it. If you only give them an OpenID, that's all they know about you, unless you give them more. Which most sites will probably ask for anyway. I'm sure the NYTimes wants you to login for demographics, not because they want to verify that you are who you say you are before you read a story. They have no way of knowing anything about shakrai@slashdot.org, besides what you visit. But if you make an account there, they have your name, address, age, gender, etc. AND what you visit at their site .. OpenID is not meant for this.

  11. read the spec, dude by CoughDropAddict · · Score: 2, Informative
    I recommend you take the time to read and understand a spec if you are going to claim it is broken in blatantly obvious ways.
    Step 5: Consumer checks the identity, via the User-Agent

    Now the consumer constructs a URL to the identity server's openid.mode=checkid_immediate (or checkid_setup) URLs and sends the User-Agent there. By sending the User-Agent there, the user's cookies and whatever other login credentials are sent back to their trusted identity server. The server does its work, appends its response onto your supplied return_to URL, and sends the user-agent back at you.
    Breaking that down:

    1. Say your home URL is www.slashdot.org/~shmlco. You log into slashdot.org, and slashdot gives you a cookie as it always does. This is how slashdot verifies you are logged in.

    2. You go to randomblog.com. You want to post a comment as shmlco from slashdot. So you give randomblog.com your URL, www.slashdot.org/~shmlco.

    3. randomblog.com establishes a shared secret with slashdot.org cryptograhically, if it has not done so already.

    4. randomblog.com sends your browser to whatever authentication URL is specified in the link tag of your site, for example: <link rel="openid.server" href="http://www.slashdot.org/openid-validate.cgi" >

    5. Your browser hits www.slashdot.org/openid-validate.cgi, which can validate that you are logged into www.slashdot.org (just like any slashdot page can), based on your cookies.

    6. If you are logged in, slashdot.org signs a certificate saying so, using the shared secret as a key, and redirects you to someblog.com with the signed certificate as one of the parameters.

    7. someblog.com decrypts the certificate, and therefore knows that your browser is signed into slashdot.org.

    As you can see, your proposed attack could not work, because you don't have the victim's cookies in your browser, nor do you have the shared secret you would need to fabricate a certificate.

    I mean really, don't you think that someone who took the time to write a detailed spec would think of obvious attacks like the one you propose?