ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Payroll >> data encryption
http://www.istechforum.com/YaBB.pl?num=1233156363

Message started by deburr on 01/28/09 at 08:26:03

Title: data encryption
Post by deburr on 01/28/09 at 08:26:03

I have been able to work around the obstacles created by encryption of Social Security numbers and birth dates for this years reports but this is a very bad idea. I need to have that information available for upload to in reports to my 401k provider and TPA, Connecticut Department of Revenue Services, and many other insurance, government agencies etc...

Many of these agencies do not accept paper anymore and in the past I was able to satisfy any uploads they needed, by using Crystal Reports and exporting to a cvs file. The data you wish to protect is widely available by crooks through other means and does little to protect my business or employees.

IS Tech has done great things with this software to make my life better and business more profitable, but this is a big step backwards. If data encryption is the way of the future, you must make the data available to us for reports that EVO-ERP does not provide for.

Advance notice of major changes like this one, should be be given to users, so they can opt out of an upgrade that will cripple function of their system. This added a lot of hours to our year end payroll tax reporting this year.

Please provide some means to decrypt our data, or roll back that "feature". The work around I used for this year, is not a good long term solution.

Title: Re: data encryption
Post by kkmfg on 01/28/09 at 09:52:31

deburr wrote:

The data you wish to protect is widely available by crooks through other means and does little to protect my business or employees.

So is cocaine (available through crooks and other means). It's still a bad idea to not encrypt at least the SS#.

Quote:

IS Tech has done great things with this software to make my life better and business more profitable, but this is a big step backwards. If data encryption is the way of the future, you must make the data available to us for reports that EVO-ERP does not provide for.

Yes, there should be a way to get at the data. Like, say, if they used AES256 and you could obtain the key. Heaven help us all if the same key is used on every machine. I hope it's randomly generated and not either the same or generated from machine related info like the computer name and MAC address...

Quote:

Advance notice of major changes like this one, should be be given to users, so they can opt out of an upgrade that will cripple function of their system. This added a lot of hours to our year end payroll tax reporting this year.

Yes, it's good to advertise big changes ahead of time. I think that they did though. I was aware of this issue before I upgraded.

Title: Re: data encryption
Post by deburr on 01/28/09 at 10:35:41

kkmfg wrote:

[quote author=deburr link=1233156363/0#0 date=1233159963]The data you wish to protect is widely available by crooks through other means and does little to protect my business or employees.

So is cocaine (available through crooks and other means). It's still a bad idea to not encrypt at least the SS#.

I don't know what dope dealers have to do with this subject but I'm assuming the reason for encryption is to protect us from our employees that have access to the data, and not dopes on the streets. I'm a bit more concerned with the other payroll information like salaries being shared between employees than my employees stealing each others identities.
,

Quote:

Yes, it's good to advertise big changes ahead of time. I think that they did though. I was aware of this issue before I upgraded.
[/quote]

Maybe you read my (warning) post in late December before you upgraded. I saw in the update notice that future payroll enhancement would "including encryption of sensitive payroll information" but I didn't understand that I would be protected from myself. What was I thinking?

Title: Re: data encryption
Post by kkmfg on 01/28/09 at 12:48:37

deburr wrote:

Maybe you read my (warning) post in late December before you upgraded. I saw in the update notice that future payroll enhancement would "including encryption of sensitive payroll information" but I didn't understand that I would be protected from myself. What was I thinking?

Yeah, it's possible that you actually were the person to tip me off about that. So maybe ISTech wasn't quite clear enough about how the encryption would work.

Personally I would assume, after having been told that the payroll info would be encrypted, that it would become very difficult to extract that info outside of Evo. An encrypted field is always encrypted. As I've said before, the only way for you to get at it is to know the algorithm and the key. Since they've been very mum about how, exactly, they encrypted these things I'm assuming that either A. they used a crap encryption algo (sorry but encryption is an interest of mine and a lot of encryption schemes aren't too good) or B. they used the same key for everyone. In the case of B then telling you the key blows the security out of the water. Then anybody could use that same key to decrypt other people's data. In the case of A then admitting to what they did could also lead to a security breakdown. It's what the security biz knows as "security through obscurity". This is only good until it's no longer obscure.

Title: Re: data encryption
Post by Lynn_Pantic on 01/29/09 at 13:04:25

I am going to have the programmer convert the PR-I report into an Evo RTM and add the decrypted fields for SSN and Birth Date. We will also modify the report layout so the SS and Medicare withholdings are separate columns making it easier to load into Excel. Since that report has both the employee master and pay detail files open and already has subtotals and grand totals, it seems like the obvious candidate as the RTM can then be modified to meet individual reporting needs.

This will enable management/employees with access to the payroll module to get at the encrypted data in a decrypted form either on paper or electronically without having the unencrypted data in a table used by everybody for Job Costing.

One of the reasons for creating the new separate ISPRMSTR file for payroll separate from the BKPRMSTR file which used to be the only employee file but now is used for Job Cost Labor only is that since ISPRMSTR file holds the sensitive information such as pay rates as well as SSN and such, it can (through Windows permissions) made hidden to users that are not loading the payroll module because none of the Job Cost programs or SM-G open the new payroll file. Some people are more protective of their payroll data than others in terms of employees finding out what other employees make but this is a way to keep it somewhat protected.

Title: Re: data encryption
Post by kkmfg on 01/29/09 at 13:07:12

That sounds like a pretty decent compromise.

Title: Re: data encryption
Post by deburr on 01/30/09 at 10:31:44

Lynn

This sounds great. I see the deduction field in that report is a summary. I don't have much experience with trying to add fields to RTMs, hence this question. Will I be able to add individual deduction fields to the modified RTM to separate insurance, garnishments, 401k etc...?

Title: Re: data encryption
Post by Lynn_Pantic on 01/30/09 at 15:20:33

Yes, if the field exists in the employee file (ISPRMSTR) or pay history detail (BKPRHIST), you will be able to add it to the report.

We also have a text report that will run in Classic and has an option to export information for a 401K Census report that now has the decrypted information. Since it is not an RTM, you can't change the format of the report itself but you can export the results to Excel and manipulate it there.

I just sent the updated programs to you and Collin. Anybody else interested, email me and I can provide them.

Title: Re: data encryption
Post by deburr on 01/31/09 at 06:32:46

Lynn

Just tried it. works great! I was going to suggest filters for terminated and zero pay amounts in PR-I, but you beat me to it in the T7 program.

Thanks for your work in this matter. I really appreciate it.

Steve

Title: Re: data encryption
Post by deburr on 02/04/09 at 14:41:45

Pardon my ignorance, but how do we add totals when modifying an RTM? I'm a Crystal Reports 5.0 guy that hasn't really kept up with the RTM thing. I was able to add an array field (user deductions) to my payroll report, but I can't figure out how to summarize data.

Thanks in advance for any help.

Steve

Title: Re: data encryption
Post by deburr on 02/05/09 at 13:55:08

Lynn

I was able to add bkpr.curp.uod[4] to my report. Using same technique I can not add bkpr.emp.lmne or fnme. I need the name in two separate fields but the original RTM has it combined somehow. Is that done in the RTM or is that coded in the T7 program? I can't figure this out and figure out were to find the info that would explain this. Is there a manual that can be bought to learn this stuff?