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
  #21  
Old April 17th, 2008, 11:13 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

In article
, The
Frog Thu, 17 Apr 2008 01:59:10 writes

[...]

I hope this helps a bit.


More than a bit - I think I now do understand the issues and techniques
involved.

I am very grateful for you long and comprehensive reply. I am now going
off to have a quick read of Cryptography for Dummies.

I'm sure I'll be back

Many thanks again.

--
Les Desser
(The Reply-to address IS valid)
  #22  
Old April 17th, 2008, 04:26 PM posted to microsoft.public.access.forms,comp.databases.ms-access
[email protected][_2_]
external usenet poster
 
Posts: 11
Default Advice on securing a sensitive Access database

Anytime. Come back with any questions you may have and I will do my
best to answer them. Another good read for a budding cryptologist is a
book by Simon Singh called 'The Code Book'. It gives you an
understanding of what the different types of cryptography are as well
as how they have and are used. Looking back through history with this
book shows quite clearly where systems have failed not because the
cryptographic standard was insufficient, but rather that the
implementation was insuffucient and made an otherwise strong cipher
vulnerable.

Its all in the way you do it :-)

Cheers

The Frog
  #23  
Old May 7th, 2008, 10:21 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

In article
,
" Wed, 16
Apr 2008 01:24:04 writes

The AES key for each table was stored as a table property with DAO
code, encrypted Asymmetrically (public / private), for each user that
had access to the table.


I have been going carefully through your posts and am progressing well.

Just one query at this point. Why cannot the AES key be encrypted with
a second symmetric key rather than Asymmetric?

In any event, you are not publishing the public key and the private key
has to be kept secret so why not just use AES a second time?
--
Les Desser
(The Reply-to address IS valid)
  #24  
Old May 8th, 2008, 10:15 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 Les,

The use of the Public / Private key pairs is simply for the separation
of users from one another. By using the key pairs for each user you
have the ability to grant / revoke permissions on a table by table
basis, or alternatively remove a user from access completely without
interrupting any other users of the system.

In essence, if you were to use a single AES key as the access code for
all users, say for example they type in a username / password and get
the AES key back in return, you have the problem of how to secure that
AES key. Where would you store it? By using the public / private key
pairs you dont have to worry about that problem because the only
exposed information is able to be publicly exposed. In this way you
can store any AES key or keys or data with a public / private key
pair.

The question then becomes why not use the public / private key pairs
as the primary means of encrypting all the data. There are two reasons
for this, the first being speed. Public / Private key encryption is
much slower to operate than symmetric encryption such as AES or DES
etc... It is theoretically possible to operate this way, but the
'horsepower' needed to do it in a timely manner for any significant
amount of data becomes a serious problem, even with current hardware.

The second reason is that you need to keep a 'central' copy of the
data available to be worked with for each user. If you use Public /
Private to encrypt this data you would require that each user has a
unique copy of the data as only their key pair could properly would
with that encrypted copy.

In short then, the basis for using the two schemes together is simply
one of practicality. We use the public / private key pairs to secure a
unique (user specific) copy of the 'central' AES key(s) that are
needed to get at the data. Each user logs in, their private key
generated from their password and username, decrypts the AES keys as
needed to access the data they are allowed to access. When you need to
remove a user from the system you can remain confident that that the
data will remain secure and simply remove the users username /
password from the system and not disrupt any other user in the system.

In theory you could also use AES or another symmetric cipher as the
means of securing the other AES keys. The condition being that you
still maintain the separation between the users username / password
key, and the key(s) needed to get at the data. If you do this it can
work fine, but you will lose the ability to operate with things like
secure tokens and such which typically work with certificates and
asymmetric encryption schemes. If you dont need / want the option to
employ tri-factor security then you can go with the more simple
username and password only. You would need to make some sort of check
in the authentication system / login so that the app knows if the user
has entered the correct data of course, same as before, then just make
sure that a copy of the tables AES key is encrypted for each user with
the users AES key. I think this should pretty much work the same for
you if you dont need the extra authentication of a smart card / token.

Is this what you were asking? I hope I understood you correctly. If
you need more info just let me know :-)

Cheers

The Frog
  #25  
Old May 8th, 2008, 11:37 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 Thu, 8 May 2008 02:15:05 writes

[...]

Is this what you were asking? I hope I understood you correctly.


Yes - just perfect.

If you need more info just let me know :-)


I'm sure I will be back

Thanks again.
--
Les Desser
(The Reply-to address IS valid)
  #26  
Old May 18th, 2008, 01:11 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

