Crypto!

[mogster]

This is a routine I've made for masking passwords before sending to the server. Basically what it does is to use Javascript for calculation/encryption pre-submit, empty all cleartext values, then re-create the same conditions on the server using php. Listed under is what happens before the form is posted.

Anyone who could give me some feedback on the logic of this?

Opaque routine start:

Submit username: mobben
Submit userpass (to masking): e4da3b7fbbce2345d7772b0674a318d5
Submit adminpass (for key - md5'ed twice): 948fb688aa6d8b1a914f03d8508186fe
Submit mseed (for key): 17b3d1901fa886a54c5b23598895aebb

Submit key: MD5(adminpass+mseed): 2808cc717d0d2efb4ee1d851fae20c46
Submit key, chop: 2808CC
Submit key, to decimal: 2623

Original big hash: (256chrs)
5e7f231fad00c7c2d84872e42f4436aba8720fd20e6d53cd61dc6d40f95ef414f2b3c0ca100568c93b2daac4c543f31c7d9107a1d0c03fbff09c3167a3ec1e77eff9cae9f2d2c0b1b6e8d40260618a2e4c26d0c2fbff89ef00ab647ea6a7e09495ea9432efa2195e4a3459deed437bfa3a928e409140de8d058b187b9a2cccaf

Tampered hash with password: (256chrs)
5e7f231fad00c7c2d84872e42f4436aba8720fd20e4da3b7fdc6d40f95ef414f2b3c0ca1bbce23452daac4c543f31c7d910d7772b06bff09c3167a3ec1e77ef74a318d52c0b1b6e8d40260618a2e4c26d0c2fbff89ef00ab647ea6a7e09495ea9432efa2195e4a3459deed437bfa3a928e409140de8d058b187b9a2cccaf

Binary 3DES-encryption:
( not printed here )

The submit hash (Hex-version of the 3DES-binary - 514chrs):

0x80585cfd46383aec537109ae9399b7df6e7e1d33f3e716413086b63949aa9a2c6a87dee1adb94fd0e78d1ce01c46009ef8f57c5d243ceae041400387e2dd5230236797623b339f0698db47bd6f1684ce997774658879f7bd5b3961fa1e939e65c64ac69098e4539f72c64b670c36071798e07f8b1fe07d74afffb2be68f8829ff99a98e45611b37d2ac0bca270a6bc4ddecc27c82da803a02a128d2266bc9435a6e02822e9ca1dfcafb8e6b9587623e91f2c19b85e55efb5eba980e90fffc081986d0788c814aa799ce362923f34e3c0def8ee8667af7fb53039b84b1f6457ace3478ad3666226065fb73592d42afa2ab9f1021fc153b1279e558b1327f2f1bb

Opaque routine end

The first 24chrs of the double md5-value of admin pass/seed is used for creating the 3DES-keys. Once the data reaches the server, the admin pass is fetched, and used to reverse the routines and reproduce the user's password (by php).
Note:
Only the username for the new user and the opaque hash are submitted in the real form, the rest of the values are removed before submit!. The admin pass used for key is the password for the current inlogged administrator.

Here's some examples on the pre_3DES tampering:
Example hash with decimal-occurrence 9999:
5d0741b8f631fa6b3586aee4d851d4358d44cd36776825f34b5b84b066ea0027b36be6dad57861 e1671797ce4eeafacb026f671ebcf70bf0e04a03b703 c52e15f7a727904016b34eaea72985111604b8495cee 63380b451cfccd29784ca445e51d7558cd14f9d742d9 e841ec327f0ae43b802b232485bdf834dd4bf24e2f

Example hash with decimal-occurrence 0000:

3cce3e0e272060c e1671797 4efef5347 c52e15f7 32ae51d4f 63380b45 1101edd6e e841ec32 2d0e1add542cf00c86394111e983ca5da4269d31643d755ca3d9a390f6c9b6cd5f3c69739da21c93982cf05ab4f50eaf2de0f77edc0322b63e9c80842bfd22d64251beb5aeaa39a9a5e96c7f51f2561d63704c178faa855022

knutm 😃

[mogster]

Erm.. here's some more on how the stuff works:

Private registration:
The registration starts when loading the registration form in Publicator. A long and unique hash is generated (8x32chrs) using javascript, with the function genString(). The 256chr string AND the hidden field which is it's container (bigstr_b, are then printed into the form by javascript.
The auth-part of the registrationform contains 4 textfields for typing, 6 hidden fields filled with values and one empty hidden field for the opaque hash:

Text fields:
- Username
- Admin password
- User password
- User password again

Hidden fields:
- $magent (md5'd user agent)
- $mdip (md5'd ip)
- $mseed (seed)
- $kembo_check (the value from the admins cookie - his auth hash)
- bigstr_b (the javascript-generated 256chr hash for tampering)
- tampered (the vessel for the submit hash once it's made opaque)

Of these, only the two last of the hidden fields is used in the actual password-encryption, while the rest is provided for one sole purpose:
To check if the admin is typing his own password correctly ;-)

Beacause this is the one crucial point - the admin password is NOT submitted. The only values to leave the client are the username of the new user and the opaque hash. When arriving on the server, the serverside script fetches the administrators password from his user-file to use it as the key for finding the users password in the opaque hash.

This is what occurs when admin submits the form:

The value bigstr_b is loaded into the doRegPub()-function in the registration Javascript to provide the hash in which to put the password
A javascript-function reproduces the value of the administrators auth hash from the hidden fields in the form
the form validates if the type-in fields are filled in correctly for the auth (with javascript):
-has the admin typed a name for the new user?
-is the user passwords filled in, and if so, are they equal?
-is the admin password correct? (Checked by comparing the calculated value with the $kembo_check)

The calculation for the replace-operation in the bigstr_b-hash starts by md5(users password), then chop it into four 8chrs pieces. then the double md5-value of the admin password is chopped - we use only the 6 first chrs
The 6 chrs is converted to decimal values (returns 4 digits)

The users password-pieces are replaced into the long hash at the points specified by the decimals defined (adm#x) as itself and in two other values as spacers/start-char:
spacer = amd#1 + adm#2
startChar = ((amd#1 + adm#2) *2)

The password is then replaced into the big hash about as this:
startChar + spacer + adm#1 + (passpiece1) + spacer + adm#2 + (passpiece2) + spacer + adm#3 + (passpiece3) + spacer + adm#4 + (passpiece4)

The tampered hash is then 3DES-encrypted using the 24 first chars of the double md5'ed adminpass
the 3DES-bin is printed to hex, and submitted along with the new users username (all other values are cleared before submit!)

Gooey?

knutm

[ednark]

your posts are a little thick.. and i didn't read them all carefuly.. but basically you have just reimplemented public-private-key encryption using javascript... which is in itself a fairly good idea....

so the killing point of this is what info is being passed to and from the browser... i think you are passing the admin key along into the html of the form

hidden fields are not hidden

if you have php write to the html file anywhere the admin key, then it will sit cached on the system and will not be a terribly safe place

(this is actually the main argument against cookie based sessions as cookie sharing leads to session hijacking)

if you use the same encryption key for every transaction then its not safe... a look at the cache could spill the beans of that users admin key... if you use a different key to encrypt each transaction then its safe as long as the key changing algorithm is not easy to guess...

i image something like this would be simpler for form security

• user enters a form page and is given a random unique FORM_KEY
  specific to that form, this is stored in user specific place (session)
  $_SESSION['form:keys'][$form_name]

• the form key is submitted into the form as a hidden variable
  <input type="hidden" name="__key" value="$_SESSION['form:keys'][$form_name]">

• when any form is submitted, the key must match the session key, if not it is rejected

if ( $POST['__key'] !== $SESSION['form:keys'][$form_name] ) {

REJECT

}

• if the submission worked, then a new key is generated for that user and that form
  if ( $success ) {
  $_SESSION['form:keys'][$form_name] = genFormKey($form_name);
  }

now javascript can be left out of the picture which is always a good idea.

[mogster]

Hi!

Thanks for reply.

Ah, the form is very carefully planned, and all fields - including the admin pass - is cleared before submit. Actually, the admin-pass is not a hidden field: it is a text field where the inlogged admin types in his pass as one of the values in the key-production.

The other value used is a unique seed, which is md5'ed together with the admin-pass to provide a meaningless (but reproducable) hash for the key.

The key 😉 issue is that the unlocking key is not sent with the form - it's used for encryption locally in the browser, then discarded before submit.

All the potential hacker would have to work with is the user name for the new user and the long 514 chr hex. In addition he'll probably know the admin's cookie data, which is admin user name, admin auth hash (unique, meaningless) and the admins seed value. Both auth hash and seed is unique from session to session, and has a limited lifespan (can't exist without replica in db).

As for Javascript, it's a means to mainpulate formdata pre-submit, and makes it possible to obtain a level of password-protection over open protocol (http).

knutm

[ednark]

ok so you are requiring a password entry in the form

upon submission javascript will create a hash with the pwd

then empty the password box before actulally submitting the form

so the password will never be transmitted http and you will have a unique hash that will be transmitted

which will be matched up with the same password on the server

ok so the password never gets transmitted... thats reasonable

gotcha... that makes more sense and seems reasonable...

only thing to note is that your active browser range is rather limited as you would need to require only javascript complient browsers that have js turned on...

beyond that the scheme looks fine... i can't find any flaws with your logic

just your explaination seemed very complicated 🙂 or maybe im just slow

[mogster]

Well, I explained it a bit clumsy, and it's probably easier to grasp once you have the whole process in front of you.

And true, there is the backdraw that the browser needs to be both cookie and js enabled.
It's the old battle between pain and gain, I guess 😃
But it's refreshing to use Javascript for something useful for a change, and I see it as a possibility for js to redeem itself, hir-hir.

The full package also includes a login based on app. the same principle, and is a result of a hastily posted comment @ php.net.
I posted a short js/php-snippet on how to md5 passwords pre-submit, then got a lot of complaints on mail about how risky it is to send even a md5 of your password over the net. So I wrote an upgrade, and then another...
You know the drill 😉

Here's the php retrieval of the password once it reaches the server:

## Find admin password ##
$ustream = file_get_contents("$pub_dir/$user_authdir/$administrator.txt");
$passPass = find_ufield($ustream, "|s|", "|/s|");
$ustream = "";
## md5 it once more ##
$passPass = md5($passPass);
$passTokey = $passPass . $seed;
$passPass = md5($passTokey);
## Decode the submit hash back to binary ##
$tampered = hexToString($tampered);
## Decode the DES-hash to md5 value ##
$decoded = TripleDES($passPass,$tampered,0,0,$iv);
$tampered = $decoded;
## Calculate decimal values from admin pass ##
$hexie = substr($passPass, 0, 6);
$wizard = hexdec($hexie);
$heks = chunk_split($wizard, 1, ',');
$hexsplit = explode(",", $heks);
## Do the start/spacer calculation ##
$startChar = (($hexsplit[0] + $hexsplit[1]) *  2);
$spacer = $hexsplit[0] + $hexsplit[1] + 15;
$start1 = $startChar + $hexsplit[0] + $spacer;
## Find the password bits ##
$passchunk1 = substr($tampered, $start1, 8);
$start2 = ($start1 + 9 + $spacer + $hexsplit[1]);
$passchunk2 = substr($tampered, $start2, 8);
$start3 = ($start2 + 9 + $spacer + $hexsplit[2]);
$passchunk3 = substr($tampered, $start3, 8);
$start4 = ($start3 + 9 + $spacer + $hexsplit[3]);
$passchunk4 = substr($tampered, $start4, 8);
## Glue the user password together ##
$da_word = $passchunk1 . $passchunk2 . $passchunk3 . $passchunk4;
$rtime = time();
## Create file-string ##
$string_to_file = "## Publicator auth file - do not edit! ##\n|u|$username|/u|\n|s|$da_word|/s|\n|r|Publicator|/r|\n|t|$rtime|/t|\n|a|$firstname $lastname|/a|\n|b|$email|/b|\n|c|$postadress^$zip^$city|/c|\n|d|$company|/d|\n|e|$phone^$mobile|/e|\n## Publicator auth file - do not edit! ##";
if (!file_exists("$pub_dir/$user_authdir/$username.txt")) { 
touch("$pub_dir/$user_authdir/$username.txt"); // Create blank file 
 chmod("$pub_dir/$user_authdir/$username.txt",0777); 
}
$a = fopen("$pub_dir/$user_authdir/$username.txt", "w");
fputs($a, $string_to_file);
fclose($a);
jump("publicator.php");

knutm

[mogster]

Erm.. this is the file-version, the db-version still only exists in Norwegian, I'm afraid.

knutm 😃