Problem with MD5

Applications Control
#1

Not sure if this might be a bug but I have problem with storing passwords. Here is what happens.

  1. Created standart security procedure (using Login App). When creating I selected MD5 for password encryption. When the Apps were generated the first ADMIN account was created and 1-st record created properly.
  2. When I login to the project and select ADD NEW USER (which calls standard SC-NewUser App) the user is saved but the MD5 is not working.
  3. When I open the table (inPHPMyAdmin) I see the password is not encrypted (so of course Login with those credentials will never work).
if({pswd} != {confirm_pswd})
{
	sc_error_message({lang_error_pswd});
	sc_error_exit();
}
{pswd} = md5({pswd});

My table has some extra columns added, but all columns were added after the original ones (SC generated) so when calling for recordset array there should be no problems.
Any ideas what I might be doing wrong ?

BTW. When I remove MD5 hashing everything works fine.

Arthur

#2

you’ve answered where you start to look :slight_smile:

My table has some extra columns added, but all columns were added after the original ones (SC generated)

because never faced this, and the encryption is done okay, you can find the hashing inside the application itself, I already updated it for some reason earlier and it worked ok, including choosing the hashing and the password length, characters to be used…etc.

#3

MikeDE - thanks for replying but I do not understand your statement. When I look in the code the last line in the first post here uses a method to apply MD5 to the {pswd field} so it is salted.
The rest is obvious, just saving the record. It seems that this line is causing a problem no converting it to hashes, but I have no idea why. The fact that I added few extra fields to the Users table seems to be completely irrelevant (or am I wrong) ?

Arthur

#4

Hello aka:

Take a look to your new user form, in the beforeinsert event, there should be a instruction like:

{pwd} = md5( {pwd} );

if not then you should review the code, secondly i would recommend to enable the debugging in SC enabling the script error aswell,so you can make sure if there’s no error.

lastly, verify the source code of the applications, and check if you have a “error_log” file, if so, check the content of the file it might tell you whats going on.

Regards

#5

kafecadm - thanks for your suggestions!

Yes I see this line in the code (when creating new user) and that is why I’m posting this message. The line is there but MD5 is not working !
Will try your debugging suggestion to see what’s wrong (although my totally surprised because this is standard generated App (no extra code or anything except few extra columns in a table which should not affect MD5 php function at all).

Art

#6

Resolved

I restored library folder from backup and now it all works fine. Thank you all for your suggestions.
Arthur

#7

OK, The account creation form works fine, so when I add new user the MD5 works OK. I just created another form and included password field on the form.
I added a line in Events (onBeforeInsert)

{pswd} = md5({pswd});

but the password is saved in unencrypted form. Any ideas ?

Arthur

#8

[QUOTE=aka;33756]OK, The account creation form works fine, so when I add new user the MD5 works OK. I just created another form and included password field on the form.
I added a line in Events (onBeforeInsert)

{pswd} = md5({pswd});

but the password is saved in unencrypted form. Any ideas ?

Arthur[/QUOTE]

It should work ok as a first reaction so it’s odd that it doesn’t. You could try to echo the data to see what’s going on. In general I would do this in the onvalidate as the MD5 should also fire on update.

#9

This bug I found a long time ago.

In the onBeforeInsert, everything will work fine, because the {pswd} contains the UNENCRYPED password, since it is a NEW record.

When editing an existing record, the md5() should be done if the password was modified.

Just throwing an md5() into the onValidate is not the answer. It needs to happen ONLY when the password field has been modified. Otherwise it will md5() the already encrypted password, for instance if your only edit is changing groups, etc.

Dave

#10

[QUOTE=daveprue;33794]This bug I found a long time ago.

In the onBeforeInsert, everything will work fine, because the {pswd} contains the UNENCRYPED password, since it is a NEW record.

When editing an existing record, the md5() should be done if the password was modified.

Just throwing an md5() into the onValidate is not the answer. It needs to happen ONLY when the password field has been modified. Otherwise it will md5() the already encrypted password, for instance if your only edit is changing groups, etc.

Dave[/QUOTE]

hi Dave
did you find solution for that?

#11

Mike,

Yes, I did but I cannot remember exactly what it was. I no longer use the ScriptCase Security Module, and I do not have the old code readily available to see what I did.

I will take a look at the current Scriptcase Security Module and see if I can remember where that bug was.

Dave

#12

Thanks in advanced dude, its daily used by others, many can’t develop something independent like you do so we depend on security module so please let us know if any solution you could manage or remember how it was :slight_smile:

#13

Yes it would be great if you could post more details, so perhaps this can be also reported to NetMake so they can fix it in a next release. I think this is really crucial !

#14

Hi,
tryed some test and here are my observations:
-1- Trying to put the app_form_add_users in debug mode : doesn’t work
-2- trying to put some message in the events (onBeforeInsert for example) : they are never launch it seems that these events are never launch.
-3- Trying to define my own ajax events: doesn’t work…

Only thing I have done on the standart security module and application: add a new column at the end of the sec_user table…

Ouh la la … What a nightmare…

#15

YES, this same thing happens to me. Once the original table is modified everything gets screwed up.
I tried to add some code into Events and it seems like it is never executed !

Any modifications also cause SC to crash (see the image)

[NOW - WHAT NETMAKE WILL DO DO ABOUT IT ?

SEC_Bugs.jpg

#16

aka,

crying so loud will not save the problem !!

BTW i never had this problem and i added fields in my user table after the first creation as my customer wants more fields.

What i did to prevent the md5 problem was, that in the edit mode, the user password could not be changed, i made a new form only for password updates.

Gerd

#17

Hi Gerd
that don’t solve the problem when creating new users.
And why all events doesn’t seems to work ?
And for aka, may be he’s shouting so loud because SC doesn’t seems to hear problems (bugs) we are facing. Or, if they hear us, they don’t answer… Read about the frustation of many customers here…

#18

i know, that it doesn’t solve the problem.
My greater problem right now is: i can not reproduce this error. i can define and delete fields in my DB, the form works. Also every event i define is working !

btw. aka should meenwhile know that SC is usually deaf on both ears !

#19

hi guys
just to add small comment, i got that error which is in aka’s screenshot above in the shouting post, in many occasions, one of them was when playing with db fields and returning back to application and tried to run it… i think it is kind of “fake” error, because once you refresh or move on it will all work ok

possible scenario is maybe having momentary crush while you change something in the values due to SC internal validations or something… then once you save it, it “resets” the application functions and it works ok

btw. aka should meenwhile know that SC is usually deaf on both ears !

agree

#20

[QUOTE=MikeDE;34561]hi guys
just to add small comment, i got that error which is in aka’s screenshot above in the shouting post, in many occasions, one of them was when playing with db fields and returning back to application and tried to run it… i think it is kind of “fake” error, because once you refresh or move on it will all work ok

possible scenario is maybe having momentary crush while you change something in the values due to SC internal validations or something… then once you save it, it “resets” the application functions and it works ok

agree[/QUOTE]

well it works for me only if I close and reopen SC, otherwise I get all kind of other junk and errors in other procedures as well. I do not know what it is but it is very annoying!

ooohhhh! DID I ALREADY SAY - I WANT THE BUGS FIXED ?