authentication service rethink

We could open up a discussion on this but this is not a bug as it is. I will talk with Heine.

The issue with the current distributed authorization is quite obvious; it is undesirable to provide your password to another (untrusted) site. I think we can implement a better system for the next release.

Signing on to another site with your username and password, does make your authentication information available to that site. However, between trusted parties this isn't an issue which is what the feature is for. Say drupal.org and groups.drupal.org as an example. For intranet uses it is also safe. Updating drupal's distributed system has been at slow simmer on the back burner for a while. I believe OpenID is the favored option.

Refiling to 6.x-dev.

+1 from someone who supervises a whole herd of Drupal installations. I don't use the 4.7.x / 5.x authentication service because it appears to pass plaintext passwords over HTTP; instead I created a 'master' installation and replaced users on 'slave' installations with an SQL VIEW.

@dopry - I agree, OpenID sounds great. There's mature PHP code — size savings could be made by not supporting legacy versions. There's also a module that does OpenID delegation, but that wouldn't even be needed if Drupal responded to OpenID discovery on user URLs (drupal.org/user/70498) or aliased URLs (drupal.org/user/Paul_Kishimoto or drupal.org/Paul_Kishimoto).

This make Drupal more attractive to users who already run their own OpenID servers/delegation, and also provide a turnkey ID solution to new users.

Subscribing.

In my opinion, there is an easy fix for this. The current method is good all except for the part where you are sending plain text passwords, right? So no big deal, don't send a plain text password. Just have it send the MD5, and the function will check to see if the MD5 of the password entered matches the MD5 of the password in the authentication database.

Seems logical to me, am I missing something? I can't see the point in redesigning the entire system, it could be fixed without a doubt.

Also, I think MD5 should be phased out. It is getting cracked more and more everyday. Hell, there are even websites out there which will crack a hash for you (http://md5.benramsey.com). We should look into switching Drupal to something more secure like Sha1 or Sha32. If any of you are familiar with vBulletin, it uses MD5 but the hash cannot be cracked without a unique code called "salt" which is different for every user. Something like that would be equally as secure.

-Jordan

@theoverclocked — Unfortunately, hashing the password before the authorization request doesn't solve the problem. If it is passed as plain XML, the MD5 hash (or any other token) can still be snooped and re-used to get the authenticating website to believe the corresponding user is actually trying to log in. This is a form of man-in-the-middle attack.

Really what's needed is something like SAML, OpenID with a transaction security layer, or similar. A proper implementation of one of these protocols with proper hooks for module developers would really be closer to a redesign than a patch of the existing system. I created a Summer of Code 2007 proposal, because it seemed like several weeks' worth of work.

hmmm well that is all too true.

I was merely thinking about the plaintext vulnerability, but I now realize there is a larger issue to be solved here.

openid client is in core. please ropen new issues as needed.