lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6905b1570803240838h34e51e05ta05ec9a186ce18d9@mail.gmail.com>
Date: Mon, 24 Mar 2008 15:38:25 +0000
From: "Petko D. Petkov" <pdp.gnucitizen@...glemail.com>
To: "Paul Schmehl" <pauls@...allas.edu>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: OpenID. The future of authentication on the
	web?

comments inlined

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

SSL + KeyFob (2 factor authentication) + Session destruction after
authorization - I don't think that you can do anything useful with
that. If the OpenID does not have any SQL Injection or other problems
such as auth-bypass, it is mission impossible. And even if the site is
vulnerable to some bugs that has nothing to do with OpenID.

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

Paul, that's cool. You are covered. :) What about the inconvenience?
What if someone withdraws all your funds right at the end of the month
you have no money for a couple of days. You know that it takes time to
detect fraud and there are all sorts of complications around that.

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

You won't be able to phish them. And even if you install a trojan you
won be able to capture them :)

>  your box.  Then I get your OpenID username and password.  Now I have everything.

You need more then username and password.

>
>  It *will* happen.
>

It will happen for purely implemented sites.

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

Not really! I was one of the first to speak against OpenID. :)

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

How many sites do you know that enforce good password policies :) ?

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

OpenID is explicitly designed to enable you to control your data. At
the moment the service provider controls your data not you.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