Slashdot Mirror


OpenID - Open Source Single-SignOn

Nurgled writes "Danga Interactive, who created LiveJournal and memcached, is working on a new decentralized single-signon system called OpenID. Similar in principle to Six Apart's TypeKey or MSN Passport, OpenID will allow you to assert a single identity to any OpenID-supporting site. The difference here is that there is no central authenticating server: anyone can run one, and Danga's reference implementations will be open-source. The site you are authenticating with never sees your username or password, just a one-time token. You can read the initial announcement on LiveJournal, though some details have changed since that post, so be sure to read the information on the official site."

15 of 209 comments (clear)

  1. Why DSA? by gtrubetskoy · · Score: 4, Interesting

    I coincidently not long ago wrote a paper (ggogle cache) on how to implement RSA-based signle sign-on (using Python/mod_python). Using public key signatures seems like the most obvious way of implementing SSO. I'm surprised OpenID is using DSA though - AFAIK RSA (now that it's patent free) is a superior, more trusted and flexible algorithm.

    I'm not a cryptographer by any means, but IIRC DSA was put together by NSA as an algorithm that was "crippled" to only do signatures, but not encryption, and there was some controversy because at first NSA wouldn't admit to being the designer, instead NIST was pretending to be one, and then later someone discovered a way to somehow leak bits and it is still a mystery whether this was intentional on the part of NSA or not.

  2. Open by callqcmd · · Score: 5, Funny

    Does it mean I have release my password per GPL and anyone is allowed to modify and distribute it for free?

  3. Certain Information by teiresias · · Score: 3, Interesting

    while it certainly would be nice to login to one spot and be logged into all my favorite websites, as a webmaster I use different information based on what part of my site the person is logging into. Their username/password might be the same for both pages but a cookie might be set on one that isn't on the other and doesn't need to be on the other or could be harmful if done.

    Admittely, I need to read up on this, and it's definitly an interesting idea to have a single login but I think there are some behind the scenes issues that need to be worked out.

    Also the decentralized nature of the servers has me worried/confused. So if I ran one, would I have everyones authentication information?

    --
    -Teiresias
    1. Re:Certain Information by Doctor+Crumb · · Score: 3, Informative

      You are confusing Authentication with Authorisation. Authentication is proving that You Are Who You Say You Are, i.e. the purpose of systems like OpenID. Your cookies/etc would be involved with Authorisation instead, deciding what that person is allowed to do on your site.

      Of course, if a central signon system doesn't work for you, then don't use it.

    2. Re:Certain Information by sydney094 · · Score: 5, Insightful
      The decentralized nature of this is the problem. It is impossible to securely authenticate a person using an untrusted server.

      If you ran one, you'd have only your authentication information stored on your server. Then, to authenticate to a remote server, you'd point that server to your server. The remote server would ask your server who you are, and then authenticate you (log you in). The biggest thing is that the remote server has to trust that what your server tells it is correct.

      This may have a place in the blog world, where you're mainly looking for an easy way to keep your user profile the same across many blogs, but certainly not anywhere where you'd have sensitive data.

      Another point, this is supposed to be authentication and not authorization. But actually, this isn't really authentication either... The difference between the two is really the question the server is asking. In authentication, the question is "are you who you say you are?". In authorization the question is "do I have the rights to perform a task?". With OpenID, the question is "who are you?". There is no verification to see if you are who you say you are (from the remote server's perspective, since there is no trust between servers), so you aren't actually authenticated.

      It would be up to your server to determine what rights an open-id authenticated user would have.

      --
      "If we knew what we were doing, it wouldn't be called research." - Einstein
    3. Re:Certain Information by Nytewynd · · Score: 5, Insightful

      You could still use cookies based on the sign on. Instead of getting the sign-on data from the user typing it, you would be getting it from the token and perhaps looking it up on the backend. It makes it easier for the user, and is about the same amount of programming for you. You can still set and delete cookies accordingly.

      Decentralized servers are no less secure than if you had a database table of your user authentication information for your application. With SSO, you actually don't need to know the password since it has already been handled. All you need back is the user ID and that they have been authenticated. If you choose to set one of these servers up, it isn't like people are going to start using your server to store their Online Banking information. They will be using your server only to access sites that you run.

      On the flip side, if you choose to latch onto someone else's server for authentication, all you will be doing is specifying that you allow anyone authenticated by that server to access your site. You wouldn't even have as much knowledge of those users as you would if you ran your own security.

      For the most part SSO is only really usefull within a small environment. Very rarely do I see a need to allow people to access more than one application with the same sign on. Something like passport is nice for the general user, but why would I want the overhead of something like that for my own applications? I'd rather have more control over things. That sort of makes this new product interesting to me, but on the other hand, most of my applications have distinct user sets anyway.

      --
      /. ++
  4. No thanks by Quasar1999 · · Score: 3, Interesting

    I'll authenticate with each and every site I visit...

    Take MS Passport for example. I log on to MSN webmessenger. I chat with some friends, then I close it down. 3 hours later I decide to log on to MSDN to grab a file, I need to log in with a different account since my messenger account doesn't have the access... fine... I do that... then a few hours later when I go to webmessenger again, I'm auto-logged on with my MSDN credentials.

    The only option I have is to force all passport sites to stop caching my username/password and make me type it in everytime, thus defeating the purpose entirely.

    This sort of password system is open to all sorts of problems, and not just of spoofing, or somehow being hacked and having people impersonate you... I'm more worried about logging on to some place with the wrong credentials...

    --

    ---
    Programming is like sex... Make one mistake and support it the rest of your life.
  5. Single signiture sign-on by 0xABADC0DA · · Score: 4, Interesting

    What I want is a system where I go to a site requiring a login and it asks my browser to sign some data with my private key. During the account creation I send the server my public key and that's that -- no need for a password and the login could be done automatically using cookies or something. Then there is no need for a single sign-on provider and nobody can globally revoke my account at all sites.

    You could still have an 'id provider' that could sign the data on your behalf if you are on a internet cafe for instance, but it would not be required by design. So in 'kiosk mode' the browser could just forward signiture requests to the authority after you logged into it (which could even be your home computer).

    This should be pretty easy to do as a firefox plug-in.

  6. Re:Hosting Servers by Turn-X+Alphonse · · Score: 3, Insightful

    you forget something.

    Slashdot maybe large but live journal's user base (myself included) is also very large. Most of them are idiots (AKA teen girls) so they would instantly start using it and think it was a great idea to only need to sign onto one site ever.

    If "average whiney girl mark 3" thinks it's a good idea she will tell her friends and it'll spread like wild fire through the mass market. The geeks can't control this only choose if we listen to the cries or get snowed under with them if this happens.

    --
    I like muppets.
  7. distributed != decentralized by PureFiction · · Score: 3, Insightful

    Yadis is correctly described as distributed single sign on, not decentralized single sign on. Everyone still has their dedicated central identity server, it's just that requests from other sites can be delegated to your server instead of requiring only one for everybody.

    distributed != decentralized!

  8. Free as in Freedom by RealProgrammer · · Score: 4, Funny
    Does it mean I have release my password per GPL and anyone is allowed to modify and distribute it for free?

    That's a common misconception. We have no problem with people making money from your password. It's the attempt by some to restrict freedom and keep your password all to themselves that we are against.

    We would support, for instance:

    • sending your password out on a tape and charging $100 for the tape.
    • charging you $100 for your use of the computer resources on which your password is stored
    • charging you $100 for the support of your password
    • charging you $100 for this response

    Your password wants to be Free. We urge you to set aside the bondage in which your password is held and join with us for a better community.

    [Gnoll mode: OFF]
    --
    sigs, as if you care.
  9. Re:Hosting Servers by soupdevil · · Score: 4, Insightful

    But Slashdot readers are more likely to manage their own sites which would be candidates for using Open ID, which makes Slashdot potentially more valuable.

  10. I am a cryptographer, and this isn't so. by Paul+Crowley · · Score: 3, Informative

    I don't think RSA is overall more trusted than DSA, and I certainly don't see a way in which it's more flexible for this application. It was designed only to do signatures, but that's fine, since only signatures are needed here.

    When you say "leaking bits", you're probably thinking of subliminal channels, and you're referring to some rather out-of-date information in Applied Cryptography. It's now established that all secure signature schemes have subliminal channels; they have to be probabalistic for the security proofs to work, and that's enough to give a "low-bandwidth" channel for anyone who doesn't know the signing key, or a "high-bandwidth" chanel for those who do.

    DSA is a perfectly good choice here.

  11. Re:Hosting Servers by Nos. · · Score: 3, Insightful

    And this is the important point. For some reason, users of web services don't typically demand features like consumers do in other markets, at least not to the same degree. New features usually are first designed by site/owners/programmers/designers/masters/etc and then copied by countless other sites.

    So, having a large population of readers that also maintain or run sites see and believe in an open system like this is probably more important than the user base knowing about it. Lets face it, if everyone on /. started incorporating this technology into their sites and mentioned it on other sites that are maybe more targetted, this could take off faster than anyone expected. Imagine if slashcode, post/php-nuke (and all the other OSS CMS systems), etc started putting in modules for this. Microsoft passport would become nothing but a memory very quickly.

  12. Wow. by yitzhak · · Score: 3, Informative

    I mean, I shouldn't be surprised, but I am. It seems liek 90% of the people commenting didn't RTFA, or didn't have their brains installed at the time. This isn't a secure banking system - it is, as one person pointed out, probably better described as OpenHandle. You sign in ONCE, and from that site, you tell it which other sites can authenticate from your identity site. Then, these sites know who you are. They don't get your password, or anything, they just get a temporary key to verify that you're you. Any site can fake it, that's not the point. The point is that you have participating sites where you would want to now have to sign in every time you want to comment. It helps prevent lock-in to blogs etc - imagine, for example, you sign in to slashdot, and then you can use the same handle without having to create accounts and sign in at other blogging services. THAT's the idea. It's not a trust net, or a passport-like system, it's just so that sites that want to play by the rules can provide people with a convenient way to identify themselves. That's ALL.