Re: How secure is a secured database?

TC, big thanks to you too. Your website was another one that helped me quite
a bit. Your diving pictures look great, by the way - lol.

I'm pretty confident that I've covered the guidelines in the Security setup
and that the database is as secure as I can make it without writing a lot of
code. I'm working on the code for disabling the shift bypass key right now.
Again, it's from one of the MVP's websites and due credit will be noted. The
users will only have access to certain custom toolbars.

While the main database will have the sensitive cost issues - i.e. their
rates, expenses we pay, etc. - if it's cracked it won't be a catastrophe.
Some of the consultants might want to adjust their rates, however - and
that's what I want to avoid. I thought about putting it on our SQL server,
but then I would lose control of handily accessing it. The IT people don't
like too many hands in the fire (and rightfully so) when it comes to the
major servers. The good thing about living on the Texas coast is that we
have wonderful disaster recovery technology in place for times when we're hit
with hurricanes. So that's one headache I don't have to worry about daily.

Oh - one other thing .. I got the industrial size Tylenol after I crashed my
database twice while first attempting user-level security - it tastes great
with margaritas! Thank goodness I followed the first rule, make a copy
before you attempt security. Again, thanks to all of y'all for your
continued help and support.

Suzann

"TC" wrote:


Suzann wrote:

I've been reading the posts on several threads and one has got my curiosity
aroused. Can a person circumvent all security that has been set up on a
database simply by creating a new database and importing objects from the
secured database into it?

No. This means that the security was not set up correctly. No if's,
but's or maybe's.

I've successfully (finally) got the user level
security working the way I want it to after several readings of the Security
FAQ and a big bottle of tylenol, so I was curious just how safe the data
would be.

Unfortunately there are products on the web that will reverse engineer
the plaintext passwords from a workgroup file. So that's like everyone
writing their password on a *** of paper that is stuck on the monitor
screen. This problem is due to a simple mistake in how MS encrypts the
passwords in the workgroup file. Unfrtunately, it aint gonna' change
now - believe me!

There is a way that you can fiddle the security, such that the
available workgroup file does not contain a workable Admins group. So
then, even though anyone can get the passwords from that workgroup file
(using a product as described above), they can *not* get Administrative
priviliges to that database (from that workgroup file). I think (but am
not sure) that this technique is described in the Acces Security FAQ, a
document often referenced in discussions of security.



The users do not have access to any of the tables or queries and
can only run the queries with the owner's permission.

That's good. It stops people fiddling with the BE file manually. But
they can still use a cracking product to find all the usernames and
passwords in the workgroup file, then write code to try those users,
successively, until they find the one(s) that let them access the data.


Which leads me to another question. Since I work with financial statements
that shouldn't be viewed by everyone I had already planned on not putting any
sensitive financial data into the front-end of the database.

Good! See above.


If I link
certain tables in this less-sensitive database to a database that is just for
upper management (which has the appropriate security on it), can a user of
the low-level database trace any outside links? The high-level database will
be on another server.

The information from a table link can generally seen in a normal text
editor. For exampe, if you link to a simple-password protected back-end
database, it is easy to find that password, in the FE file, using only
a text editor.


Once again, thanks for any and all help. It's been a while since I've
actively used Access and I've decided I either need a bigger bottle of
Tylenol or I should stick to accounting - lol.

Buy it in bulk, that's what I say!

HTH,
TC (MVP Access)
http://tc2.atspace.com


.