gnuherds-app-dev
[Top][All Lists]
Advanced

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

Re: OpenID -- do not delegate the authentication process


From: MJ Ray
Subject: Re: OpenID -- do not delegate the authentication process
Date: Tue, 03 Jun 2008 09:23:31 +0100
User-agent: Heirloom mailx 12.2 01/07/07

Davi Leal <address@hidden> 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.

[...]
> 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 - taking
responsibility for my own security, avoiding having dozens of piddling
little web app passwords and being able to independently record my
log-in history.  I am very fed up of websites that claim to support
OpenID when they only mean they are an OpenID provider, effectively
saying that they trust no-one but everyone should trust them.

> > 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.
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!  Adding OpenID doesn't add any
risk of that type we're not already exposed to.

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

Why?  Only the users who say "trust OpenID server X" should lose money
if OpenID server X is cracked, just like only the user(s) of a
particular machine will lose money if that machine is cracked and
their GNU Herds Cookie system password is stolen.

> 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
I think we should try to do betterthan most banks.

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.

Hope that explains,
-- 
MJ Ray (slef)
Webmaster for hire, statistician and online shop builder for a small
worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/
(Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237




reply via email to

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