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: chx Status: patch (code needs review) 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.) chx 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@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. ;-)