[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OpenID -- do not delegate the authentication process

From: Davi Leal
Subject: Re: OpenID -- do not delegate the authentication process
Date: Mon, 2 Jun 2008 22:31:36 +0200
User-agent: KMail/1.9.7

MJ Ray wrote:
> > Gnuherds can always choose a limited number of OpenID providers, as soon
> > as we will discover one of these providers has been exploited, we can
> > remove it from the list.
> 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.

Note the GNUHerds Cookie is only sent, and only accepted via HTTPS. When the 
project get a certified HTTPS certificate its security will be better.

> I control my OpenID server, usually remember its password and will probably
> notice any strange behaviour from it (it logs where I've logged in, for
> example), 

We could modify the webapp to show too such log-in history feedback after 
users log in.  That is a good idea which IMHO helps improve security.

  [new task]:

> whereas for many other sites, I either have their passwords saved in
> something like Mozilla Personal Security Manager or frequently request
> password resets, neither of which are as secure, in my opinion.

That is true, IMHO.

What we could do is offer the GNU Herds authentication as an OpenID shared 
identity service.

Being GNU Herds the provider, we take care of its security. So we avoid any 
security risk due to the compromise of the external services, not adding more 
security risk paths.

But to such idea work, we would have to avoid accept _any_ other external (not 
controlled) OpenID service.

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

All us could lost our money in the first security issue, before we note it.

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.

I propose we follow thinking about all this subject. We will have to know what 
to do about it when we begin to work on the (phase 2) to add 'bank' support 
to GNU Herds.

We should do a dept analysis before deciding if the project must use OpenID in 
some way or not.

We must follow discussing about this. Perhaps me or you, or both you and me, 
are wrong.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]