A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Using Forms
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Advice on securing a sensitive Access database



 
 
Thread Tools Display Modes
  #1  
Old April 10th, 2008, 09:30 AM posted to microsoft.public.access.forms,comp.databases.ms-access
Les Desser
external usenet poster
 
Posts: 45
Default Advice on securing a sensitive Access database

I wonder if someone could give me some pointers on the following.

I need to securely encrypt an Access 2003 database currently sitting on
a server with multiple users linking to it from their individual PCs via
an Access 2003 front-end.

I need a hardware/software solution that will:-

1. Encrypt the database on the server so that a copy of it is of no use
to anyone. This is to cover if the server is stolen.

2. Ensure that only authorised users directly connected to the network
can access the database and preferably only via the designated Access
front-end database.

3. Authorised users cannot get a decrypted copy of the file via their
PCs - i.e. cannot use Explorer or similar to copy the file in decrypted
form.

I presume that the solution would include hardware and software
elements.

I would be grateful for any guidance.

Many thanks.
--
Les Desser
(The Reply-to address IS valid)
  #2  
Old April 10th, 2008, 09:59 AM posted to microsoft.public.access.forms,comp.databases.ms-access
Keith Wilby
external usenet poster
 
Posts: 812
Default Advice on securing a sensitive Access database

"Les Desser" wrote in message
news
I wonder if someone could give me some pointers on the following.

I need to securely encrypt an Access 2003 database currently sitting on a
server with multiple users linking to it from their individual PCs via an
Access 2003 front-end.

I need a hardware/software solution that will:-

1. Encrypt the database on the server so that a copy of it is of no use
to anyone. This is to cover if the server is stolen.

2. Ensure that only authorised users directly connected to the network
can access the database and preferably only via the designated Access
front-end database.

3. Authorised users cannot get a decrypted copy of the file via their
PCs - i.e. cannot use Explorer or similar to copy the file in decrypted
form.

I presume that the solution would include hardware and software elements.

I would be grateful for any guidance.


If your data is really that sensitive/valuable then I would suggest using
Oracle or similar since Access security can be easily broken.

Keith.
www.keithwilby.com

  #3  
Old April 10th, 2008, 12:28 PM posted to microsoft.public.access.forms,comp.databases.ms-access
MikeB
external usenet poster
 
Posts: 31
Default Advice on securing a sensitive Access database


"Keith Wilby" wrote in message
...
"Les Desser" wrote in message
news
I wonder if someone could give me some pointers on the following.


If your data is really that sensitive/valuable then I would suggest using
Oracle or similar since Access security can be easily broken.


There is another venerable DB that is used daily by the US Army, Airforce,
Navy and the FBI for the one of the very reasons you seek. After all, it was
originally invented to track the engineering data and the parts to the Space
Shuttle by Boeing, then later ported to the PC environment. I have used it
since 1983 and quite a few of my colleague developers use it for medical
records applications which require a similar security requirement.

www.RBase.com

Still very much alive and used worldwide where other solutions can't make it
work.



Keith.
www.keithwilby.com



  #4  
Old April 10th, 2008, 02:37 PM posted to microsoft.public.access.forms,comp.databases.ms-access
salad
external usenet poster
 
Posts: 47
Default Advice on securing a sensitive Access database

Les Desser wrote:

I wonder if someone could give me some pointers on the following.

I need to securely encrypt an Access 2003 database currently sitting on
a server with multiple users linking to it from their individual PCs via
an Access 2003 front-end.

I need a hardware/software solution that will:-

1. Encrypt the database on the server so that a copy of it is of no use
to anyone. This is to cover if the server is stolen.


I think you'd want a copy that is of use to someone. Hmmmm...zip it up
and put a password only the big cheeses know.

2. Ensure that only authorised users directly connected to the network
can access the database and preferably only via the designated Access
front-end database.


Network access rights.

Usually the front end is run from the C drive. What's more important?
The program/app? Or the data?


3. Authorised users cannot get a decrypted copy of the file via their
PCs - i.e. cannot use Explorer or similar to copy the file in decrypted
form.


Network access rights once again. Remove the Copy right.

I presume that the solution would include hardware and software elements.


Mostly OS elements.


I would be grateful for any guidance.

Many thanks.


Friction
http://www.youtube.com/watch?v=Mh9a5_3ATHY
  #5  
Old April 10th, 2008, 11:10 PM posted to microsoft.public.access.forms,comp.databases.ms-access
Les Desser
external usenet poster
 
Posts: 45
Default Advice on securing a sensitive Access database

In article sOqLj.23706$4O1.6011@trnddc03, Larry Linson
Thu, 10 Apr 2008 15:58:16 writes

[...]

Thank you for your comprehensive response.

Also thanks to the other posters for their ideas.

The background is that the Access application has been developed over
many years and it is not really viable to re-write it.

Due to the prospect of some commercially sensitive data being now stored
in the database, it has become desirable to secure the data.

I do not have major concerns about the Access front end as

