Gunny,
Well, firstly let me say that, so far as I'm concerned, it's great to have a
difference of opinion! Things get learned that way! Also, your statements are,
of themselves, uncannily accurate. I just think they occasionally might not
apply to the issue at hand.
Anyhow:
My post was restricted to the reasons for encrypting, and I stand by that, and
why in-built encryption doesn't even matter if they otherwise have (or obtain)
full access to Access. Encrypting or dump utilities could be slightly
off-topic but is all to do with security and "extraction".
I interpret that to mean that Connie's company wants to hide and protect the
critical tables and queries from the people who purchase the database
Yes. I think we all answered with that in mind. I don't think our ideas were
too broadly dissimilar. Basically it is difficult!
Personally, for my own "retail software", I give the user-site (but not all
the users) full design perms on the tables. Without being irresponsible, I'm
worried about the program being ripped-off and I don't really care if they
change the table design and mess-up their own data! It has also been said "how
many ways can you design a table and what can be secret about that!" (I
reserve judgement)
She has indicated she wants to protect the design more than the data. This is
consistent with my own attempts at retail software, as indicated above.
These customers will have
sufficient permission to open the database, so breaking user-level security
isn't an issue.
No that is wrong. Unless they obtain hacking software or services, ULS will
severely limit what the user can do. Including that "normal users" will not be
able to open a database exclusive, can't make design changes, can't decrypt a
database which this particular post was about. And if they could then by
definition they wouldn't need to, which you didn't seem to understand.
The whole thing relies on (ULS, MDE, etc), which we know can be broken. But if
we go too far down that track, and have too much knowledge, then there isn't
any point in security at all. Yet there is. Connie is probably selling s/w to,
um thinks, Chicken Farmers! Hopefully Chicken Farmers know more about chicken
farming and less about MS-Access security. If she is selling s/w to the
Gunny's of this world, then Heaven Help Her!
These customers will also be able to use Access to
decrypt/decode the application if Connie's company encrypted/encoded the
file before distribution.
Read my post. If they can do that, then they don't even need to decrypt it!
And they can only do that if they break ULS as a pre-requisite, because they
would not normally have exclusive open or anything else beyond running a menu.
They might well break into ULS. In which case, encryption/decryption
(in-built) becomes irrelevant, sure. THEY DONT HAVE TO DECRYPT IF THEY HAVE
THAT!
It's amazing how many people think that this
built-in encryption will safeguard the data from the people who are allowed
to open the database.
I said no such thing. I said it prevents external dump utilities. I said that
if they can get in with sufficient perms to decrypt, then they don't even need
to decrypt they are into it anyway! A properly secured database does not allow
any user such permissions. Password-cracking excepted. (or possibly, no such
user in the distributed mdw)
Thankyou for the reply. I, as I'm sure you, have some interest in the subject.
What we are both doing is trying to give Connie our best advice. In my case
(another post in this thread) I appear to have given conflicting advice.
However, it wasn't about Encryption.
We "retailers" need every means of defence, whatever their limitations. I
thought that was your philosophy as an old US marine too.
Best Regards
Chris
P.S. One of my best security methods is nothing to do with Access, it's
recording my customers. The way I write software, they will surely have to
contact me sooner or later! What's this? Not on my list? My next best method,
is to employ Gunny as a security guard
