Challenge / Response login

Some comments bei redLED on #drupal:

01:12 < redLED> "interesting, but not generally applicable"
01:13 < redLED> ssl generates chain of trust warnings if you use it out of context
01:13 < redLED> e.g, without a valid certificate
01:13 < redLED> and without a dedicated IP address
01:13 < redLED> you can't bulk-host SSL on same IP like you do with apache vhosts
01:13 < redLED> the errors will obviously be confusing
01:14 < redLED> valid certs cost $'s, dedicated ip for ssl hosting costs most people $'s
01:14 < redLED> now
01:14 < redLED> what we probably do want to do if we want to improve security
01:14 < redLED> is steal someone's GPL javascript implementation of MD5
01:14 < redLED> then hash the password client-side, on the browser
01:14 < redLED> and then send it for verification

I am not sure the JS idea will be mich better than sending the password. If somebody can get the hash, he will also be able to submit the same http request.

If there is any interest in using a Javascript hashed, challenge-response login which falls back to the plain text arrangement we have now if the browser does not have Javascript enabled, there is well-tested (in use for years) GPL code to do it available from the PHPLIB base library:

http://phplib.sourceforge.net/

+1

Although I agree with killes that this isn't a proper solution, I think it might be useful to at least not send the password plain-text. Yes, this is security through obscurity, but IMHO it's still slightly better than no security at all.

MD5-hashing the password on the client-side offers no security. The only security you can get is by hashing the password-hash concatenated with a random key to prevent replaying the HTTP request. But this gets tricky, as we need to tie the key to the client/session. We can't use cookies, because if an attacker can spy on network traffic, he can retrieve the cookie/session ID too and imitate the client.

I'm not sure if PHP sessions are tied to an IP, but even if they are, there are cases where people might share an IP (e.g. NAT firewalls). Plus, in the case of such a local area network, the chance of someone spying on traffic is often bigger due to misplaced trust.

The complicated SSL mechanism exists for a reason, we should not try and duplicate it.

The patch does not apply anymore.

I am working on a new version of this patch, should be available very soon, if it's not please send me an e-mail.

I played around with this patch as well, on my 4.6.x system, and with some tweaking it does work as "intended". However, it only seems to apply to the login pages, which I found less than ideal since user password (and possibly other sensitive information) is sent in clear text in several other pages and forms. For instance, changing your password would still send the password in the clear.

So, with this in mind, I prepared a slightly different "patch" for this, which I've made available at

http://www.ogre.com/tiki-download_file.php?fileId=9

Sorry, it's not using Drupal yet, hopefully soon :-). Note that this patch doesn't change the user module at all, it's all done in the common.inc file instead. I thought this was "cleaner". Let me know what you think.

-- leif

Hey guys,

I am currently using this bit of code in my own web application, still determining whether to use drupal or another CMS ...

This works fine as it redirects the user to an https connection. I haven't done anything to redirect the user back to http after authenticating or viewing a page that does not requires ssl.

I am not quite sure how this would get implemented in drupal without touching their code as well as tables. All I know is that this works fine for redirects and prevents the infinite loop (redirecting to oneself).

Walter

I apparently couldn't include my code because it was suspicious ...

Here it is attached, hopefully it is.

Anyways, with this class file I have attached, I extend it with a class customized for my website ... it changes which page is displayed (first visit, and what the root url should display, folder, element, ...).

I apparently couldn't include my code because it was suspicious ...

Here it is attached, hopefully it is.

Anyways, with this class file I have attached, I extend it with a class customized for my website ... it changes which page is displayed (first visit, and what the root url should display, folder, element, ...).

Walter, it looks like your code just redirects users to "SSL" pages. The problem is, by the time the redirect is posted in the HTTP response, the form submission (username and password) has already crossed the wire.

I would not recommend using this method.

zoop's patch, while a tad kludgy, is very clever. (There's no non-kludgy way to do it, I'm afriad, without being a bit invasive into the code.) I suggest using zwoop's patch instead.

Zwoop's patch seems to work fine here. I will be expanding on it that other pages with sensitive personal information like addresses in e-commerce check-out, will be in SSL mode as well. I will try to make something where the user can add other URLs that will switch to SSL mode.

Ok, chx has talked me into working on this as a challenge/response login.

Changed the title, and assigned it to myself.

Basic theory of how this will work

The login form uses a challenge/response mechanism to authenticate the user. The password does not travel over the network if the client browser has Javascript enabled.

Drupal will generate a challenge value which is incorporated into the login form. When the user tries to submit the form, md5("username:password:challenge") is calculated and filled into the reply field. The password field is erased.

The server can calculate the expected reply and compare it to the actual reply value. If they match, the user is authenticated.

If the reply field is empty and the password is set, the server knows that the client cannot do Javascript. The user can still be authenticated, but the password will have crossed the network as it does now.

Draft Javascript bits

