[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]: http://savannah.nongnu.org/task/?8225
> 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.
- Re: OpenID, Antenore Gatta, 2008/06/02
- Re: OpenID, MJ Ray, 2008/06/02
- Re: OpenID -- do not delegate the authentication process,
Davi Leal <=
- Re: OpenID -- do not delegate the authentication process, MJ Ray, 2008/06/03
- Re: OpenID -- no no, Davi Leal, 2008/06/03
- Re: OpenID -- look beyond rivals' marketing materials, MJ Ray, 2008/06/04
- Re: --- I am overloaded, delaying other tasks ---, Davi Leal, 2008/06/04
- Re: --- I am overloaded, delaying other tasks ---, Antenore Gatta, 2008/06/05
Re: OpenID -- do not delegate the authentication process, Davi Leal, 2008/06/02