Hello everybody.

Drupal sends login password using plain text
wich makes really easy password sniffing.
(ever tried ethereal in an hub connected lan???)

It is possible to secure sending of password using md5 hashes
on the client side using javascript.

A good example and explaination of this could be found at
http://pajhome.org.uk/crypt/md5/auth.html
here some demo:
http://pajhome.org.uk/crypt/md5/chaplogin.html

The patch attached is a first attempt in changing login procedure to let
user browser do the md5 password hasing before send it.

While an attacker can still use it for logging in to the drupal site
this prevents to reuse the password on other sistems where the user
has an account.

A more advanced usage of this technique is implementing a
"challenge response" system as described in
http://pajhome.org.uk/crypt/md5/auth.html

Yahoo! Mail Italia use this.
Also Yahoo! Mail International seems use it.

This patch is only for demostration.

Fabio Varesano

CommentFileSizeAuthor
#11 drupal_md5.diff116.56 KBfax8
tree_0.diff11.26 KBfax8

Comments

Richard Archer’s picture

Richard Archer commented

This algorithm is susceptible to a playback attack. The listener records the md5 sum and simply sends it instead of the password. You have to send a unique value with the form and calculate the md5 sum of the password concatenated with that unique value. The unique value is stored in the session before sending the form and invalidated once used.

You also need to make sure you fall back to plain text passwords if javascript is not available.

You can see a correct implementation of this in PHPLIB:
http://sourceforge.net/projects/phplib

In particular:
http://cvs.sourceforge.net/viewcvs.py/phplib/php-lib-stable/php/crclogin...
and
http://cvs.sourceforge.net/viewcvs.py/phplib/php-lib-stable/php/local.in...
(see class Example_Challenge_Auth...)

Richard Archer’s picture

Richard Archer commented

Sorry, I should have said "this implementation is susceptible".

The algorithm is great if correctly implemented.

fax8’s picture

fax8 commented

yeah I know the playback problem... (as I wrote on the first post)
this patch was only a first implementation top show a basic usage.

chx’s picture

chx commented

This has been discussed before. http://www.sanisoft.com/phplib/manual/auth_Response.php I guess we should use this.

deekayen’s picture

deekayen commented

I wouldn't give user's the false sense of security claiming javascript is any better for protecting passwords. This slippery slope will only make headaches when you start thinking about XMLRPC. Security on HTTP is SSL right now. If you really want to use Yahoo as an example, that's why Yahoo! USA has Standard and Secure (read SSL) login options (not Standard and Javascript).

fax8’s picture

fax8 commented

sure. making a drupal site SECURE is only using SSH.
But why don't use md5 hashing when possible????
this will be sure a better protection.

For non local login we can test on username using js.
If(is_as(name@site.dom)) do not use md5() and send plain.

No headache needed.

fax8’s picture

fax8 commented

sorry: SSH was SSL

deekayen’s picture

deekayen commented

If you accept the hashed password, you're canceling out the benefit you get from hashing the stored password in the db. If someone gets an exploit to output the DB hashes, having a method to accept the hash as the password then IS the password. If you can only send the password, not the hash, then when the DB/server is exploited, only the hashes that were originally dictionary passwords or that can otherwise be brute forced are able to be used to login.

fax8’s picture

fax8 commented

I agree with you David.

You marked a real problem for this implementation.
The problem still appear on a "challenge-response"
implementation (which I'm working on..)

I think we have 2 different weak situation:

1 - sniffig: someone can intercept client-server clean traffic.
(as currently)

2 - somone exploit the drupal db and is able to read user table
(with md5 hashed passwords)

The problem is understand the probability of the two.

If we think that is more probable/dangerous the first situation
then an hashed login (using challenge-response) should be a
good solution.

Instead if we evaluate more probable the second, then current
implementation with plain password is a good solution.

Please also note that a man in the middle attack (1) will not only
open drupal site login system but also the attacker will get good
passwords for reuse on other (more important) systems.
(Lot of users use only a password for lot of theyr account,
drupal or Paypal is the same... )

Instead an exploit (2) will open the system to cracker but still
protect passwords to be reusable on other systems.

Fabio

deekayen’s picture

deekayen commented

...but again, the correct solution is SSL. Have that, and there is no exploit to find the original password other than brute forcing the hashed passwords in an exploited DB. Giving users the false impression that the JS is anything related to secure is wrong since someone will end up NOT implementing SSL because they think the JS does "encryption". It's not equivalent.

Anyone that uses their paypal account password over a clear line deserves what they get, anyway.

fax8’s picture

fax8 commented
StatusFileSize
new drupal_md5.diff116.56 KB

Hi!

I started this thread about MD5 password hashing
thinking that should be useful for users.

I posted to the developer mail-list ant to this thread.

But I received only few comments on this feature request...
so I was thinking that nobody were interested on it...

Instead on this mailing list (which I did't read for some time)
discussion was live..

So attached there is the patch (one week cvs) which is
a beginning of implementation of a challenge-response auth.

Hope someone interested in this.

Fabio

caligari’s picture

caligari commented

From development@drupal.org list:

Have you tested it with charset cases? Does JS show same MD5 value in
UTF-8 as in ISO-X-Y charsets? It could result in a crash test...

I think that JS hashing gives more problems than benefits. May be a
virtual keyboard to avoid keyloggers...

saerdna’s picture

saerdna commented

im sorry to say but this sounds seriously bad. most of the negative arguments has already been said. im not the one who will force any user of my site to use javascript.

Your "2 different weak situation" is not a drupal issue, its a gernal http issue. all sites has this problem. consider use ssl. i do and it works like a charm.

Jaza’s picture

Jaza commented
Version: x.y.z » 6.x-dev
Status: Needs work » Closed (fixed)

Closing this issue, since the majority of responses towards the proposal have been negative. -1 from me as well.

Moving to 6.x-dev queue, in case someone wants to try and revive this thread.

shap’s picture

shap commented

As comment #8 notes, this proposal is simply broken. It merely trades one clear-text password for a second (the md5 of the original clear-text password). There is a solution: use two MD5 steps as follows:

  1. When emitting the login page, server embeds a randomly generated nonce into a hidden field somewhere. Server must remember that this nonce is associated with this session.
  2. User types their password.
  3. Client-side javascript generates md5(clear-password).
  4. Client-side javascript now concatenates the nonce to get nonce+md5(clear-password)
  5. Client-side javascript computes md5(nonce+md5(clear-password)) and sends this to server.
  6. Server computes md5(session_saved_nonce+previously_stored_md5_of_clear_password), compares this against what came from the client.

    7. This scheme cannot be replayed, because the nonce cannot be reused. Note that the server must not retrieve the nonce from a hidden form field -- that would permit replay.

    The defenses here are in multiple parts:

  • The inner md5(clear-password) guarantees that the user's password is not stored in the clear on the server. The server nonetheless has a shared secret with the user that never crosses the wire. Because md5(clear-password) can be regenerated on the client, the user does not need to remember a long hex string :-).
  • The nonce plus the outer md5 guard against replay.
  • The fact that the nonce is a salt applied to a shared but undisclosed secret allows the server to check the second md5 result for validity.
  • The fact that the nonce is use-once guards against replay.
  • The fact that the server sends the nonce but does not trust any nonce received from the client is also necessary to prevent replay.

    • This protocol is secure against replay and also against disclosure. Note, however, that there are now mature attacks against MD5. Using SHA1 would be a better choice if that is possible.

    Issues not solved by this proposal:

    • Computing MD5 or SHA1 in Javascript may be too expensive.
    • This proposal does not address the problem of password changes. Solving that requires client-side encryption, not just an HMAC. The method I have described can be used to bootstrap that encryption. The string nonce+md5(clear-password) can be used as a symmetric encryption key for sending the new password. I have no idea if any reasonable symmetric encryption method can be performed sensibly in Javascript.
    • The scheme requires javascript. This is a problem for users who are vision-impaired, since many of the text-based browsers do not implement javascript.