Follow Slashdot stories on Twitter


Forgot your password?
The Internet

LiveJournal Founder Launches OpenID System 172

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.
This discussion has been archived. No new comments can be posted.

LiveJournal Founder Launches OpenID System

Comments Filter:
  • is still a dupe, especially when the note wasn't part of the actual submission
  • by Anonymous Coward
    Universal hardware tokens. Please.

    • I'm kind of surprised that nobody has come up with a good, free alternative to RSA's SecurID system. For those that haven't seen it, it uses little hardware tokens (in the form of keyring fobs or credit card-sized units) that are synchronized with an authentication server. It seems to me like somebody could come up with a similar system that perhaps used a small Java app running on cell phones and PDAs to replace the key fob.
      • It seems to me like somebody could come up with a similar system that perhaps used a small Java app running on cell phones and PDAs to replace the key fob.

        Actually that sounds like a pretty good candidate for an open source project. Once you've created the RSA ACE/Server clone you could have someone mass fabricate cheap tokens with replaceable watch batteries. Maybe have them plug in via a USB interface to upload a new encryption seed should it get compromised.

    • 1)How do we get the database of who owns what tokens? Talk about a danger of privacy.
      2)Easily spoofed
      3)Makes identity theft far easier- we now just need to steal 1 number.
      • 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 i
  • Can hardly wait... (Score:3, Insightful)

    by martian67 ( 892569 ) < minus caffeine> on Tuesday July 05, 2005 @05:01PM (#12988747)
    I can hardly wait if/when systems like this become popular, to be forced to register an id like Martian5576567567 due to every other numerical possibillity haven been already taken, due to alot of sites using such a system, and people forgetting about passwords or old accounts and re-registering multiple times.

    Also isnt there an issue if somone discovers your password, they can "pretend" to be you on any site including sites with sensitive information such as paypal and the like...
    • by LFS.Morpheus ( 596173 ) on Tuesday July 05, 2005 @05:51PM (#12989140) Homepage
      I'm not addressing your security issue.. I think OpenID is not designed for secure applications (banks, credit cards, etc) - its more for bloggers, chatters, forums, etc etc.

      Anyone can run an identity server.. so for instance each ISP could have one, or you could choose to use Google's, or Yahoo's, or Livejournal's.. or even mine, if I choose to run one for my website. In an ideal world, AOL could run one and integrate it with their AIM logins. Microsoft could run one and then Passports would work too.

      Having a decentralized system allows you to avoid problems like this - it's kind of like jabber in my mind. I don't know *too* much about OpenID yet but this is the general idea.
      • I liked it better when we all had finger. I am sure some genius will resurect it any day now as the next big thing. Yes it's a decentralized authentication system of sorts.
        • That's interesting... but finger doesn't really have any authentication, does it? You can finger anyone on any system, so pretending to be someone would be simple - finger only tells you if that person exists. Obviously if you have a shell account you have a password but there's no way (through finger anyway) to check to see if that password is correct.
          • All finger has to do is to hand out your public key. At which point you can compare the public key the user gave you and the one finger gave you.
            • Well, then I can get anyone's public key, but I see what you're saying. You could use a public/private key system, asking the user to encrypt or decrypt a random string, and seeing if you can get the same string using the publically available string. I think something akin to backwards RSA (where the private key encrypts) would work better in this case. The only issue is how the user would get their private key, because no one wants to remember a long, random password.

              I think its time for me to really go a
              • if you look at ssh keys they are tied to a domain. So I claim to web site X that I am and do a key exchange. The site then fingers which gives them my public key. The site takes the public key from the finger and encrypts something to send me. I decrypt it and then re-encrypt it using their public key and send it to them. If they get what they gave you then voila, everything is kosher.

                Easy, I AM A GENIOUS, behold the next big thing!. It's finger that gives out publ
    • actually, if this gets popular, and /. buys into the idea, you could then log into anywhere as [] - no need to re-register anywhere else... That's the whole point...
  • A good Idea... (Score:1, Insightful)

    by MaxPowerDJ ( 888947 )
    ...but a questionable implementation. This is very utopic in nature (not having a centralized server storing everyone's data) but it doesn't feel feasible to just "trust" a decentralized architecture to hold/store my personal information without designing it from the ground up with security in mind.

    Just my 2 cents...
    • Re:A good Idea... (Score:3, Informative)

      by kurtras ( 65722 )
      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.
      • Re:A bad idea... (Score:3, Interesting)

        by shmlco ( 594907 )
        ...allow you to prove that you own a URL.

        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.

        Without a private portion (password) it fails at authentication of identity, and devolves to just being "easy"...

        • Re:A bad idea... (Score:3, Informative)

          by kurtras ( 65722 )

          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.

          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 i

          • ...then you can use your URL to log in to any OpenID consumer site.

            Which is the problem. It doesn't need to be your URL.

            My current comments stand, with a couple of exceptions. First, it appears that you have to "authorize" a site. Second, you have to be logged in.

            Given those two conditions, it appears I could easily impersonate someone on a site they frequent if they have a session running AND if I know (from their sig, perhaps) their URL/domain.

            • 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

              • I appreciate the detailed explanation, but I had to chuckle at the last line. I've seen plenty of "detailed spec's" that had rather large, freight-train-sized holes in them...
        • You're right! In his pages and pages of specs, he totally missed the attack of "just typing someone else's URL!" I wonder why he never thought of that!

          Thank you for your thoughtful analysis.
    • your personal information is stored only with the site you choose for your OpenID. so if you use your OpenID to post comments in your friend's deadjournal, only LiveJournal has your information.
  • by Anonymous Coward on Tuesday July 05, 2005 @05:05PM (#12988781)
    If it is like LiveJournal, I am sure lots of self obsessed people will want to use the ID system.
  • On the one hand:

    Sites that let you enter your name/URL/email/etc and show it without verifying you're you are lame.

    On the other:

    Somebody could run their own identity server that says they're [] all the way to [] and that's not a goal of this system to prevent.

    If anyone can run their own identity server, then why use this rather than a (probably more user-friendly) Captcha [] system?

    • that would involve creating a new account, and having yet another set of usernames and passwords to remember.
    • Re:The point? (Score:5, Informative)

      by jfengel ( 409917 ) on Tuesday July 05, 2005 @06:02PM (#12989233) Homepage Journal
      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.
  • Something like this is simply DOA. Few content providers will take advantage of this because they have their own in house and/or have never heard of this guy or his company. If say, Yahoo was to do it, it'd take off like wildfire. But Yahoo's a perfect example... their one id system is and has been in place all throughout their growing universe of web content. As is, does the creator really think that people will be clamoring for one for a blogging site? c'mon... blogging is still quite the ego-centric
  • by ShatteredDream ( 636520 ) on Tuesday July 05, 2005 @05:23PM (#12988928) Homepage
    Many blogs require you to register in order to be able to comment so that the person who runs them can control trollish behavior. This sort of system is good for letting people avoid having to register to be able to post on dozens of blogs.

    Registration is mostly good for keeping away trolls who can't even take the time to learn their native dialect of English well enough to write a coherent and grammatically correct post. Sometimes it's horrifying to read the structure of such posts because you realize how far our schools have fallen. I've gotten ones that if I didn't have a college-level grasp of English, I'd have no idea what was being said.

    As long as security is the first priority, this is a good thing. What I wonder though, is how secure this could really be without centralization. The appeal of SixApart's service is that SixApart is guarding it aggressively from being cracked... so who runs this service? I'm not sure how well you could trust a P2P system like this since you have no definitive authority to say "this user is who he/she says they are."
    • What this is good for is being able to say "I trust comments posted from LiveJournal, SixApart, Yahoo, MSN, Google, and 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,
    • I'm not sure how well you could trust a P2P system like this

      "This is not a trust system. Trust requires identity first."

      The only thing that this does is that it lets someone who has established an identity use that identity in other places without a relationship between the sites or between the user and the new site. This would let me convince groklaw that I'm [] as effectively as I convince slashdot itself without enabling groklaw to spoof me to other sites (like if I just sen
    • What I wonder though, is how secure this could really be without centralization.

      The protocol has been gone over by a few cypher experts, who seem happy enough with it.

      Whether you trust any particular site to be a reasonable validator of accounts is another matter. You might (for instance) allow as an authenticator, but not, if you thought that getting an account was too easy.

      It's more meant to be so that I can identify myself in various places as being me - you can't trust anyon
    • A new scheme for this is actually pointless, because it just reinvents an existing wheel and does so far less effectively than before.

      That previously invented wheel is PGP keys.

      They were created for a different purpose, but they already contain a string that can be used as a legible identifier (which commonly contains a URL or email address), and they are trivially checked, and they are vastly more proven and secure as a means of trusted identification, and they already operate through a distributed syste
  • by FidelCatsro ( 861135 ) <fidelcatsro@gmail.cOPENBSDom minus bsd> on Tuesday July 05, 2005 @05:26PM (#12988953) Journal
    About openID
    Sometimes i wonder
    Why we don't have it shut
    Closed ID seems smarter
    Burma shave

    Seriously all this jazz about the OpenID systems left right and centre from so many sources , yet non of them work , perhaps a new vector is required
  • On the [] 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.
    • It does not open a hole in the protocol per se. I understand your relevant concern, but people are bashing OpenID so much that I don't think it's advisable to talk about "holes" at this point.

      But yes, I agree that popularizing popping up a login to your server is a bad idea, as if people get used to this, that could be prone to phishing -- but not actual man-in-the-middle attacks to the actual OpenID protocol.

      Anyway, the way I understand it, OpenID assumes that the user trusts both sites:

      I have an OpenID
    • Keep in mind this is a system for authentication, not a system for authorization. You can trick the user into proving their identity, but OpenID doesn't allow you to then access the user's information. It only allows you to verify that they are who they say they are.

      • The danger of the attack grandparent describes is that the foreign site could trick you into authenticating with "your home server" by spoofing its login page and hiding the URL to look legit. Then you would be giving your username/password to the untrusted site.
  • Taking the items one by one:

    1. XML-RPC had a recent exploit that could be revisited in a very nasty way. Even though this appears to use POST, it's still looking pretty complicated from my perspective. I think the same results could be achieved in a much easier way.

    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.

    2. I think the motivation for this service is skewed. The only motivati

  • A big reason for me like this (and dislike it at the same time for security reasons) is that with a widely distributed system like this is will make it easier to keep track of who said what, even across multiple web sites. Each person would have the same name across many web sites, so those of us who are involved in multiple online communities can more easily keep track of people that share more than one common community with us. For example, I could identify Slashdot posts by people that go to the iDevGame
  • Forgive me if I'm being naive, but couldn't we have more or less open posting if whatever bulletin board system required a PGP encrypted post, and checked it against a central authority, or even several authorities?
  • There seems to be quite a proliferation of these services, eg. NoCatAuth, which is used in several projects.
  • Providing you actually have a URL, this may be slightly better than the existing typekey technology. However, only 1 in 14 internet users has their own blog or website. The more options the better I suppose, but this is really an evolutionary step rather than a revolutionary one.
  • by Downes ( 897607 ) on Tuesday July 05, 2005 @09:42PM (#12990592) Homepage
    A few days before the LiveJournal system came out I released something very similar (this is not sour grapes; they have very generously acknowledged my work) called mIDm. You can view it here: []

    I was very pleased to see the LiveJournal system because it acknowledges what no system has done before: that identity belongs in the hands of the users.

    This has two major aspects:

    First, as argued over and over on the LiveJournal site, this is not an authentication system, it is an identification system. You are not being required to prove you are who you say you are, you are instead being given a mechanism to declare who you are.

    It is, in purpose and intent, as secure - and no more secure - than filling out a web form. But the idea here is that you fill out the form just once, and then using a system of call-backs (to ensure your personal information isn't spoofed) you can use that information anywhere on the web.

    Let me repeat that, in case you didn't get it: anywhere on the web.

    The idea is, if you want, you can have the *same* identity on each of dozens of websites. Which means, say, if your email address changes, you change it once, and this information is now available (if you want it to be) to all of your accounts. Ditto your home page.

    I will leave the many many applications - such as web-wide peprsonalized display, in-page messaging, multi-site social networking, and more - as an exercise to the reader.

    Second, what it means is that the system is distributed. This means that there isn't some centralized grand poobah of identity (the way Passport tried to be, the way Sxip is trying to be). It means you can choose any system you want to host your identity or you can build your own.

    Let me repeat that: you can build your own.

    Don't like their security. Make yours tighter. Too much lag on LJ. Host it yourself. Want to send different emails to different types of site. Code it.

    One of the mistakes made in previous system was in the use of a one-size fits all model, which meant that the level of security had to be at the highest possible - which is orders of magnitude more than someone needs merely to write blog posts and comments. Building a distributed system allows each person to decide how much - or how - security is appropriate.

    Having made these two points, I would like to mention briefly where my system goes beyond LJ's. In their system, you are still typing your home URL at each site you visit. In mine, you don't ever have to type your home URL - it is stashed in the browser agent environment variable, where it can be picked up by any site that needs it. Oh I know, you probably shouldn't do that - but I've been testing this for months with no ill effects. YMMV, and if you have a better idea, I'm all ears.

    Despite the naysayers here on Slash, this system - or something very like it - will become the norm on the internet very soon.


    - Because it will be very simple to install for websites, especially after things like Drupal and Wordpress modules are built.

    - Because it will be very simple for the user, because they just need to type one thing in (or extensions will be built for my type of system).

    - Because it will work.

    - because it will be no less safe, and probably more safe, than filling forms willy-nilly everywhere you go.

  • this sounds like the stuff do. with i-names and so on...
  • by HishamMuhammad ( 553916 ) on Wednesday July 06, 2005 @12:01AM (#12991242) Homepage Journal

    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 using my id, "hisham".
    • I post a message at using my OpenID,
    • sets a cookie in my browser, and issues a request to, with the cookie and the message.
    • receives the request, verifies the cookie (confirming that the request from was posted by a browser who's actually currently logged as hisham in livejournal).
    • then signs the message and sends the signature back to
    • posts the message saying that 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
    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??

  • Problems with OpenId (Score:2, Interesting)

    by Atrus5 ( 537814 )
    I've expounded on [] why OpenID is insecure and I believe it is unnecessarily complicated.

    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 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

  • by flink ( 18449 )
    So one could almost say that it's like a passport that allows you to "log on" to lots of different sites...

In English, every word can be verbed. Would that it were so in our programming languages.