The recent nodes on OpenID at Re^2: PerlMonks OpenID provider? and Breaking Out of the Perl Echo Chamber: A Call to Action have convinced me that OpenID sucks... but what would be a good solution to this problem?

My musing is just to use the ssh public/private key system.

What is hard about giving a public key out as your password, and having the web site verify it's you, by your private key.

I havn't investigated(googled ) it thoroughly, but couldn't your public key be placed in a htaccess file, and you could automatically logged in like is done with keys authentication in ssh? I suppose this would require the browser makers to include ssh as a helper app, or even builtin directly.

Another possibility is a challenge/response system(like Captcha) in which the server sends you a random password encoded with your public key, which you decode, and return to verify your identity.

In any event, it seems that if the idea is to ensure your identity online, a key system, where you have your private key, probably on a usb stick, is eventually going to be the ultimate solution, so why waste time on anything else?

Ideally, the government should setup a key server, and give everyone a public/private key. This would be a big leap forward in internet identification. Sure there would be details to work out, like do you generate the key pair, or does the government? Or could you have multiple key pairs for different sites.

Anyways, I'm not seeking approval/criticism of the above idea; but would like to here what you consider to be the best strategy for online ID's. This will probably become more important as attempts are made to make safe online voting systems. The current voting system disenfranchises the poor for various reasons.... but I'm straying off topic.

Sure there are fingerprint scanners, iris scanners, etc., but usb sticks and key pairs are probably cheaper and easier to mass distribute.


I'm not really a human, but I play one on earth Remember How Lucky You Are
  • Comment on OpenID alternatives, what do you suggest

Replies are listed 'Best First'.
Re: OpenID alternatives, what do you suggest
by moritz (Cardinal) on Sep 23, 2008 at 15:26 UTC
    Ideally, the government should setup a key server, and give everyone a public/private key.

    ... and thus have my private key? Surely you're kidding. I don't know in which country you live, but please do tell me if you've found one where you can still trust your government to neither abuse nor leak your private data. I know of none.

    To get back to your original question: I've heard a proposal which I quite liked. It goes like this: You have a secret password, to which you append the domain name of the site that you log in to, and then you calculate some cryptographic hash out of it.

    The hash (or a part of it) is used as a normal password.

    This has a few advantages:

    • Implementable as a browser plugin
    • Implementable as a web service, if you trust that web service
    • Implementable in client side JS, if you don't want to send your secret password over the wired at all
    • You can use different usernames, and nobody can connect your logins on different sites, unless you want that
    • It seems secure, to me

    Disadvantages:

    • It might need some copy&paste unless implemented as a browser plugin
    • Changing your secret key means changing many passwords.
      Well the government would have to trust your key.... I said there would be details. How about this: You generate your key pair, and like with a Drivers License or Passport, you go to a Secretary of State, prove your identity, then they sign your public key with their signature key, without seeing the private one on your usb stick. Your signed and verified public key would be then put on the national id server(maybe along with a passport photo). If ssh works as it's supposed to, it would be tantamount to a big key-signing party, run by the government at it's offices.

      If anybody wanted to see if you are who you say you are, they get your verified public key, and send you a message to see if you can decode it. Or put that key in some db, that thru the use of a browser-builtin or helper app, would verify you automatically when you go to a site, like ssh does with keys auth.

      The reason I like the key method, over some browser hash, is that this could work as an id system anywhere...at airline boarding, hospitals, etc. Instead of a USB keystick, they could even put it on a credit card type of thing, with your laser embedded photo on it.

      But on the planet I come from, they will give you subcutaneous implants with your private key on it. :-) When I use my computer, it says please put your left ziffer on the screen.


      I'm not really a human, but I play one on earth Remember How Lucky You Are

        Then the gov't can do a handy man-in-the-middle(MITM) attack. They can distribute a different public key for you, and intercept messages, decrypt them, alter them if desired and reencrypt them with your proper public key.

        Of course if the whole cyphertext is signed by its sender, then the signature would be invalidated. But the same sort of MITM stuff to the signature.

        If you are willing to compromise one key to spy, compromising two is no big step to take.

        This problem exists anytime you have one big repository of public keys. The only defense I know of is to have multiple, independent key repositories.


        TGI says moo

        Firefox and Opera both support client keys for SSL and TLS. I'm sure they are not the only browsers to do so, but I don't want to check all 9 other browsers on my desktops right now.

        For email, Thunderbird and mutt support client keys. There's also built-in support for PGP/GPG in mutt to encrypt the email itself. I'm sure there are plugins for Thunderbird to do that if it doesn't already. Many servers can be configured to use TLS-encrypted sessions for MTA to MTA communications when available at the other endpoint.

        It's typically considered the MTA's job to deliver the mail first and to concern itself with security second, which is an attitude that needs to change before any of this improves. It does little good to have SSL or TLS sending and receiving if the mail routing in the middle is in plaintext. Encrypting and signing the message at the endpoints with PGP/GPG and sending it through clear channels should offer whole-path protection up to the point where they are easily borken. AFAIK, it still takes quite some time to break a 2048-bit key for GPG.

Re: OpenID alternatives, what do you suggest
by mr_mischief (Monsignor) on Sep 23, 2008 at 16:35 UTC
    I suggest a password and/or key wallet at the client end. Secure that by biometrics, passphrase, trusted key, or however you want to secure your own password wallet.

    This solution allows you to have separate keys or passwords for separate sites. If one gets compromised, then you have partitioned the damage. The only way all of your personal site credentials get stolen is if your wallet software (or hardware) gets compromised. That package and its data are in your possession on a system you, your employees, or your contractors secure. You're not depending on some site on which you may or may not be currently active to keep your credentials for everything safe.

    This solution also allows you to have a single sign-on experience at your own expense and effort without pulling in the resources of site administrators or effecting the credential storage of other people. You keep your passwords over there and I'll keep mine over here. I think that works well enough for everyone.

    I'm not sure this has anything to do with Perl unless you're assuming that Perl will be the implementation language.

      I like that. Maybe with the leaps forward they are making with miniaturization, they could have a credit card sized thing, that stores many keys, can read your thumbprint, and has a built-in mini-keyboard for entering passwords on the card. Looks like the guy testing this Electronic Paper is trying to hide his thumbprint. :-)

      I'm not really a human, but I play one on earth Remember How Lucky You Are
        I was thinking a USB or Bluetooth connection to the hardware versions. One with its own miniature keyboard could come in handy in a pinch, though. I tend to use KWallet or something similar on my PCs already.
Re: OpenID alternatives, what do you suggest
by DrHyde (Prior) on Sep 24, 2008 at 10:14 UTC

    Oh yeah, public key crypto is definitely the way to go. All it requires is that someone writes software to make it easy and convenient. No-one has done that yet, despite everyone knowing for donkey's years that it's a pain in the arse to use.

    So what makes you think that someone is going to do it now?

      So what makes you think that someone is going to do it now?

      Because with the "war on terror" and increased online activities, the Time is NOW, especially for online voting in elections. Just wait, when Obama gets in, all problems will be solved. :-)


      I'm not really a human, but I play one on earth Remember How Lucky You Are
        You're an eternal optimist, aren't you? The war on terrorist groups makes the government less friendly to things like widespread adoption of strong encryption. They don't want the terrorists to have secret communications in plain view.