encrpyt salary data

[ljb]

Anyone have a good idea for encrypting salary data in US $? I have an Access
database with some salary info connected to ASP on our intranet. My manager
is somewhat apprehensive about the level of security currently provided. I'm
using basic authentication (I think that's what it is called). It relies on
NT directory permissions and code to query "AUTH_USER". Does anyone have a
simple encryption idea that can take US$, 5 digit employee ID, encrypt it
and store it in Access' Currency data type? The database will store the
salary encrypted. When an authorized user hits the ASP it will display
decrypted values. All data maintenance is done with various ASP which must
be able to do the encryption/decryption by vbscript.

thanks
LJB

 

[Aaron Bertrand - MVP]

Where are you going to display this "encrypted" data in a meaningful form?
Once you've encrypted the information, great, now what you need to protect
is the decryption algorithm.

 

[Chopper]

Anyone have a good idea for encrypting salary data in US $? I have an Access
database with some salary info connected to ASP on our intranet. My manager
is somewhat apprehensive about the level of security currently provided. I'm
using basic authentication (I think that's what it is called). It relies on
NT directory permissions and code to query "AUTH_USER". Does anyone have a
simple encryption idea that can take US$, 5 digit employee ID, encrypt it
and store it in Access' Currency data type? The database will store the
salary encrypted. When an authorized user hits the ASP it will display
decrypted values. All data maintenance is done with various ASP which must
be able to do the encryption/decryption by vbscript.

thanks
LJB

There are a number of encryption scripts here:
http://www.aspin.com/func/search?tree=aspin&qry=encryption&cat=
To improve security there are a number of things you can do, including:
1.If the users accessing this application are using IE then it's better to
use 'Integrated authentication' set under 'directory security' in the
website properties. This will prevent the login details being sent
unencrypted across the network. If they are not running IE then you could
still use basic authentication but do it over SSL.
2.Make sure the server is patched with all the latest security updates.
3.Password protect the database.
4.If those using the application have static IPs then you could restrict
access to the application by IP (in directory security under website
preference).

chopper

 

[ljb]

Only when an authorized user views the single employee record by ASP will
the data be meaningful.

I realize that protection of the algorithm becomes critical. Since the NT
directories don't allow Anonymous browsing I'm counting on that to protect
the algorithm. I'm not expecting high security just something to hinder
accidental release of the info.

My original request was to store the encrypted data in Access' Currency data
type. Is that easily possible? My goal was to not require a change to the
table. Perhaps storing the data in a string is easier to accomplish.

 

[Aaron Bertrand - MVP]

I realize that protection of the algorithm becomes critical. Since the NT

directories don't allow Anonymous browsing I'm counting on that to protect
the algorithm.

Wow, you have a lot of faith. The problem here is that you have an ASP page
which is responsible for decrypting things. So, whether you put that
algorithm right in the ASP page, or in a DLL, there is going to be a vector
for at least using, if not reverse engineering, the algorithm... and trust
me, a determined person within your company is going to get to it. Also,
Access is not the most secure place for this kind of sensitive
information!!!

My original request was to store the encrypted data in Access' Currency data
type. Is that easily possible?

Access doesn't support encryption natively, so what you are going to have to
do is encrypt or encode the data OUTSIDE of the database, and store it in a
VARCHAR column rather than a CURRENCY column. Alternatively, you could use
some other numbering system which is NOT incremental, e.g. $60,000 = 45,
$50,000 = 72, etc. etc. More like a code than encryption. Then, at least,
you could continue to use a numeric-based column.

 

[ljb]

Thanks for the pointer to some algorithms. Certainly enough there for me to
pick one and get going. Looks like I will probably need to store the
encrypted values as a string.

 

[Chopper]

Thanks for the pointer to some algorithms. Certainly enough there for me to
pick one and get going. Looks like I will probably need to store the
encrypted values as a string.

Yes, you'll have to store them as strings as the output from all the
encryption functions are strings.

 

[ljb]

I agree with every point. This application is not well thought out. I'm new
to this work group and was immediately assigned the task of extending what a
former secretary had developed. Around here they give anyone who wants one a
day long class in Access then send them back to their desk with instructions
to procreate. Soon after they get promoted because they have become "expert"
and someone else is expected to complete and extend the application.

 

[Aaron Bertrand - MVP]

then send them back to their desk with instructions

to procreate.

Geez, we can get fired around here for that.

 

[TomB]

They must have an in-house daycare

Geez, we can get fired around here for that.

 

[ljb]

The majority here are Civil Engineers as are all the managers. They are
quite confident in whatever they do. In their opinion end user development
is just fine. They also believe IS projects are always late, over budget and
short on promised functionality.

 

[ljb]

I picked the RC4 algorithm. Do you know if the encrypted string generated by
RC4 can be stored in an Access string type field? Not all characters in the
encrypted string are printable. Do Select and Insert handle these properly?

thanks
LJB

 

[Aaron Bertrand - MVP]

I think we have a different perception of the term "procreate"

 

[Aaron Bertrand - MVP]

I picked the RC4 algorithm. Do you know if the encrypted string generated
by

RC4 can be stored in an Access string type field? Not all characters in the
encrypted string are printable. Do Select and Insert handle these

properly?

Well, you could always try it.

 

[Chopper]

I picked the RC4 algorithm. Do you know if the encrypted string generated by
RC4 can be stored in an Access string type field? Not all characters in the
encrypted string are printable. Do Select and Insert handle these properly?

thanks
LJB

You shouldn't have a problem storing it in a field of type 'text' providing
the ciphertext doesn't exceed 255 characters.
The only character you will have problems with is the apostrophe. Here's
some info:
http://www.aspfaq.com/show.asp?id=2035

chopper

 

[Jeff Cochran]

The majority here are Civil Engineers as are all the managers.

Around here we'd prefer that neither engineers nor managers be allowed
to procreate...

 

[Arnold Shore]

Here's what I did with that particular problem at a gov't site with
international users. (This may sound complex, but it really isn't, and
worked out very nicely. It also got us blessed in a stringent security
review.)

Let me note that the problem in encryption is the problem of key management.
Therefore, I built the solution around the use of public key crypto.

1. In this approach, the user's password is the private key. We don't
store that, but rather its hash, for login authentication.
2. At login, that private key is carried in a form field to the script
doing the lookup, decrypt, and display.
3. The public key, calculated from the password/private key, is used by the
data load script for encryption. It's perfectly secure to retain this
public key in the database, since the private key, the user's password,
can't be derived from it.

What's stored in the database? Only the public key, which is universally
considered safe for publication, and an MD5 hash of the public key, also
safe. Secondly, the salary info is secure from what's widely known to be
the bigtime risk, the insider. And thirdly, even if one password is broken,
all the others remain secure.

I used a very nice COM product for this: see it at www.dyncrypto.com Quite
inexpensive, good sample scripts, and easy to use.

AS

 

[Arnold Shore]

Correction: That " ...MD5 hash of the public key ... " should be "MD5 hash
of the PRIVATE key", the user's password.

AS

 

[Don Grover]

Send Me an email and I pass a function onto you, .
(e-mail address removed)

 

[ljb]

Thanks, but I have already found and implemented something based on RC4
encryption. The function I used came from
http://www.Planet-Source-Code.com/vb/scripts/ShowCode.asp?txtCodeId=6646&lngWId=4