Re: How to prevent importing tables

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 :-)


"'69 Camaro" <ForwardZERO_SPAM.To.69Camaro@xxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:OCfu%23WGqFHA.3720@xxxxxxxxxxxxxxxxxxxxxxx
> Hi, Chris.
>
> > In the first place they have to break ULS with exclusive permissions to do
> > that. (admittedly not difficult)
>
> In Connie's first post, she explained the following:
>
> "We have also hidden several of the critical tables and queries. The
> problem
> is, if I open a new database in Access and have set my options correctly, I
> can import all of the tables and queries.
>
> "To protect our investment, does anyone know how we prevent this type of
> importing?"
>
> 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
> application who would then copy them and use the data in other applications
> without authorization or even sell it themselves. These customers will have
> sufficient permission to open the database, so breaking user-level security
> isn't an issue. These customers will also be able to use Access to
> decrypt/decode the application if Connie's company encrypted/encoded the
> file before distribution. 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 wanted to warn against this common assumption.
>
> HTH.
>
> Gunny
>
> See http://www.QBuilt.com for all your database needs.
> See http://www.Access.QBuilt.com for Microsoft Access tips.
>
> (Please remove ZERO_SPAM from my reply E-mail address, so that a message
> will be forwarded to me.)
> Beware to those who use munged addresses: known newsgroup E-mail harvesters
> for spammers are Ripley@xxxxxxxxxxxxxxx and scott@xxxxxxxxxxxxxxxxxx
>
>
> "Chris Mills" <phad_nospam@xxxxxxxxxxxxxx> wrote in message
> news:uFng6oCqFHA.156@xxxxxxxxxxxxxxxxxxxxxxx
> >> And don't think that encrypting/encoding the database with Access is a
> >> good
> >> idea, because anyone who can open the database can use the same utility
> >> to
> >> decrypt/decode the file.
> >
> > In the first place they have to break ULS with exclusive permissions to do
> > that. (admittedly not difficult)
> >
> > In the second place, if they can get into the database to decrypt it, then
> > they hardly need to mess around with dump utilities which encryption
> > prevents.
> > So it doesn't matter to decrypt it, in that event, because they can get
> > into
> > the database by "proper methods" anyway.
> >
> > In-built Encryption is fundamental as a line of defence against simple
> > dumping.
> >
> > Chris
> >
> >
>
>


.

Relevant Pages

  • Re: SQL or Access DB
    ... As far as encryption goes though... ... with Sql Server you can use SQL DMO and encrypt your stored procedures ... installation - Security was absolutely critical and in most instances, ... > then we create a nice gui around this database and sell it to automotive ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Cryptography in SQL Server 2000
    ... A company is vulnerable when its security ... > database encryption solution with protected key-management software ... > tested by the SQL Server Test Lab. ...
    (microsoft.public.sqlserver.security)
  • Re: Anything to this mumbo jumbo I found while surfing the net?
    ... > We believe there is one very simple rule in encryption - if someone can ... someone else will be able to decrypt it. ... > navigate inside the Virtual Matrix is created. ... > security at low computational cost. ...
    (sci.crypt)
  • Re: Which is more secure RC2 or RC4 ?
    ... same database temporarily, until the order is approved manually and the ... obviously there are a LOT of security related issues that arise ... itself in order to decrypt the information, ... meaning if I encrypt the information using AES and a password driven ...
    (sci.crypt)
  • Re: How to crypt for 1,000,000 years into the future?
    ... Making certain someone bothers to actually decrypt it. ... The problem with using secure encryption right now and just hoping ... physical security, why bother encrypting it?) ... Put a time-lock on your journal. ...
    (sci.crypt)