It is possible to encrypt one and not the other.
If that's a good idea depends on what you are trying to accomplish. So
let's hear it.
-Tom.
Microsoft Access MVP
[quoted text clipped - 4 lines]Access 2007, XP.Glynn
Hi Tom,
Appreciate the feedback... Simply trying to provide some level of protection
when I deploy using package wizard... now not so much as backend (tried
encryption but ran into refresh link code password issues from the backend so
I moved sensitive data from the backend and made it local to the frontend) so
now I'm looking for some protection in the front-end...
I tried encrypting on frontend which works fine except it doesn't seem
plausible in a runtime environment distributed all over creation... so unless
I'm missing something big time (which is entirely possible bcs of wading into
unknown waters)... it doesn't seem like there is too much protection in a
runtime environment... just looking for something to discourage average users,
pros can probably get into it no matter what...
any thoughts,
thanks in advance,
glynn
It is possible to encrypt one and not the other.
If that's a good idea depends on what you are trying to accomplish. So
let's hear it.
-Tom.
Microsoft Access MVP
[quoted text clipped - 4 lines]Access 2007, XP.Glynn
So you want to protect sensitive data. I'm thinking Salary information
would be a good candidate, just so we don't make this too abstract of
a discussion.
The Employee table has a 1:1 relation with the Salary table
(EmployeeID, SalaryAmount).
You are considering putting this table in the front-end (FE). I think
that's only a good idea if the data is readonly (next time we adjust
salary we will deploy a new version of the FE) or if only one person
uses the information (perhaps one person in the Payroll dept). In most
other cases the table should be in the BE.
A very cheap way of protecting the data is to hide the Salary table.
Right-click the table and check the Hidden attribute. The innocent
user will never realize it is there. By default the option to show
hidden and system objects is off.
A much more complicated option is to use ULS = user-level security
(aka workgroup security) which is an advanced topic you should not get
into without first downloading, studying, and fully understanding the
Security FAQ from microsoft.com. As my friend Larry says: 37 pages
without any filler.
Encryption is NOT a good solution by itself. The SecFaq adresses this
to some extent. You have to realize what Encryption of a database
does: it prevents you from opening the db in Notepad or any Hex editor
and seeing ANYTHING useful. It does NOT prevent any Access user from
opening the Salary table and seeing it in plain text.
You could encrypt the SalaryAmount column using your own encryption
scheme. For example you could add 123456789 dollars to the annual
amount and to the casual observer this column (especially if given an
innocent name like InsuranceID, in an innocent table name like
tblInsurance) it would seem to contain only uninteresting garbage
information. This technique is called "hiding in plain sight".
Anyway, this is a big topic and I'm hoping some of these ideas pertain
to your situation.
-Tom.
Microsoft Access MVP
[quoted text clipped - 29 lines]Hi Tom,
Hi Tom,
Again, appreciate your time for the feedback.
Hiding the sensitive table doesn't seem like enough protection, and the
password required for encryption doesn't seem like the answer in a runtime
environment... so I looked into the accde option... which sounded like a
viable answer until I realized that any table/query in an accde could be
imported or linked (and if I'm not mistaked even updated from anyone that has
Access) so that doesn't help either... and the world of user-level security
is way beyond my scope...
I'm holding onto the idea of moving the sensitive tables from the accde to
VBA code (and also any queries that would update the tables) as well as using
some encryption code to mask any elements of data that have to be kept in a
local table (thought being that if someone tried to hack around the data it
wouldn't be recognizable or even useful without the encryption code)...
now this is all precluded on the monumental assumption that the VBA code in a
form cannot be read, decifered, or magically reproduced from an accde file...
it seems to me patently absurd that MS would enable tables and queries in an
accde file to be imported or linked to from another access db, but who am I
to question that decision...
so any comfort you can give me on monumental assumption would be much
appreciated...
Thanks again in advance,
Glynn
So you want to protect sensitive data. I'm thinking Salary information
would be a good candidate, just so we don't make this too abstract of
a discussion.
The Employee table has a 1:1 relation with the Salary table
(EmployeeID, SalaryAmount).
You are considering putting this table in the front-end (FE). I think
that's only a good idea if the data is readonly (next time we adjust
salary we will deploy a new version of the FE) or if only one person
uses the information (perhaps one person in the Payroll dept). In most
other cases the table should be in the BE.
A very cheap way of protecting the data is to hide the Salary table.
Right-click the table and check the Hidden attribute. The innocent
user will never realize it is there. By default the option to show
hidden and system objects is off.
A much more complicated option is to use ULS = user-level security
(aka workgroup security) which is an advanced topic you should not get
into without first downloading, studying, and fully understanding the
Security FAQ from microsoft.com. As my friend Larry says: 37 pages
without any filler.
Encryption is NOT a good solution by itself. The SecFaq adresses this
to some extent. You have to realize what Encryption of a database
does: it prevents you from opening the db in Notepad or any Hex editor
and seeing ANYTHING useful. It does NOT prevent any Access user from
opening the Salary table and seeing it in plain text.
You could encrypt the SalaryAmount column using your own encryption
scheme. For example you could add 123456789 dollars to the annual
amount and to the casual observer this column (especially if given an
innocent name like InsuranceID, in an innocent table name like
tblInsurance) it would seem to contain only uninteresting garbage
information. This technique is called "hiding in plain sight".
Anyway, this is a big topic and I'm hoping some of these ideas pertain
to your situation.
-Tom.
Microsoft Access MVP
[quoted text clipped - 29 lines]Hi Tom,Glynn
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.