>Access 2007, XP.
>
>Is it possible to encrypt only the backend or does both the frontend and the
>backend have to be encrypted?
>
>Thanks in advance,
>
>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
>
>
>Tom van Stiphout wrote:
>>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
>>
>>>Access 2007, XP.
>>>
>>[quoted text clipped - 4 lines]
>>>
>>>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
>
>>Hi Tom,
>>
>[quoted text clipped - 29 lines]
>>>>
>>>>Glynn

>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
>
>Tom van Stiphout wrote:
>>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
>>
>>>Hi Tom,
>>>
>>[quoted text clipped - 29 lines]
>>>>>
>>>>>Glynn