// <sscript src="md5.js"></script>  <-- needs to be obtained -->
// <sscript>
  function doChallengeResponse() {
    str = document.login.username.value + ":" +
          MD5(document.login.password.value) + ":" +
          document.login.challenge.value;
    document.login.response.value = MD5(str);
    document.login.password.value = "";
    document.logintrue.username.value = document.login.username.value;
    document.logintrue.response.value = MD5(str);
    document.logintrue.submit();
    return false;
  }
// </script>

Draft PHP bits

function user_login(...) {
  $challenge = md5(uniqid($magic));
  $form['challenge'] = array('#type' => 'hidden', '#value' => $challenge);
  ...
}

function user_login_validate(...) {
  ...
  $expected_response = md5($account->name .':'. $account->pass .':'. $challenge);

  if ($form_values['response'] != $expected_response) {
    form_set_error('login', t('Sorry. Unrecognized username or password.') .' '. l(t('Have you forgotten your password?'), 'user/password'));
  watchdog('user', t('Login attempt failed for %user: %error.',           array('%user' => theme('placeholder', $form_values['name']), '%error' =>        theme('placeholder', $error))));
  }
  ...

Hmm afaik this will not work:

function user_login(...) {
  $challenge = md5(uniqid($magic));
  $form['challenge'] = array('#type' => 'hidden', '#value' => $challenge);

The $form array is not stored anywhere between requests, but created when needed (this makes sense when you think about it, because there is nowhere for it to be stored). So the challenge would be different when the form is output than when it is processed, and login would fail.

The problem is that we need to tie the challenge to the end-user somehow. But, ip/hostname tends to work badly because of multiple proxies at an ISP.

Let's step back though. Suppose we do get a reliable unique challenge/response going. That means an attacker can not replay the authentication... but he could still just sniff the session ID cookie and use it directly! Remember: our sessions are not tied to IP either (for the same reason as above).

And if an attacker can not just sniff, but also intercept traffic, then he can simply strip out the Javascript and force a plain-text log in.

So it would seem that the use of this patch is only to prevent plain-text passwords from travelling around. While it does offer a tiny bit of safety for the end user (especially for people who re-use passwords), it is not much at all. If a feature like this is added we need to clearly document what it does and does not protect.

In order to handle SSL logins securely, you need to add

php_value session.cookie_secure 1

to your .htaccess or httpd.conf. Any newly created session cookies will be set to only be sent back to the server over encrypted SSL connection. When users connect via the regular http URL, they will always be logged out, even if they have a valid session on the https site. But this configuration does have the advantage of not causing browsers to send session IDs over an unencrypted connection.

I believe Steven's remarks on the usefulness of this feature raise an important issue. Do we really want to implement this feature? It provides some amount of additional security, but it is not panacea. Because of the challenge with keeping the challenge value across forms that Steven pointed out, the technical effort will be higher than I originally thought. Thus the feature has a lower cost-benefit ratio.

IMHO it is "won't fix".

Now we just need chx's agreement, since he directed me to pursue this thing. :-)

"So it would seem that the use of this patch is only to prevent plain-text passwords from travelling around. While it does offer a tiny bit of safety for the end user (especially for people who re-use passwords),"

i think this is a significant win ... phpmyadmin does this as well as some other major projects.

Challenge/Response were discussed earlier.. I was one of the biggest fan of this...
http://drupal.org/node/36793
http://lists.drupal.org/pipermail/development/2005-November/011022.html

There were lot of comments there and I finally understood that the real way to get
security is over an SSL connection.

also check
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/challenge_res...

I would like to argue for a less secure yet better-than-no-security approach, coupling the question of sending the password as clear text with another (new) useful user account feature.

Consider this scenario:

• I am increasingly working through public Wi-Fi networks, "insecurely".
• I use SSL on all my own sites, and becoming increasingly aware of how valuable my identity/history/user/etc. is (becoming, increasingly). So I am trying to avoid web services that does not do at least basic protection of my credentials. If I know that by starting to use a particular web service - and if it turns out to be satisfactory, leading me to become "dependent" on it (meaning I will hate to loose it or get my login stolen), then I will look to find another similar service that provides basic security before I even get started with the one that would be my first choice, if it wasnt for the lack of protection.
• For me, most often it is sufficient if I know that at least not tech novices or the common (wo)man could just get a tool from the internet to intercept the traffic and get hold of my credentials in clear text. Even if it would be fairly simple to get around this, I think it will significantly reduce the number of people who could "easily" get hold of my credentials. That is enough for me when it comes to a site like drupal.org, for example.

An important additional feature that will help us accept the above:
I love the way sites like Yahoo is using a separate "security key" that cannot be the same as the current password. This means that even if someone gets hold of my login, at least they cannot manage to block me out of my account as they would not have the second "key" that let them change the password. The only thing they could do was impersonate me. I would probably notice, and be able to change my password to block them out.

I mention this here in this issue even if this could be a separate feature request. If this sounds interesting, maybe we either use this issue for this, or file a new one about a secondary "key" (password).

FYI - there is a "duplicate" (open) issue here:

"SSL security for login/admin" :
http://drupal.org/node/1577