We have progressed a long way and we are testing the encryption
functions and have seen some odd behaviour and wonder if there is a
problem.

We have a query that shows the original text, the encrypted string and
then the decrypted string - it is working fine.

However, there is a certain pattern of results that we do not understand
where we have identical string values in different records (user name
and event log text).

In the case of user name (8 chars), we have records with identical
strings and the encrypted values (32 chars) are totally different each
time.

So question one is if the initial values are the same why are the
encrypted values not the same (we are not using an initialization
vector)

In the case of the log text (20 chars) the first 32 characters of the
encrypted string is always the same while the remaining 32 are always
different.

So question two is why are we seeing this odd behaviour.

We intend using an initialisation vector to stop this happening but
would still like to understand what is going on.
--
Les Desser
(The Reply-to address IS valid)
  #27  
Old May 19th, 2008, 09:37 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 Les,

I just want to make sure I understand this correctly so that I can
answer properly. What I think you are saying is that when using the
same (I am assuming AES) key to encrypt some text / data, that you are
seeing different outputs in different parts of the program.

If this is the case I suspect that the source of this lies in the
string / plaintext to byte conversion (and possibly the reverse also).
Theoretically the operation to encrypt (without padding) should
produce the same result for the same text / data each time it is done
if using the same key.

Things to check for are these:
1/ Are the keys being used actually the same
2/ Is the data decrypting properly
3/ If you are operating the code "By Hand" in the editor and encrypt
something does the result match the same when using the application
4/ Are the sections of code that are used to encrypt and decrypt the
same? (ie/ is the process and encryption / decryption methods being
used the same)
5/ Does the data decrypt properly?
6/ Is the source (plaintext) exactly the same when doing the testing.

The most common issue I have come across was the conversion of the
plaintext to a bytearray was producing different bytearrays. As it
turnded out the code that was feeding the plaintext to the encryption
algorithm was actually producing different plaintexts that looked the
same on screen (so to speak) but were in fact different. This came in
my case from some simple data type conversions that I wasnt handling
properly. The root cause was the variant data type being used to house
the plaintext instead of a string. When dealing with numbers in
particular it caused issues. Using strict data types eliminated the
problem.

Aside from that, the only other thing that I could think of is that
there may be an issue with the algorithm implementation itself. If you
like we can try and beat the source code to death to see if there are
any uncooperative lines of code :-) Please understand I am not asking
to post your proprietary code here or data, just the algorithm
implementation code so that if you think we need to dissect it we can.

Please keep me posted, and try the "By Hand" testing with the same
data multiple times to see if you get the same strange behaviour.

Cheers

The Frog
  #28  
Old May 22nd, 2008, 10:03 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 Mon, 19 May 2008 01:37:51 writes

[...]

Please keep me posted,


Thank you for your previous post. We have introduced an IV so the
problem has gone away. I still want to understand what was going on so
will do some more test when I can.

One side affect of the encryption has surfaced. Obvious really, but did
not think of it.

If fields are encrypted then basically all indexes go out of the window.

So to fill a pull-down list from a table, the whole table needs to be
decrypted (we are using a query calling the decrypt function) and then
Access has to build a temporary index to sort.

For 26K records the decrypt is instant (query without sort) but with the
sort it is about 16 seconds.

Two solutions we can think of. Have a separate field containing the
first character in clear text or equivalent ASCI code. Or introduce our
own sequence field. Both solutions require these fields to be
maintained every time the text is changed or a record created.
--
Les Desser
(The Reply-to address IS valid)
  #29  
Old May 23rd, 2008, 10:05 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 Les,

Yes, indexing can be slightly problematic. One thing I did to help was
to populate a recordset with the results of the 'decryption query',
and then did my sorting / filtering from there. It is much faster to
operate in memory than off the HD. I dont know if this will suit your
situation though. I found working with ADO disconnected recordsets
quite efficient for this purpose, and you can keep the data secure
even across the 'wire' this way by having a two stage process:
1/ first query simply gets the data 'raw' from the encrypted recordset
still in encrypted form
2/ Make a function that takes the 'raw' recordset and returns a
decrypted one.

Let me know if you want to bounce this around some more.

Cheers

The Frog
  #30  
Old June 17th, 2008, 12:43 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, 23 May 2008 02:05:50 writes

Let me know if you want to bounce this around some more.


I would just like to tender my sincere thanks for all your help.

The project is coming to an end - based primarily on your advice and
help.

Many thanks once again.
--
Les Desser
(The Reply-to address IS valid)
 




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 02:01 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.