G
Guest
I have medical data that needs protection for legal and privacy reasons. Per an excellent post by TC on April 23 (copied below) I think that encrypting the data using rc4 may be the way to go. Does anyone know of a rc4 vba module / code that I can use to encrypt data on the fly? Also, please let me know if I am totally off base on my approach
Thanks
-ha
********Post from TC************
From: TC ([email protected]
Subject: Re: Access Security: Compliance with HIPAA standards?
View this article only
Newsgroups: microsoft.public.access.securit
Date: 2003-04-23 18:36:14 PST
I doubt you'll have much luck meeting any stringent standards
(1) The database password is stored in an obfuscated (but easily reversible
form at a set location within the file. It can be cracked using code that i
easily & freely available all over the web
(2) User level security is based on other (more sophisticated) cryptographi
techniques including RC4 and DES. Unfortunately, because of "schoolbo
howler" implementation mistakes, both of those encryptions are reversible
For example, there is at least one utility which will retrieve & display th
plaintext usernames, passwords and PIDs from any (RC4 & DES encrypted
workgroup file, thus allowing anyone to impersonate the users defined withi
that file
(3) It is also possible to completely desecure an encrypted, secure
database, *without* a workgroup file. But the knowledge & code required t
do this is not, to my knowledge, generally available
(4) Since msaccess.exe runs on the PC (not the server), it is alway
possible for a suitably skilled user to patch that EXE, & remove or bypas
any & all security checks. For example, there is at least one product on th
web, that causes Access to accept *anything* for the username & password
The sad thing is, that (1)-(3) could easily have been avoided by usin
proper cryptographic techniques. And, I can think of a way in which it migh
be possible to correct this "after the fact"
However, (4) will always get you in the end. So there's no way that an
desktop database product could really be said to be very secure. There's n
way that you can protect a PC EXE from (4) (afaik)
HTH
T
Thanks
-ha
********Post from TC************
From: TC ([email protected]
Subject: Re: Access Security: Compliance with HIPAA standards?
View this article only
Newsgroups: microsoft.public.access.securit
Date: 2003-04-23 18:36:14 PST
Dave said:I've created a database in Access 2000 that has sensitiv
information related to patient healthcare. Our corporat
HIPAA Compliance Review Committee has asked that I provid
them with specifications on the MS Access passwor
security and user-level security. The committee wants t
make sure that methods used to achieve these two types o
security meet the specification standards set forth b
HIPAA
I doubt you'll have much luck meeting any stringent standards
(1) The database password is stored in an obfuscated (but easily reversible
form at a set location within the file. It can be cracked using code that i
easily & freely available all over the web
(2) User level security is based on other (more sophisticated) cryptographi
techniques including RC4 and DES. Unfortunately, because of "schoolbo
howler" implementation mistakes, both of those encryptions are reversible
For example, there is at least one utility which will retrieve & display th
plaintext usernames, passwords and PIDs from any (RC4 & DES encrypted
workgroup file, thus allowing anyone to impersonate the users defined withi
that file
(3) It is also possible to completely desecure an encrypted, secure
database, *without* a workgroup file. But the knowledge & code required t
do this is not, to my knowledge, generally available
(4) Since msaccess.exe runs on the PC (not the server), it is alway
possible for a suitably skilled user to patch that EXE, & remove or bypas
any & all security checks. For example, there is at least one product on th
web, that causes Access to accept *anything* for the username & password
The sad thing is, that (1)-(3) could easily have been avoided by usin
proper cryptographic techniques. And, I can think of a way in which it migh
be possible to correct this "after the fact"
However, (4) will always get you in the end. So there's no way that an
desktop database product could really be said to be very secure. There's n
way that you can protect a PC EXE from (4) (afaik)
HTH
T