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.

CommentFileSizeAuthor
drupalmod.patch11.15 KBrobertDouglass
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dries’s picture

Status: Active » Needs review
robertDouglass’s picture

Category: task » bug

tasks don't send mail? Setting to bug report.

robertDouglass’s picture

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.

eldarin’s picture

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.
;-)

chx’s picture

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.)

gravyface’s picture

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) 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 as an example; the largest software company in the world could not get this to work and apparently, nobody wanted it either.

kbahey’s picture

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.

m3avrck’s picture

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.

Kobus’s picture

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

Bèr Kessels’s picture

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@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@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@drop.org never visits 'my account', or does not change anything in there, the user 'foo@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@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.

killes@www.drop.org’s picture

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.

Prometheus6’s picture

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.

IamPter’s picture

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.

nedjo’s picture

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!

javanaut’s picture

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.

Boris Mann’s picture

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.

Prometheus6’s picture

Hm. Pubcookie requires SSL and (possibly worse) accurate system time.

http://www.pubcookie.org/docs/install-mod_pubcookie.html#req

Dries’s picture

I'm a little surprised no one rejects. I guess I'll remove it shortly.

Bèr Kessels’s picture

well, I rejected, as did some others, Be it in the words: "this must be fixed" ... "removing this will not help improvement, improvement first"

javanaut’s picture

I think most people have no problem removing the current dist auth implementation, but would like something more robust to replace it. IMO, moving it to contrib until a better solution is devised would be the safest option. Some people will definitely be upset about this, though.

I never saw any argument supporting the removal of the "Directory Server" feature, though. Yes, it is lacking some features, but I don't see it as much of a threat (relative to the dist auth feature). The patch seems to remove this functionality along with dist auth. Any reason why this should be removed from core?

robertDouglass’s picture

re: encrypted password. We need to walk through the scenario a little bit. Two sites, good.com and bad.net. I'm originally a member of good.com, that is where my encrypted password is stored. I then go to bad.net and think "Groovy, a Drupal site. Time to use my Drupal ID". I then type in my username, the name of the server I'm registered at, and the password that buys access to that server. The bad.net site silently logs these in plaintext, does the authentication like normal (sending the hashed version of the PW over the wire) and lets me comment on Joey's blog. Meanwhile, bad.net's admin has done a Google search to find out all of the other sites I've posted on using my Drupal ID and starts evaluating which one is the biggest bounty. For example, perhaps good.com is my own site where I'm likely to be the admin. The bad.net admin then logs on, creates a new page with PHP content, installs a root kit by hitting Preview (no watchdog message for that) and turns good.com into a spam-bot.

chx’s picture

if you use uid 1 or any user with super cow powers for remote auth then we can only pity you...

killes@www.drop.org’s picture

chx: we can't expect that users know how this feature works. Most computer users don't know/care enough about security.

Bèr Kessels’s picture

@killes. correct. hence making it more obvious WHAT this module does would improve it a lot!
Does it allow drupalID, or listings in the /sites directory? Will it send along my password to the other site or not? Can others see my details on foo.com when I log into bar.com with user@foo.com etcetc. The current module is very bad in communicating this.

the first step in security is to make you users care.

chx’s picture

killes: yes I know. Note that I have opted for the removal of drupal module. When we talked of jabber / gmail auth it was you and James who talked me out of it...

chx’s picture

what I meant to say is that you two talked me out jabber for the very same reason drupal module is dangerous: password collection.

Boris Mann’s picture

Status: Needs review » Needs work

Dries: I don't think we want it removed from core -- we just want it fixed, and as I suggested, be morphed as a front end for dis t auth, and the default Drupal dist auth can be removed from the code.

Now just up to us to supply patches, I guess. Setting to "needs work".

jon@jony.net’s picture

