Re: OpenID -- no no

[Davi Leal]

MJ Ray wrote:
> Davi Leal wrote:
> > MJ Ray wrote:
> > > Generally, I agree with Antenore on this - OpenID is 'probably' more
> > > secure that only accepting GNUHerds Cookie authentication.
> >
> > 'probably' is a vague term. We should do a dept analysis before deciding
> > if the project must use OpenID in some way or not.
>
> No, probably there is a stochastic term.  Who can predict whether
> GNUHerds Cookie authentication or a significant number of OpenID
> servers will be cracked?  However, my belief is that OpenID gives
> more intrusion detection opportunities than GNU Herds Cookies.

Read the full [1] article.
  [1] http://idcorner.org/2007/08/22/the-problems-with-openid/

  SECURITY PROBLEMS
  PRIVACY PROBLEMS
  TRUST PROBLEMS
  USABILITY PROBLEMS
  ADOPTION PROBLEMS
  IMPERSONATION PROBLEMS
  AVAILABILITY PROBLEMS
  PATENT PROBLEMS

"One thing that has been bugging me more and more is how openID providers
 have been recommending that you use their log-in URLs again and again when
 they say they support openID (provider). At no point do any of them
 mention how dangerous this is." ...


Read http://en.wikipedia.org/wiki/OpenID#Criticism

etc.


> > What we could do is offer the GNU Herds authentication as an OpenID
> > shared identity service.
>
> That would completely remove the main benefits of OpenID

After reading [1] I think the project must not use neither be a provider of 
OpenID identity services.


> > > Could we simply hold unknown OpenID providers for approval and build
> > > whitelists and blacklists over time?
> >
> > IMHO it is too much risky give away a key security piece as is
> > the "authentication process" to external, and so not controlled, systems.
> > The authentication process is even more main when we talk about the
> > user's money.
>
> Why riskier?  That wasn't explained at all in the following message.

Read the full [1] article.

> IIRC, we're already exposed to someone hijacking a user's domain -
> the attacker simply hijacks the domain, asks for a password reset,
> then collects the email and PROFIT!

You has exposed a very good improvement for the current authentication 
procedure: Sign the emails with the user's public GPG key. So the project 
sends the email encrypted, therefore only the user can read it making use of 
its private key and passphrase.

Additionally, the project have to add the HTTPS certificate.

> Adding OpenID doesn't add any risk of that type we're not already
> exposed to. 

Read the full [1] article.


> > Who control the authentication systems control the money kept at GNU
> > Herds.
> >
> > If the project finally will work with money maybe we will have to adopt
> > security measures as the actual bank uses.  Delaying the request to
> > transfer the money could help; and/or maybe ask for a confirmation via
> > email or... but that does not solve the base problem: the project must
> > not delegate the authentication process.
>
> Most banking internet operations seem less secure than the debian
> project - only Nationwide.co.uk have ever sent me OpenPGP'd email, for
> example - and I don't remember anything in the Payment Card Industry
> Data Security Standard (PCIDSS) that prevents OpenID, for example.  I
> don't think the back security requirements will be a major hurdle and

OpenID is a nighmare. Read the full [1] article.

> I think we should try to do betterthan most banks.

I agree.

> I agree that the project must not delegate the authentication process,
> but I believe it could replace the authentication password with OpenID
> tokens without significant loss of security.

Read the full [1] article.

Besides, as you can see at [2], OpenID is not just about replacing the 
gnuherds password by an OpenID.

  [2] http://blogs.sun.com/hubertsblog/entry/openid_sun_architecture