Refactoring the Debtags web interface

Enrico Zini enrico at enricozini.org
Tue Feb 24 10:27:15 UTC 2009


On Mon, Feb 23, 2009 at 10:19:21PM -0500, Sam Hartman wrote:

> I find it deeply ironic that I'm arguing against security.  However,
> let's remember that we're talking about debtags.  It's always
> important to think about your threat model and about how much
> complexity you're willing to spend in order to get security.
> 
> This seems like a case where usability is far more important than
> security.  If the system starts getting abused, we can lock it down
> more.

Unfortunately the issue of choosing openid here is not on the debtags
side: the problem lies where the user database is, that is on
db.debian.org (maybe also on alioth).  I perfectly understand that the
people in charge of db.debian.org do not want to expose their password
database through an OpenID identity provider: since they cannot decide
what service providers would or would not use their services, they
cannot rule out the scenario where a DD would get his Debian password
stolen while trying to log into a random wiki, or where someone,
unbeknownst to them, implements an insecure openid service provider
allowing DDs to do something important.

I understaind their choice of not providing the service over creating an
ecosystem based on a very convenient but flawed identification mechanism
that will risk drifting towards being used more and more, and more and
more inappropriately as time passes.

The big flaw of OpenID now seems to me to be that the service provider
is easily able to weaken the security of the identity provider.

Therefore the most important security aspect of OpenID is not to have a
service provider where security is not important, but rather a user
database whose security is not important.

I can implement OpenID in a new Debtags web application, but people
would have to get their identities out of something like their blogs.
We could implement a Debian OpenID provider, but it'll have to be
something else than the normal user database, in implmementation as well
as in scope.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20090224/ffded879/attachment-0001.pgp 


More information about the Debtags-devel mailing list