Re: OpenID. The future of authentication on the web?

["Petko D. Petkov" <pdp.gnucitizen () googlemail com>]

Hey Paul,

some valid points indeed but let me inline some of my thoughts. read on.

On Sun, Mar 23, 2008 at 10:37 PM, Paul Schmehl <pauls () utdallas edu> wrote:
> --On March 23, 2008 2:52:53 PM +0000 "Petko D. Petkov"
>
> <pdp.gnucitizen () googlemail com> wrote:
>  >
>
> > First of all, OpenID is a very simple but rather useful technology.
>  > With OpenID you have only one account, your ID, which you can use
>  > everywhere where the OpenID technology is supported. It is not clear
>  > whether this setup is more secure from what we have at the moment
>  > (every site forces you to register unique username/password pair) but
>  > it is definitely more convenient.
>
>  Yes, and convenience is often the enemy of security.

Not always. I think complexity is the enemy of security. The simpler
the system is the less chance to screw up, the more secure it is. It
is much easier to secure a single port then a class B network, don't
you think?

>  > The first argument "for" OpenID is
>  > that the more you share your secrets, credits card information,
>  > usernames, password, the higher the chances this information to be
>  > leaked or stolen. On the other hand, OpenID is prone to phishing
>  > attacks so user education is required.
>  >
>
>  However, with OpenID, all I have to do is figure out how to capture your
>  credentials (which does not require that I compromise OpenID), and I can
>  own everything that you own.  At least with the disparate systems we have
>  now you only get those things where I've been foolish enough to use the
>  same credentials.  Even then you have to figure out what those systems
>  are.  With OpenID I simply try every site that uses OpenID, trivial to do
>  programmatically.

Paul, you are right but here are my arguments:

First of all, we've proved time and time again that people do reuse
passwords. Password reuse is a huge problem and it is due to our
inefficiency of memorizing partial information which is not associated
with anything substrantial. In psychology this is known as the process
of anchoring and if you master how to anchor then you can master
memorizing large sets of useless data without getting corrupted
sectors in your brain. A good start is reading Darren Brown's book
"Trick of the Mind".

On another note, capturing my OpenID credentials wouldn't be as easy
as you say. First of all if the OpenID provider has a valid,
authorized SSL certificate you won't be even able to see when creds
are flaying around. Second, I've mentioned one-time passwords in terms
of keyfobs, rsa tokens, whatever. Even if you capture these
credentials you wont be able to use them and believe me, carrying one
keyfob just for your OpenID provider is a lot easer then having what
they call keyfob necklace in order to ensure a good security for every
single site you visit. I think that verisign provides OpenID service
which is based on all that.

Last but not least, lets say that you have access to the machine or
network and you can sniff the cookies and as such get access to the
openid account. Well, some OpenID providers have features where you
can configure the account to automatically destroy the session cookie
once an OpenID authentication is authorized. Your best chance is to
sniff or attack the sites where the user is logging into but any
problems associated with them are not problems withing OpenID and they
will work independently of the authorization/identification mechanism.

>  > Think about OpenID as the equivalent of PayPal for authentication. In
>  > theory, it is more secure to pay through paypal as you are not sharing
>  > your credit card information with everyone else but a single provider.
>  >
>
>  There's a reason I don't use Paypal......

Well, PayPal is a lot more secure when it comes to money
transfers/transactions. Do you feel comfortable giving away your
credit card details to every single merchant from which you want to
purchase some goods. I don't!

>  > I am all "for" OpenID as you can spend good time on securing a single
>  > system. If the OpenID provider is not vulnerable to common Web attacks
>  > and it provides good privacy mechanisms such as SSL and the top of
>  > which are build good authentication features such as one-time tokens,
>  > etc.... then OpenID is the preferable choice.
>
>  The problem is, I have to trust the OpenID provide to both secure his/her
>  systems and hire trustworthy help.  I have to do the same locally, but I
>  have a great deal more control and ability to monitor.

Well, roll your own OpenID service. It takes 5 minutes and a couple of
lines with PHP and you can make it as secure as you want.Isn't that
much better then trusting every single login prompt you see?

>  > Keep in mind though,
>  > that if your OpenID account is hacked, the attacker will be able to
>  > login as you anywhere they want. This is the main concern and
>  > disadvantage.
>  >
>
>  And that is a *huge* disadvantage.

true but as I mentioned above and in my previous email, you can spend
good time securing your OpenID to the extend it is not feasible for
someone to attack it. We know that all encryption mechanisms are
vulnerable to brute force attacks but is it feasible to crack them?
No, not at all. Not now! Maybe when we get to personal quantum
computing we might have a chance but by that time we will switch to
quantum based cryptography.

>  Now, there is no doubt that we need better user education.  User *must*
>  learn not to trust everything they get in email.  They must also learn to
>  use good passwords and not reuse them on every site they visit.  There's
>  also no doubt that some sites will do a lousy job of security and end up
>  exposing a person's credentials (which is why you should use different
>  credentials on every site.)

This is impossible! :)

>  We also need some sites to do a better job of requiring strong passwords.
>  (Some still require only alpha-numeric characters and two few maximum
>  characters.)

This is also impossible! :)

>  But the idea that SSO makes sense outside the context of a single entity
>  that controls its userbase is misbegotten, in my opinion.  The individual
>  *user* should control their credentials, not some "foreign" entity, no
>  matter how trustworthy they may claim to be.

As I said, if you don't trust public OpenID providers, roll your own.
It is very, very, very easy.

>  Paul Schmehl (pauls () utdallas edu)
>  Senior Information Security Analyst
>  The University of Texas at Dallas
>  http://www.utdallas.edu/ir/security/
>
>  _______________________________________________
>
>
> Full-Disclosure - We believe in it.
>  Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>  Hosted and sponsored by Secunia - http://secunia.com/



-- 

Petko D. (pdp) Petkov | GNUCITIZEN | Hakiri | Spin Hunters

gnucitizen.org | hakiri.org | spinhunters.org

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/