Status: Needs work » Closed (won't fix)

I just wanted to add my two cents. I think that the distrubuted authentication one of the best features drupal has going for it, and i would be very sad to see that removed from core. What I propose is to add a white list, for trusted sites, in witch you agree to accept distributed authentication from those sites. In this manner, I could agree to accept users from drupal.org, but not users from bad.com. Another idea I've heard, would be to alow users to define a seperate password to be used with distibuted auth. I know this sounds confusing, but it would eleviate the worry of the plain text passwords. One time use passwords are also another idea. I dont know how that would work, but its an idea.

killes@www.drop.org’s picture

Status: Closed (won't fix) » Needs work

jon: I think you don't understand the issue. it is not about accepting logins from elsewhere. it is about the guy who accepts your login stealing your password. Yes, it is ultimately the responsibility of the user to think about what they are doing, no, they don't.

scriptnews’s picture

Title: Remove drupal module from core » DON'T ... Remove drupal module from core

Hi

just 0.1 cent about the same ...

Please don't remove, BUT change the feature.

I agree that there is or seems to be a risk - and then their is a hurdle in the use of the module:

I would give a group of persons access to my site, if I had an idea and trust about who they are.
In the case of the Drupal Net I do not have that.

But it would make perfect sense, to share login and some user data between somehow related sites, for example in the case of a specific business network, where different organisation have a drupal site and then, for limited features (example: handling of their own RSS-feeds, agenda, advertising, news,pictures ) they would allow each / the / some other to access.

So in resume: dont take this module out but allow discretion in the access allowances.

Cheers

Roland
http://centroamerica.tv
(soon a drupal site)

robertDouglass’s picture

Title: DON'T ... Remove drupal module from core » Remove drupal module from core

1) Leave the title of this issue alone.

2) If you're not a core committer, don't change the status of this to won't fix

3) A list of trusted sites won't help you with the problems I've described.

4) Moving this module out of core and into the contributed repository won't stop you or anyone else from installing and using it if they feel comfortable with the risk or have a different situation where the risk doesn't exist.

5) There are other modules (SXIP [1]) that do distributed auth better than the current implementation. Check them out.

[1] http://drupal.org/project/sxip

Souvent22’s picture

I have an idea for an authentication theme. What if used a user challenge and password supplied from their 'Main' site? It would go something like this:

1. User enters their username@drupal.og with NO password
2. A screen then pops up with a challenge to the user that THEY created.
a) e.g. 'What is your favorite interstate?'
b) Answer: '465 East'
3. User is authenticated through the challenge. W/o compromising their password.
4. If the site has 'hacked' their drupal install, they will have only the challenge answer, but not the users password.

What do you think?

killes@www.drop.org’s picture

What to do now? Nedjo has worked on adding a new feature to this module which just got committed, so I guess nobody wants to remove it now.

robertDouglass’s picture

Well, then it should be made secure.

m3avrck’s picture

Agreed, we need to look at how Drupal.module is currently working and rework it based on the above feedback. I think with the features nedjo has committed there are many new, useful possibilities with this module, so let's do our best to secure it down.

Either that, or split the module: distributed authentication and reporting back modules/themes/etc type features. Unless they are tightly coupled, but I haven't had a chance to look over the code yet, but let's get the ideas flowing once again, and hopefully some usable code.

webgeer’s picture

Although I agree there is a problem and previously suggested a partial fix of this problem: http://drupal.org/node/21998 , I think it should be pointed out that many drupal sites are community sites that grant "authenticated user" status to anyone who asks and therefore if I use a simple "authenticated user" account from my website on other sites, I don't risk someone stealing any special priviledges. Theoretically they could post as me if they stole the account information, but this is really a pretty minor risk and as pointed out for these types community accounts most people probably use the same username/pasword combination anyways. (personally I use different passwords on sites that "matter", but on most community websites/forums/wikis I use the same or similar combinations)

I think that Maintaining distributed authentication in core is a important as this makes remote authentication quite common and therefore useful. If it were an contributed module, very few sites would bother with it and it would loose most of its usefulness. I think this should be fixed up and kept in core.

As an initial solution I suggest that a good explanation of the security risks be given in the documentation and that a new access control setting be added for "refuse remote authentication" so I can make sure that the trusted users on my website don't use their accounts from my site for remote authentication on other sites and expose my site to potential hacking (Of course I can't really prevent them from using the same username/pwd combination, but at least the username doesn't direct a hacker back to my site), but still allow simple "authenticated account" users to use remote authentication. Probably this would work both ways an account with this setting would not confirm the account to remote sites, but instead send an error "Remote authentication not permitted for that account" and if someone was using remote authentication and they had this setting it should force them to convert the account into a local account.