1. the staff using it are trustworthy
2. the data would have to be extracted table by table
3. the front-end is an MDE and I think I can securely (reasonably) hide
the table view.

To steal the data via the front end (or an alternative front end once
Access security had been broken) would be non-trivial and they would
have to work within the office (as the data would be encrypted).

My main concern is how to, on the one hand, encrypt the data on the
server (TrueCrypt?) so that if the server is stolen the data cannot be
read, and on the other hand, allowing the Access front end to read the
decrypted data but somehow blocking access to the decrypted data to the
Windows file copy facility.

As far as I can see, once the decrypted data is visible to the PCs
running the Access front end, it is also a matter of a few seconds to
copy the whole decrypted data mdb using Explorer.

I regret that I don't have more encouraging words for you.


Sounds like I have a problem
--
Les Desser
(The Reply-to address IS valid)
  #6  
Old April 11th, 2008, 01:33 PM posted to microsoft.public.access.forms,comp.databases.ms-access
The Frog
external usenet poster
 
Posts: 10
Default Advice on securing a sensitive Access database

Hi Les,

This is a problem that I have solved once before, and I can tell you
that it is fraught with dangers. I have managed to incorporate AES 256
bit encryption on the individual tables, complete with a user
control / access system. I must stress just how much a pain in the
arse this was / is.

The way that I achieved this was to use encryption the same way the
EFS does. Basically it works like this:

1/ You need to generate a *RANDOM* key to be used for the AES
algorithm for each table. I used GUIDs for this and adapted the GUID
to a key.

2/ You need to make a 'master' Asymettric key pair to act as a data
recovery in case of emergency. Use a different GUID.

3/ You take the 'master' key pair, and using the private key encrypt
the AES key for each table, and store the encrypted AES key as a table
property of your defining.

4/ Lock away the AES keys, as well as the 'master' key pair.

5/ At the field (contents) level you use the AES encryption, specific
to the table, to encrypt the contents of each field.

What you should now have is the entire database encrypted with AES
encryption. (I will try to find the links to the VBA code for this).
At this stage no user can access the data in any meaningful way,
unless they happen to have a neat way of breaking either the symmetric
encryption on the fields or the asymmetric used to encrypt the AES key
itself.

Now comes the user part:

For each user you need to generate an asymmetric key pair. This is in
turn used to make an encrypted copy of the AES key, which is attached
to the tables as a property with a name of your choosing. I suggest
the property name either be the user name / id, or some other easily
identifiable term that is specific to each user.

In this way you can also only give users access to the tables that
they need simply by making sure that you dont issue them with an
encrypted copy of the AES key for that table. I suppose you could
extend the model further even to the column / field level if you
wanted, but I thought that to be overkill.

I used the public part of the key pair to encrypt the AES keys, and as
per normal kept the private part private :-) It was my intention to
eventually use certificates with a token to handle this but the
project never went that far.

Anyway, back on with the task at hand. We had two options for handling
the private keys with this. The first was to have them stored in files
on disk / usb key etc.., or alternatively to have them stored in a db,
themselves encrypted. We eneded up using the second system due to
practicality. Users were asked for a username / password to access the
system. The password was MD5 hashed, and in turn the MD5 hash was used
to decrypt the private key again using AES. The way that we knew if
the password was correct was to have the MD5 hash also stored in
encrypted format with the private key. This became the weak point of
the system, but as I said we didnt get to the point of using
certificates and tokens. If the username / password combo was able to
successfully decrypt the AES encrypted private key it would also
successfully decrypt a copy of the MD5 hash associated with that key.
This was done in a table with 3 columns, username, password, private
key.

The administration of this was done through a separate database / app
that was not accessable to anyone except the administrators. It was
kept on a secure usb key (if you can call them that). I am sure you
can think of ways of securing the physical media. User key pairs were
added as needed and expired / removed as needed.

I am sure that you could also implement time restrictions, as well as
network card or IP address restrictions to the application. For
example it is possible to gather the MAC address of a network card, as
well as the IP address of the card as a means of testing the 'local'
environment of the application, though I would have to think about how
you would secure / administer that data.

In the end it comes down to how far you want to go to secure the data
and is it worth it? The method described above will certainly give
your data a heavy level of encryption by most current standards, but
that does not necessarily mean that the model suits your purposes or
is suitable for the task.

The app I wrote is currently stored securely and I do not have access
to the finished code, however I do remember that I located a lot of
what I needed freely available on the net. I will have a look over the
weekend and see if I can locate the sites where the code came from for
the different algorithms.

Hope this gives you some food for thought.

Cheers

The Frog
  #7  
Old April 11th, 2008, 02:48 PM posted to microsoft.public.access.forms,comp.databases.ms-access
paii, Ron[_3_]
external usenet poster
 
Posts: 7
Default Advice on securing a sensitive Access database

I need a hardware/software solution that will:-

1. Encrypt the database on the server so that a copy of it is of no use
to anyone. This is to cover if the server is stolen.


