[drupal-devel] [bug] Remove drupal module from core
javanaut
drupal-devel at drupal.org
Tue Sep 20 17:28:37 UTC 2005
Issue status update for
http://drupal.org/node/31716
Post a follow up:
http://drupal.org/project/comments/add/31716
Project: Drupal
Version: cvs
Component: drupal.module
Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: robertDouglass
Updated by: javanaut
Status: patch (code needs review)
Just contributing some links to the discussion here.
There was previous discussion on distributed auth here:
http://drupal.org/node/19113
Parts of this discussion fed what became OpenID: http://openid.net/
There's a PHP implementation of OpenID here (I've never used this,
though): http://www.videntity.org/openid
If somebody had time/motivation to develop an auth module that used
this, I think it would bode well for Drupal, whether core or contrib.
It's primary benefit is that you need not trust the site that you're
logging in to, just your main server. You never enter your password
into a non-trusted site.
javanaut
Previous comments:
------------------------------------------------------------------------
Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB)
The drupal module does two things; it implements distributed
authentication and it lets you run a "directory server". These sound
great in the features list, but the implementation of both features is
weak and poses the real risk of exposing Drupal users to identity
theft.
Here is an excerpt from my writings on the module:
Distributed authentication
Drupal distributed authentication is a way to save site users the extra
steps of creating redundant accounts on multiple sites.
(snip... we know how it works :-)
There are some limitations and concerns about the current
implementation of distributed authentication. It would be relatively
easy for someone to alter the code of their site to save a record of
the passwords of users who log in. This is true of any website you
visit, Drupal or otherwise. As long as the username and password only
buys access to that very site, there is little incentive to do this.
If, however, it would allow the malicious person to log into other
sites as well, in this case any Drupal site that has the drupal module
enabled, the incentive is greater and the potential loss or damage
greater. The attacker would be able to masquerade on those sites using
your user identity and execute actions on your behalf.
CAUTION Drupal's distributed authentication is inherently insecure. If
you do not know that you can trust the owner(s) of a particular site,
never use your distributed authentication (Drupal id) to log into it.
Running a directory server
The drupal module offers a simple service by which other Drupal sites
can announce their existence, or "ping" a central server on a regular
basis. While there are many possible applications of such a service,
the most prominent use is the now defunct Drupal sites page on
Drupal.org which was simply a long list of sites that run Drupal.
In practice, any site that has the drupal module enabled can function
as a directory server. When another site pings the site, the remote
site's name, slogan and mission are added to the list of sites. A
useful application of a directory server might be on a college or
university where individual labs or departments are setting up many
different Drupal sites. Each one could ping a central server at the
university to compile a list of all the various sites as they spring
up.
In its current state, the service lacks some basic features. There is
no way for the administrator to block a certain site from pinging and
being added to the list. Nor is there a way to limit the incoming pings
to a certain set of domains or IP addresses. The potential to make a
truly useful directory server service exists, though, and anyone is
encouraged to participate in discussions and development at Drupal.org.
-----------------------
I've come to the conclusion that a module that is this weak should be
offered as a contributed module, not as core. If it weren't in core, I
wouldn't bother writing about it because it is too weak, and poses a
real security threat. My recommendation is that it be placed in the
contributions repository as an example of how distributed auth. for
those enterprising individuals who might want to improve upon it.
------------------------------------------------------------------------
Tue, 20 Sep 2005 10:19:32 +0000 : robertDouglass
tasks don't send mail? Setting to bug report.
------------------------------------------------------------------------
Tue, 20 Sep 2005 10:30:42 +0000 : robertDouglass
The more I think about it, the more I conclude that Drupal.org should
also drop dist. auth. support, or find better security solutions.
Here's an example scenerio to provoke discussion. Gerhard always logs
on to drupal.org as killes at www.drop.org. AFAIK, these sites are now on
two separate servers, and therefore probably have different security
profiles. Now, just as conjecture, let us suppose that the server on
which drop.org is run gets compromised and someone is able to steal
Gerhard's password. They now have a big cat in the bag: drupal.org.
They'd be able to become site/cvs admins for drupal.org, something
which we probably don't want. In the end, if we have no way to say
which sites can be trusted to do authentication, it is a bad idea
allowing anyone to use this in conjunction with drupal.org.
Another example:
http://kerneltrap.org/user/2524
What if Jeremy's server were compromised (or perhaps Jeremy is just
really evil and nobody knows ;-))? In either case, someone would be
able to log into drupal.org with the UnConeD username - not a really
attractive idea.
PLEASE TELL ME I'M WRONG! Or remove the module.
------------------------------------------------------------------------
Tue, 20 Sep 2005 11:17:00 +0000 : eldarin
Robert, you make perfect sense.
;-)
Other servers could get compromised like you point out, and that could
let someone take control of drupal.org if a siteadmin used the
compromised site with the same account login. This could especially be
true if a site used an earlier Drupal version. And it's not only
current sites using this, but future sites and possible future modules
which can be used to compromise security. Someone could offer
my-cool-module.module and distribute it through some other forums,
thereby getting some backdoor access. Using the distributed login
feature, they could behave like a worm.
Ultimately, it's up to the users to show good thinking and NOT use the
same username or password everywhere .. but that is difficult to
demand. Scenario example: two websites have siteadmins which know each
other well (or same person), and same person registers on both sites.
If the password is very similar or a pattern can be discerned and if
that person is a drupal.org siteadmin, the possibility exists that
drupal.org still could get compromised.
There is no way to be foolproof, but helping users along doesn't hurt.
;-)
------------------------------------------------------------------------
Tue, 20 Sep 2005 11:34:07 +0000 : chx
I agree.
I have looked around for better solutions and pubcookies looks good.
(Google on it. I do not have too much too time to write about it.)
------------------------------------------------------------------------
Tue, 20 Sep 2005 13:53:36 +0000 : gravyface
Of course, this assumes that Gerhard uses a different username and
password combination for every site, which most people don't; if not,
you wouldn't need to exploit the distributed authentication to get this
to work -- you could take the average user's account and not only log
into other Drupal sites but into Hotmail, gmail, Paypal, eBay, etc.
I agree with Robert; I think that this should be removed from the core.
Single Sign-on (SSO) [1] is not an easy thing to tackle and outside of
a controlled, private network, it may not even be desired. Look at
Microsoft's Passport failure [2] as an example; the largest software
company in the world could not get this to work and apparently, nobody
wanted it either.
[1] http://en.wikipedia.org/wiki/Single_sign_on
[2]
http://yro.slashdot.org/article.pl?sid=04/12/31/1416212&tid=109&tid=158&tid=95
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:04:36 +0000 : kbahey
For me, I never liked distributed authentication, be it from Microsoft
Passport or from Drupal or anyone else.
The point here is that you are trusting others to do security for you.
Those others can be malicious, or can be slack in their security, or
they got get hacked by someone else.
So, for me, this is something that I will likely never use, whether it
stays in core or not.
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:10:13 +0000 : m3avrck
I agree with all said points. I never had used drupal.module and never
plan to. Great idea in concept, but in reality, just doesn't work.
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:15:45 +0000 : Kobus
I agree with the posts before, but will this influence the drupal-sites
functionality? I have a few old Drupal 4.2 sites utilizing this feature
to list themselves on the drupal-sites page.
Regards,
Kobus
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:30:37 +0000 : Bèr Kessels
1Though potetially insecure, iSSO is one of the best features in drupal.
I'd rather notsee this end in the null bin, for it will then be lost.
forever. What about a revive/rewrite?
Here are my thoughts: case: drop.org user 'foo' log into Drupal
drupal.org pings drop.org. Drop.org retruns TRUE if the pinged details
are correct.
foo at drop.org is NOT a user nor gets a uid on drupal.org. never! For as
long as the session takes, he is a 'registered' user.
if foo at drop.org visits 'my account' and changes anything in there, he
gets a uid, welcome mail and a native drupal.org user. That has, from
then on, nothing to do with drop.org, drop.org will never be pinged
anymore. Off course one is required to fill in a new password and an
email addy.
if foo at drop.org never visits 'my account', or does not change anything
in there, the user 'foo at drop.org' will be lost as soon as the session
terminates.
drupal.org user with a lot of rights 'foo' logs into drop.org
drupal.org will send TRUE when it receives correct login details.
foo at drupal.org is NOT a user nor gets a uid on drop.org. never! For as
long as the session takes, he is a 'registered' user. but drop.org
knows nothing, nor saves anything on drop.org. only packet sniffers can
track the user details;
This is very much how it works now, with one difference: you have to
actively undertake something to me changed from remote user to native
user. You have to actively undertake something to get yuour details in
the database of the other site.
This, Icw some common sense (Dries should be aware that he must not use
his drupalID on WannaHackdrupal.pr0nnet.ro) thiswill do, IMO.
First rule of securit is clarity:
if your users see and feel what happens, your security is much better
maintainable. This is not really the case ATM.
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:31:40 +0000 : killes at www.drop.org
I am using my username only for historical reasons. drop.org is down and
I've not been using distributed auth for quite a while. I agree that
drupal.module's distributed auth isn't up to date any more and people
shoudl be discouraged from using it.
------------------------------------------------------------------------
Tue, 20 Sep 2005 14:55:44 +0000 : Prometheus6
The module would be useful if the side that does the authentication had
a list of trusted sites. That would let you have single sign-on across
a range of related sites. But that still means it's more appropriately
a contribution module.
------------------------------------------------------------------------
Tue, 20 Sep 2005 15:52:16 +0000 : Peter Apockotos
I like the idea of the module.
I just wish it wasn't tied to drupal.org itself.
Perhaps a setting of which (trusted) sites to share the information
with instead.
------------------------------------------------------------------------
Tue, 20 Sep 2005 16:20:59 +0000 : nedjo
Thanks for bringing this issue up, Robert. See for reference the
related issue "Refactor and rename drupal module",
http://drupal.org/node/29826
The near consensus I'm hearing is:
1. The functionality areas covered in the drupal.module are valuable
and desired.
2. But the current implementation has serious flaws, and therefore
fails to meet clearly the standards for drupal core inclusion.
There are probably three basic options:
1. Keep the module in core, with the commitment to fixing its flaws.
2. Temporarily (e.g,. for one release cycle) pull the module from core
with the aim of refining it enough for reinclusion.
3. Remove the module from core to contributions.
While I agree with the serious limitations of the current
implementation, I'd hate to see this functionality area disappear from
core. Projects pulled from core tend to languish. So I favour
options one or - perhaps better - two.
Inter-site functionality similar to what is covered in drupal.module is
in increasing demand. Projects like the telecentre.org initiative
centre on such functionality. CivicSpace has expressed keen interest
in improving the ability of webs of related sites to discover each
other, connect, and pool information. Look again at our mission,
http://drupal.org/node/10250. Inter-site connections are increasingly
key to "the collaborative production of online information systems and
communities".
Let's focus on fixing the module!
More information about the drupal-devel
mailing list