Zen’s picture

I would prefer to see passwords taken out of the equation completely, but still retain site-to-site authentication rather than use any centralised methods.

Here is how I think this should work - Site A is the local site, while Site B is the remote site:

a) Enabling Drupal ID creates a role named temporary with only access to "create comments" (by default).
b) When "user@site_b.com" logs in [with just his username] on Site A, Site A queries Site B with the username. Site B checks database and returns the first 3 octets of the user's last known IP address.
c) Site A matches IP address and if successful, authenticates user as a "temporary" user. If not, Site A requests user to try logging into Site B and then try again.
d) Drupal ID users are alloted a limited session time of say 24 hours after which they will have to re-authenticate themselves.
e) Users can be given an option in their profile as to whether they want their accounts to be eligible for Drupal ID - turned on by default.

Using the first 3 octets should accomodate any network vagaries/proxies and the like, at the expense of a little inaccuracy. Perhaps a configurable subnet mask will allow the admin to address special cases or adopt a more stricter approach. The 3 octet approach should also allow for a degree of anonymity/privacy for the user.

The Temporary role provides the admin control over what these chaps are allowed to do - download files etc. Other options such as comment restrictions (x/hour), IP/website blocking etc. will also help increase security.

This should keep things simple and allow for the basic level of authentication that is being sought. I (personally) would be happy and feel reasonably safe with this system.

Also, post-authentication - the users shouldn't really be referred to as user@site_b.com. This might very likely be a valid email account, and also encourages spammers to spider through your site on a regular basis attempting to harvest all these email addresses.

Hope all that made sense :)
Thanks
-K

Jaza’s picture

Version: x.y.z » 6.x-dev

Moving to 6.x-dev queue.

My $0.02: drupal.module shouldn't be taken out, but it definitely should be modified to use more secure (possibly tried-and-tested third-party) authentication methods.

Dries’s picture

I'd like to replace it with an OpenID client implementation (not an OpenID server implementation). Other systems like Wordpress and Joomla are adopting OpenID as well.

Let's keep drupal.module for its ping home function, and remove the distributed authentication part. For that, we can add a new openid.module to core.

Bèr Kessels’s picture

'Today' there are rather few options to choose from when registering an OpenID, AFAIKS there is no ready-to-go application that acts as your server (I've tried several, butall are very beta), so it is far from straightforward to get such a server running. This may have a severe impact on the side of implementing OpenID. with Drupal Id its a matter of flipping a switch, and providing the server and the client side.

I therefore plead for a server as well. Not in core. But at least in a maintained contrib. Else we loose a (for many people) critical part from the featureset we now offer.

That said, I think OpenId is the way forward. I think people interested should join the work-group distributed-authentication http://groups.drupal.org/distributed-authentication

Boris Mann’s picture

Just an update to point to http://drupal.org/project/openid. There are two modules in there, one is a server, and one is a client, both in the 4.7-2 branch. So, needs updating to 5.x and then integrating into 6.x branch.

Also, we could of course turn on the server component on Drupal.org (or home.drupal.org if we want to run the identity separately) and continue to allow @drupal.org logins.

http://home.bryght.com is an example server. You just create a Drupal account and it is automatically an OpenID identity.

Definitely work in progress, but the client is fairly simple. Patches welcome :P

Bèr Kessels’s picture

@boris: I have two small patches for the 4.7 branch of the client in your SVN. Where can I put them?

Which raises a point: would it not be better to put these modules in the drupal cvs without releases, so that we can create issues/attach patches for them?

pwolanin’s picture

In the context of gathering data on modules & themes used (http://drupal.org/node/79550):

As a first step, could the "phone home" part be cleanly split off from the authentication part? Maybe the phone home part could be merged into another core module (or be a core .inc) with an optional setting to enable it?

Also, module & function names should be renamed per: http://drupal.org/node/5243

pwolanin’s picture

moshe weitzman’s picture

Status: Needs work » Closed (duplicate)

as pwolanin said, see http://drupal.org/node/29826