I have not used any strong DB security; but as others have pointed out,
someone with physical access to your serve can with time break any
encryption you apply. You need secure the server, at least in a locked room
in a building with some type of monitored alarm system. That way your random
thief would only get basic office equipment. Using Windows security; your
server hardware may be the only thing of value to an office equipment thief.
A more sophisticated thief may only take your backup media or better yet,
break-in though the internet.


  #8  
Old April 11th, 2008, 05:44 PM posted to microsoft.public.access.forms,comp.databases.ms-access
Les Desser
external usenet poster
 
Posts: 45
Default Advice on securing a sensitive Access database

In article , "paii, Ron"
Fri, 11 Apr 2008 08:48:26 writes

I need a hardware/software solution that will:-

1. Encrypt the database on the server so that a copy of it is of no use
to anyone. This is to cover if the server is stolen.


I have not used any strong DB security; but as others have pointed out,
someone with physical access to your serve can with time break any
encryption you apply. You need secure the server, at least in a locked room
in a building with some type of monitored alarm system. That way your random
thief would only get basic office equipment. Using Windows security; your
server hardware may be the only thing of value to an office equipment thief.
A more sophisticated thief may only take your backup media or better yet,
break-in though the internet.

I accept your comments and recommendations. My main problem still
exists even when physical security of the server has been addressed.
--
Les Desser
(The Reply-to address IS valid)
  #9  
Old April 11th, 2008, 05:44 PM posted to microsoft.public.access.forms,comp.databases.ms-access
Les Desser
external usenet poster
 
Posts: 45
Default Advice on securing a sensitive Access database

In article
, The
Frog Fri, 11 Apr 2008 05:33:58 writes

[snip fine detail]

Phew! I have given it a quick read and there is a lot there that I do
not understand at this stage, but it gives me hope that a possible
solution is appearing.

I will have a look over the weekend and see if I can locate the sites
where the code came from for the different algorithms.

That would be most useful.

Hope this gives you some food for thought.


Thank you - it gives me hope.
--
Les Desser
(The Reply-to address IS valid)
  #10  
Old April 14th, 2008, 08:45 AM posted to microsoft.public.access.forms,comp.databases.ms-access
The Frog
external usenet poster
 
Posts: 10
Default Advice on securing a sensitive Access database

Hi again Les,

Security is depth is certainly the best way I can think of to approach
the issues surrounding any data confidentiality. There are many
factors to consider when approaching such a thing, and most of them
are situation dependant on how you address them. For this you need to
do a proper risk analysis, which I think is probably going beyond the
scope of this forum. If you want to approach such a thing I am happy
to try and steer you in the right direction, so just drop a note in
the forum here.

As for the 4k keys, you must understand that there is a difference in
cryptographic types (algorithms) used. Symmetric and Asymmetric. AES
is a symmetric cipher, commonly used with a 256bit key strength. A
symmetric cipher, in this case AES, is quite fast, safe, and
considered strong for securing information, but it suffers, like all
symmetric encryption, from a problem known as the 'Key Distribution
Problem'. Basically it means that you use the same key to encrypt and
decrypt the data. If you want to send the data to someone with a
symmetric cipher then in order for them to decrypt it they need to
know the same key you do - but you shouldn't transmit the key with the
data! So how do we get around this problem?

The answer lies in Asymmetric encryption. Asymmetric encryption allows
us to have a public and private key which are distinct and separate
from each other, but at the same time directly related to each other.
The way it works is that you can encrypt something with your Private
key (called signing in most instances), and anyone can acquire (safely
and without concern) a copy of your public key and see that the data
came from you. Only your public key can be used to decrypt the data
encrypted with the private key. Now if we reverse the situation, and
we encrypt the data with the public key, only the private key can
decrypt it, which means that anyone can encrypt something, send it to
you, and only you with the private key can decrypt it.

The difference between the two keys is one of information. The private
key contains enough information to be able to reproduce the public key
at will, but the public key is built in such a way that to reproduce
the private key is extremely difficult (but not impossible!). So, what
do we do to make the public key really secure? We use giant 4k keys
that make the problem so large / hard to solve that for all intents
and purposes it is unbreakable / considered secure. The problem with
Asymmetric encryption is that it is slow by comparison to Symmetric.
Slow by a long way.

So how do we solve the problem of your DB encryption? We use
Asymmetric to encrypt the Symmetric keys. The 'heavy lifting' of
encryption / decryption of the data is actually handled by the AES
cipher which is relatively fast, and only the decryption of the AES
keys is done with the slower Asymmetric cipher. This keeps the system
and data both relatively fast and safe, and also gets around the key
distribution problem.

So, crash course in cryptography aside, here are some links that I
have used for the different algorithms and components:

MD5 http://www.di-mgt.com.au/crypto.html#MD5
RSA http://www.di-mgt.com.au/crypto.html#dhvb
AES http://www.frez.co.uk/freecode.htm#rijndael

You will also find some useful code implementations he
http://www.freevbcode.com/ShowCode.asp?ID=3779

I hope that this gets you on your way, and you are successful in
implementing this for your needs. I will monitor this thread if you
need further help with this.

Cheers

The Frog
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 10:39 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.