[drupal-devel] [bug] Remove drupal module from core

[GravyFace]

And SSL is a bad thing?

On 9/20/05, Prometheus6 <drupal-devel at drupal.org> wrote:
>
> 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: Prometheus6
> Status: patch (code needs review)
>
> Hm. Pubcookie requires SSL and (possibly worse) accurate system time.
>
>
> http://www.pubcookie.org/docs/install-mod_pubcookie.html#req
>
>
>
>
> Prometheus6
>
>
>
> 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 <http://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<http://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<http://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 <http://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 <http://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<http://drupal.org>
> .
> They'd be able to become site/cvs admins for drupal.org<http://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<http://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 <http://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 <http://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 <http://drupal.org> siteadmin, the possibility
> exists that
> drupal.org <http://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 <http://drop.org> user 'foo' log into
> Drupal
> drupal.org <http://drupal.org> pings drop.org <http://drop.org>. Drop.org<http://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<http://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 <http://drupal.org> user.
> That has, from
> then on, nothing to do with drop.org <http://drop.org>, drop.org<http://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 <http://drupal.org> user with a lot of rights 'foo' logs into
> drop.org <http://drop.org>
> drupal.org <http://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 <http://drop.org>.
> never! For as
> long as the session takes, he is a 'registered' user. but drop.org<http://drop.org>
> knows nothing, nor saves anything on drop.org <http://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<http://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<http://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 <http://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<http://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!
>
>
>
>
> ------------------------------------------------------------------------
>
> Tue, 20 Sep 2005 17:28:34 +0000 : javanaut
>
> 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.
>
>
>
>
> ------------------------------------------------------------------------
>
> Tue, 20 Sep 2005 19:23:47 +0000 : Boris Mann
>
> Both CivicSpace (Kieran, I think we agreed on this) and Bryght are
> commited to developing distributed authentication functionality.
>
>
> We would love if something shipped by default with Drupal core.
>
>
> OpenID is my current best bet, although as chx pointed out, Pubcookie
> looks excellent for the more corporate market.
>
>
> My proposal would be to make drupal auth an OpenID compliant server,
> and to make the "base" dist auth have the proper trust
> relationships/security that people could be confident in using it in
> most standard security situations.
>
>
> The current "drupal" module would actually become more of a container
> for dist auth in general, as it has been in the past. One of it's
> functions might be (for example) mapping remote information to local,
> as we implemented for the SXIP module.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drupal3.drupal.org/pipermail/development/attachments/20050921/cd68988c/attachment.htm