Hi,
Why does Scriptcase only permit the use of MD5 cryptographic hash function when it has been known for years that it has is been severely compromised and all authorities warn AGAINST its use.
My applications require the use of either SHA-256 or SHA-512 with salting. Why doesn’t ScriptCase accommodate these secure functions. How do I incorporate these functions into my ScriptCase applications?
Regards, John
The only spot I know of is the security module which uses MD5. MD5 is a standard php function. But it’s fairly simple to go to the ide-created logon module and change the MD5 to what you want.
you can always modify the forms created by the security module to use the sha encryption you need.
for example in the sec_form_add_users form that scripcase creates automatically you can change the md5() function to whatever you want.
I would recommend to use php default functions.
Regards.
[QUOTE=JohnMMM;32700]Hi,
Why does Scriptcase only permit the use of MD5 cryptographic hash function when it has been known for years that it has is been severely compromised and all authorities warn AGAINST its use.
My applications require the use of either SHA-256 or SHA-512 with salting. Why doesn’t ScriptCase accommodate these secure functions. How do I incorporate these functions into my ScriptCase applications?
Regards, John[/QUOTE]
NetMake is severely behind the times, I do not think they have anyone on staff with any knowledge of this century’s crypto requirements.
This can be verified by simply looking at the encryption used when you pay for ScriptCase: test NetMake Server
I wrote the security module for use in our Payroll System using SHA256 with salt, and we will probably move to SHA512 soon.
Dave
Dave! add us a huge favor all, a tutorial how to do that in current scriptcase security module
I’m sure scriptcase guys will not care or even add it to their module, moreover, you for sure deserver $$ for it which they will not doe
but I’m sure many people here will appreciate and pray for your efforts dear 
Mike,
I will make it available to all on my web server in the next day or two.
Dave
thanks Dave that would be great
Dave,
Make that double thanks. Could you post a link where this tutorial may be available?
Regards, John:)
A good start is to look into the available php functions like
http://php.net/manual/en/function.hash-init.php
As in Scriptcase the standard MD5 function is used, it’s not that hard to replace that by another function.
Yes, in the most simple terms, that is true. In addition though (to do it properly), you need methods to create and store good random salt values, unique for each password. I also did quite a bit of work to support rock solid userid creation with email delivery of activation codes, and lots of work to support a reliable password reset mechanism. Of course while I was at it I fixed all the broken session handling as well.
The delay in me making it available is that I have to create a new project, import the security related apps from my project, clean them up and insert copyright notices, etc.
A bit of background, so that you can understand the system where my security code currently resides. My application is a Cloud Based Human Resources and Payroll System. Customers subscribe and become an “account”. An account has one or more “companies” and some number of “users” - account administrators, company administrators, payroll clerks, managers, and employees. Each “company” has a unique database of identical structure. The “users” that belong to an “account” can access one or more “companies” depending on their role. The Account Administrators can add users to their account. Company Administrators can enable log in for any “employee” of that company. Accounts have maximum number of companies, users and employees, based on the plan that they subscribe to.
I will probably pull out most of the account/database related stuff, but if anyone in particular needs to do anything like this, I can make some of it available to them.
I will let you know when I have it ready.
Dave
That is indeed marvelous job Dave, I’m sure you’ve worked hard to reach to this extend. At your own freedom to share the code, as I said earlier, maybe SC guys will not care, but for sure we will appreciate.
Albert, you are right about the function, many other stuff can be added as well, we are targeting a lot of people in Dave’s addition, specially for those are not familiar with these terms and for those who can’t “easily” apply the same in SC, not everybody has same experience after all.
Regards
No Mike, you’re right. But it depends on your need so the function I showed is usable as a replacement for the current MD5 call.
However, if you need more advanced security then Dave’s solution comes in hand. But to have a random unique salt for each password would need to store the salt somewhere in the database? Then it wouldn’t make sence, but it makes me curious to his solution.
Regarding the rest, the generated security module of scriptcase is indeed limited and like Dave I have my own solution(s) depending on my security needs, multi group assignment for one thing.
If people are not so familiar with php and need to stick to the module of SC itself then replacing the MD5 by a better function would be the way to go.
Albert,
[QUOTE=aducom;32807]No Mike, you’re right. But it depends on your need so the function I showed is usable as a replacement for the current MD5 call.
However, if you need more advanced security then Dave’s solution comes in hand. But to have a random unique salt for each password would need to store the salt somewhere in the database? Then it wouldn’t make sence, but it makes me curious to his solution.
[/QUOTE]
We are talking about two very different things here.
Hacking into a password protected website is what we are trying to prevent. Protecting the Database Server is a different topic entirely.
Salting prevents the use of rainbow tables to create hash collisions. A hash collision is caused when a password (the original or some other password) generates the same hash. Since the hashing algorithm is one direction only, hackers use tables of every possible hash code, and a password that will generate that hash code. These tables are readily available for MD-5. Take a look here
Re-using a salt is very bad practice, salts should change every time a password changes, so that even if two loginIDs are using the same password on the system, their hash codes are different.
Storing the unique salt in the user table is widely accepted practice in the cryptographic community. Think of it this way - if you have 4096 bits of hash and 2048 bits of salt both store in the same record, then it is essentially the same as storing 6144 bits of hash (except of course for the math).
If somebody has hacked into your database server (totally different problem than hacking into the website), then they already have gained access to all your precious data. They do not need to bother to hack into the website itself. Still, however, even if they get the salt and hash, they cannot readily create a matching password, whereas a compromised MD-5 hash with no salt can be used to create a working password easily.
Dave
Dave, tnx for your explanation. You absolutely have a good point there, never thought of that.
hi guys, I was looking into this and did a small test like took the hash of my admin user in mysql test project and put it on some online website and grrrr gave me the password in free-text like dycpting it easily
any finally tutorial that shows us how to use sh1 or any other useful hashing/protecting users password with better than md5 that tutorial will help everybody after all
Hi there Mike:
Quite simple actually, enable the security module in SC, it’ll create several applications:
in my case I remade the sec_users form so in the onbeforeinsert and onbeforeupdate events I added the following code
{pswd}= hash('SHA512', {password} );
The {pswd} is a hidden field which holds the password to be encripted, while de {password} field is the one the user uses to enter the new password.
The hash function is quite straight forward as you can c.
In your sec_login application you only have to modify the onvalidate event.
$slogin = sc_sql_injection({login});
$spswd = hash('SHA512', {pswd});
$sql = "SELECT
priv_admin,
active,
name,
email
FROM sec_users
WHERE login = $slogin
AND pswd = '" . $spswd . "'";
sc_lookup(rs, $sql);
as you can see all I’m doing is to get the pswd field of the sec_login screen and use the same algorith I used for when they create the password and then I look for the username and “encripted password” into the database if no user meets the criteria… then the user is invalid.
Hope this helps.
If you have any question please do not hesitate.
Regards
Oh kafe, thanks a lot dude, i was really shocked when took the md5 hash and put it on some website and told me “password found” then showed it to me!!
what i want to understand, if php is decrypting it anyway in process of the applications, then anybody can decrypt it the same way and see it as free-text! so this is applicable even if used the sha512 as well! problem is maybe i don’t understand how this mechanism works grrrrrrrrrr
now, i’ve done what you said above as quick test earlier, changed in edit_users and also in login application, i saw that password is being storred encrypted to database different hash than using md5 (same password) but the login application didn’t authinicate, didn’t open the project login screen… so i didn’t think it will be such easy!
just to clear things out, lets take it less than easy… when storing the password field to database it should go with encryption method, nomatter if md5 or sha512… now we have the hash in the database, then we need to inform the login application to use the same algorithm to decrypt it in order to authenticate correctly, right!?
in this case, if that it true, then we can’t apply this to ongoing project, all passwords should be using sha512 because login app will use sha512 to decrpyt it all the time, so if it was md5 hash the one stored, it will not work!
moreover, do you think in this case the field of the password should e increase from varchar 32 to something else? if yes, what varchar should be 512? more? is this why my problem happened? something like when decrypting it doesn’t store the full hash (only 32 chars) then login app isn’t able to decrypt? because varchar32 is being used by sc security when created (assuming md5) what you think?
one last thing, in this case we have to apply all these stuff to each project we create? is there a way to save the applications modified and use them with next projects? i am really finding it stupid to go through all the changes we do for each project, including the minor changes to security appls and headers/footers templates, themes usage… how we can do something to be used later in other projects!?
well, those are very important points, if you think we need a session will be great and better actually, only problem is the timing dude
let me know what you think please
HI there Mike:
Well firstly, you need to understand what a HASH is… when you hash something you scramble the data to a fixed size… that means is not reversible(reason why it is used for non reversible password). in this case sha512 is 512 bits long around 64 chars. if you are wondering how a website can decript something that is supposed to be irreversible… the answer is simple, commonly they would use 2 ways:
1.- a md5 database
2.- they use an algorithm to generate md5’s until it matches yours.
If you verify in the code I sent you… I’m not decripting anything… I’m comparing the hashed value of the password against the database.
Now Secondly you are right… you can’t use this in an ongoing project without resetting the passwords, for that you can use several approaches (from… hey guys guess what “you all need to change your password” to… hey guys… "I took the liverty of reseting your password). this is for the inherent use of a “HASHing”.
Thirdly again you are right… you need to apply everything to your new proyects… tho… remember you can import and export the applications… meaning is not needed to recreate everything maybe just tuning it.
Regarding the meeting… we simply need to work it out man.
Regards
oh man, that is wow, just closed a lot of open loops for me 
highly appreciated
will be in touch dude
thanks again
kafecadm,
I really appreciate you figuring this out. However, I'm having issues after following your instructions. I created a new user with the first php code and then replaced the event on login with the second set of code. I increased the DB field to 64 to contain the 512 hash. When I attempt to log in with the new user under SHA512, I get a 1054: Unknown column 'c2c6161a45329e01d419c10374bd89604f5ab95466f1d6cab716927d61fdd968817285e3b95074de6257b145c5d8604c20d4f5aec52258b5a5a8ebbb6cd3df3b' in 'where clause'. I search online for help and can only find a Stack Overflow thread mentioning the treatment of strings with a ' mark. I attempted to change the code with different combinations of ' " but with no success. From other replies on this thread, it seems like your solution works. What am I doing wrong?
$slogin = sc_sql_injection({login});
$spswd = hash('sha512',{pswd});
$sql = "SELECT
s.priv_admin,
s.active,
s.name,
s.email,
s.emp_id,
s.comp_id,
e.c_member,
s.group_id
FROM sdh_sec_users s
join emp_comp_access e on e.login = s.login and s.comp_id = e.c_member
WHERE e.login = ".$slogin."
AND s.pswd = ".$spswd."";
sc_lookup(rs, $sql);