Message-ID: <e172cd090803240832v1e29b6cen48f88a2db809a61@mail.gmail.com>
Date: Mon, 24 Mar 2008 10:32:10 -0500
From: "John C. A. Bambenek, GCIH, CISSP" <bambenek.infosec@...il.com>
To: "Petko D. Petkov" <pdp.gnucitizen@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: OpenID. The future of authentication on the
	web?

When it comes to IT... the user is the *last* person I want empowered.

On Mon, Mar 24, 2008 at 10:21 AM, Petko D. Petkov <
pdp.gnucitizen@...glemail.com> wrote:

> on your last comment,
>
> OpenID is exactly design for that! To give the power back to the user!
>
> On Mon, Mar 24, 2008 at 3:10 PM, Paul Schmehl <pauls@...allas.edu> wrote:
> > --On Monday, March 24, 2008 09:13:38 +0000 "Petko D. Petkov"
> >
> > <pdp.gnucitizen@...glemail.com> wrote:
> >  >>
> >
> > >>  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?
> >  >
> >
> >  Of course.  Both complexity *and* convenience of often the enemies of
> security.
> >  :-)
> >
> > >
> >  > 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".
> >  >
> >
> >  I don't disagree.
> >
> >
> >  > 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.
> >  >
> >
> >  Verisign *requires* only alpha-numeric characters for my password for
> my *CA
> >  ADMIN* account for our PKI system.  That should tell you something
> aobut their
> >  dedication to security.
> >
> >
> >  > 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.
> >  >
> >
> >  Getting access inside networks these days is trivial.  There are
> hundreds and
> >  hundreds of compromised machines inside of corporate networks due to
> phishing
> >  scams and the ignorance of the average user.  Furthermore, you can get
> access
> >  to at least 10% of the machines on any network simply by logging in as
> >  administrator or root (pick your OS) using either blank, password or
> >  root/administrator as the password.
> >
> >  Add to that hundreds of trivial sql injection attacks and other easy
> attacks,
> >  and most networks are like swiss cheese.
> >
> >  Once you're on one box inside, you can roam around freely and find a
> way to
> >  capture id information in the clear.
> >
> > >
> >  > 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!
> >  >
> >
> >  You frame the question wrong.  The real question is, do I feel
> comfortable
> >  exposing $50 to risk by using a credit card or exposing every dollar
> I've
> >  deposited with Paypal to risk.  And the $50 is waived if the vendor is
> culpable
> >  for the loss.
> >
> >  I scanned a card through a gas pump while on a vacation trip last year.
>  WIthin
> >  two hours someone had charged $1005 on that card.  It cost me nothing.
>  The
> >  charges were reversed, because it was clearly fraud.  (I was in South
> Carolina
> >  - timestamped just two hours before - the charge was in El Paso.)
> >
> >  The credit card industry is quite robust and equipped to handle fraud.
>  What
> >  happens when an OpenID account is compromised and *every* account is
> drained
> >  and thousands of dollars are charged and *according to OpenID* it was
> me?
> >
> > >
> >  > 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?
> >  >
> >
> >  No, it's not, because a poorly secured site exposes only that data I
> have
> >  revealed to them.  OpenID opens a whole new realm of theft.
> >
> >  But don't take my word for it.  Just wait for the first big scam to
> occur.
> >  First I phish your credentials.  Or I induce you into installing a
> trojan on
> >  your box.  Then I get your OpenID username and password.  Now I have
> everything.
> >
> >  It *will* happen.
> >
> > >
> >  > 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 you sound like Larry Ellison.  :-)
> >
> >
> >  >>
> >  >>  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! :)
> >  >
> >
> >  Spoken like a true advocate for technological solutions to every human
> problem.
> >
> >
> >  >>
> >  >>  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! :)
> >  >
> >
> >  Not really.  Think Sox, GLBA, PCI, etc., etc.
> >
> >
> >  >>
> >  >>  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.
> >  >
> >
> >  You're misunderstanding my point.  It's not that I necessarily distrust
> OpenID
> >  providers or the software itself.  It's that I think the entire
> approach to
> >  solving the problem is wrong-headed.  Data owners should control the
> access to
> >  their data, not third parties.
> >
> >  --
> >
> >
> > Paul Schmehl (pauls@...allas.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/
>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists