Page 1 of 1

A simple PHP based DES encryption module (not MCrypt)

Posted: Wed Apr 07, 2004 12:12 pm
by budgefeeney
I'm doing a site which involves people changing passwords. It's not done over HTTPS. I can encrypt the new password with the old password using DES or Triple-DES on the client side with JavaScript.

The problem is on the PHP site, the host does not support the MCrypt extension. I was wondering if anyone had ever implemented DES or Triple DES using PHP alone, and if it was available anywhere.

Thanks :roll:

Posted: Thu Apr 08, 2004 12:19 am
by kettle_drum
Im sure it can easily be done, ill try and convert a C script i wrote when i have some more time this afternoon.

Posted: Thu Apr 08, 2004 4:21 am
by budgefeeney
Thanks! :D

use md5()

Posted: Thu Apr 08, 2004 6:35 am
by dipit
it is more promising

Description
string md5 ( string str [, bool raw_output])


Calculates the MD5 hash of str using the RSA Data Security, Inc. MD5 Message-Digest Algorithm, and returns that hash. The hash is a 32-character hexadecimal number. If the optional raw_output is set to TRUE, then the md5 digest is instead returned in raw binary format with a length of 16.

Note: The optional raw_output parameter was added in PHP 5.0.0 and defaults to FALSE

Posted: Thu Apr 08, 2004 7:17 am
by budgefeeney
That's not what I want. Here it is in full.

The MD5 hash of the passwords are stored on a file on the server.

When someone logs in, a salt value, based around time, IP address and some other values is embedded in the webpage. The user supplied password is hashed on the client side using JavaScript, and this is then combined with the salt value and the result is hashed. This hash (it's MD5 BTW) is then transmitted.

On the server, the salt value is recalculated, combined with the stored hashed password and hashed. The value is compared with that supplied, if they match, the user is logged in.

However people will need to change their passwords. This is the scheme: The user enters the old password and the new password. Again using JavaScript both the old and new passwords are hashed (MD5). Both are then encrypted using the hash of the old password as the key. These two encrypted values are then transmitted. On the server side, the software reads the hash of the password from the file, and attempts to use it to decrypt the old password value. If the decrypted value is equal to the old password hash, then the user got the old password right. The new password is then decrypted and stored, replacing the old one.

Now there's no shortage of JavaScript based encryption scripts out there (even Rijndael!), but I'm looking for PHP encryption utilities as I'm pretty sure the MCrypt extension isn't supported by our hosting company.

Posted: Thu Apr 08, 2004 8:04 am
by Roja
From your description of what you want to do, md5 will be more than sufficient, and des isnt needed.

http://pajhome.org.uk/crypt/md5/chaplogin.html

Thats a page with javascript md5, with php backends for it.

The tutorial I wrote for md5 is here: viewtopic.php?t=19761

Are you really sure?

Posted: Thu Apr 08, 2004 8:13 am
by budgefeeney
If I transmit the new password using just MD5, an eavedropper will know the MD5 hash of the new password.

Using this they
1) connect to the login page - this gives them the salt
2) They modify the source. The original source hashes the user entered password, combines it with the salt, and hashes the result

The modified source will combine the password hash they found via eavesdropping, combine it with the salt, and hash the result.
3) they load up this modified page and hit submit
4) they login

It is for this reason that when I'm saving a NEW password, it is NOT sufficient to hash it, as an attacker can login if they have the hashed password. Thus I NEED a symmetric cipher with both PHP and JavaScript implementations which do not rely on native code extensions.

If you look at the page you referred me to (http://pajhome.org.uk/crypt/md5/chaplogin.html), the author is aware of this problem too, thus his dream system makes mention of the following:
Change password with Rijndael using old password as key
This is exactly what I'm trying to do, but I'm not too bothered with heavy encryption, given that the "plaintext" is a hash. 3DES would be good enough.

Re: Are you really sure?

Posted: Thu Apr 08, 2004 10:16 am
by Roja
budgefeeney wrote:If I transmit the new password using just MD5, an eavedropper will know the MD5 hash of the new password.
And if you read my tutorial, I specifically say that thats what CHAP is for - you exchange a secret.

More detail below..
budgefeeney wrote: Using this they
1) connect to the login page - this gives them the salt
2) They modify the source. The original source hashes the user entered password, combines it with the salt, and hashes the result

The modified source will combine the password hash they found via eavesdropping, combine it with the salt, and hash the result.
3) they load up this modified page and hit submit
4) they login
And you've failed to do a chap sequence.

CHAP - Challenge, Handshake authentication protocol.

1) Connect to the login page
2) The login page sends a unique TIME-BASED code
3) The user, via the form, enters his password
4) The form, using javascript, hashes his password WITH the time-based code, which is unique, and already stored.
5) If it matches, then a session is created - he is securely logged in.
6) As part of creating that session, the time-based code is deleted from the server.

An attacker would have to sniff both transactions - getting the time-based code, and getting the password from the user before it is sent to the server. Then he would have to reply - BEFORE THE USER DOES - to get the session.

Once the session is securely established, changing the password is just a repeat of the above. You send him a secret - the time-based code, and he replies with the old password, and the new password, both hashed with that time-based code.
budgefeeney wrote: It is for this reason that when I'm saving a NEW password, it is NOT sufficient to hash it, as an attacker can login if they have the hashed password.
You chose a poor salt for your hash. If the salt is time-based, and short-lived, the attacker can't replay - which I mentioned in my tutorial.
budgefeeney wrote: If you look at the page you referred me to (http://pajhome.org.uk/crypt/md5/chaplogin.html), the author is aware of this problem too, thus his dream system makes mention of the following:
Change password with Rijndael using old password as key
This is exactly what I'm trying to do, but I'm not too bothered with heavy encryption, given that the "plaintext" is a hash. 3DES would be good enough.
He wants that as an ideal, to replace SSL. He ALSO notes that the CHAP system I described (using just md5, with time-based salts) is being used by Yahoo in areas where SSL isnt used.

Posted: Thu Apr 08, 2004 10:45 am
by budgefeeney
To quote my earlier message, to which you originally posted
When someone logs in, a salt value, based around time, IP address and some other values is embedded in the webpage. The user supplied password is hashed on the client side using JavaScript, and this is then combined with the salt value and the result is hashed. This hash (it's MD5 BTW) is then transmitted.
I don't care about the login, that's already got a CHAP mechanism, it's fine. The problem is when you change your password. When this happens you have to send a new password to the server from your webpage, and it has to be in a form whereby the server can subsequently use it to authenticate you.

If you simply hash the new password, then an attacker will know the new password's hash. They can then combine this with whatever salt the server sends out to generate a correct login ticket. This is why, when a logged in user is transmitting a new password to the server, I want to encrypt it's hash (which is what is STORED on the disk on the server) with a symmetric key.

I'm sorry to be so ratty, but this caught me by surprise, and it's been an annoyance, and the fact that a lot of people have missed the point and suggested hash based login mechanisms when I want a cipher based password update mechanism is doing my nut in! 8O

Posted: Thu Apr 08, 2004 12:59 pm
by Roja
budgefeeney wrote: I'm sorry to be so ratty, but this caught me by surprise, and it's been an annoyance, and the fact that a lot of people have missed the point and suggested hash based login mechanisms when I want a cipher based password update mechanism is doing my nut in! 8O
Not at all - I did miss that from the description you gave.

Solid point, totally correct.

Just makes me wonder if it really is an area BETWEEN CHAP login and SSL..

Seems like if the need pushes it towards a symettric cipher, you should go straight to SSL.