For "TC" - Request for Clarification on a Comment You Made

[Don]

TC,

Looking for a little clarification on a comment you made (cut-'n-paste
below). When you say "Access security" are you referring to the basic
Access password protection for a database? Or are you referring to
"security" as described in the Security FAQ (i.e. with a MDW file, etc)?

I tried finding the original thread without success.

Thanks!

Don





Is this previous question relevant?

I've created a database in Access 2000 that has sensitive
information related to patient healthcare. Our corporate
HIPAA Compliance Review Committee has asked that I provide
them with specifications on the MS Access password
security and user-level security. The committee wants to
make sure that methods used to achieve these two types of
security meet the specification standards set forth by
HIPAA.

I answered that question, previously, by telling the person that Access
security can (unfortunately) be cracked in various ways using tools
that are in some cases, freely available on the web. "So you will not
have any luck in meeting stringent [security] requirements."

HTH,
TC

 

[Joan Wild]

There are free cracks for the database password. User level security (with
a mdw file) is also crackable. I believe, for about $150 you can buy a
crack for Access Security. I doubt very much that it complies with HIPAA.
You need to use a server based database like SQL Server.

--
Joan Wild
Microsoft Access MVP

TC,

Looking for a little clarification on a comment you made (cut-'n-paste
below). When you say "Access security" are you referring to the basic
Access password protection for a database? Or are you referring to
"security" as described in the Security FAQ (i.e. with a MDW file, etc)?

I tried finding the original thread without success.

Thanks!

Don





Is this previous question relevant?

I've created a database in Access 2000 that has sensitive
information related to patient healthcare. Our corporate
HIPAA Compliance Review Committee has asked that I provide
them with specifications on the MS Access password
security and user-level security. The committee wants to
make sure that methods used to achieve these two types of
security meet the specification standards set forth by
HIPAA.

I answered that question, previously, by telling the person that Access
security can (unfortunately) be cracked in various ways using tools
that are in some cases, freely available on the web. "So you will not
have any luck in meeting stringent [security] requirements."

HTH,
TC

 

[Don]

Joan,

Thanks for the info. Our application is not HIPAA related, but does involve
personnel data. I am trying to work a transition to MS SQL server, but some
of the powers above are pushing our current application into an unsecured
environment (outside our corporate net). I did not realize the user level
security was that vulnerable.

Thanks!

Don

There are free cracks for the database password. User level security (with
a mdw file) is also crackable. I believe, for about $150 you can buy a
crack for Access Security. I doubt very much that it complies with HIPAA.
You need to use a server based database like SQL Server.

--
Joan Wild
Microsoft Access MVP

TC,

Looking for a little clarification on a comment you made (cut-'n-paste
below). When you say "Access security" are you referring to the basic
Access password protection for a database? Or are you referring to
"security" as described in the Security FAQ (i.e. with a MDW file, etc)?

I tried finding the original thread without success.

Thanks!

Don





Is this previous question relevant?

I've created a database in Access 2000 that has sensitive
information related to patient healthcare. Our corporate
HIPAA Compliance Review Committee has asked that I provide
them with specifications on the MS Access password
security and user-level security. The committee wants to
make sure that methods used to achieve these two types of
security meet the specification standards set forth by
HIPAA.

I answered that question, previously, by telling the person that Access
security can (unfortunately) be cracked in various ways using tools
that are in some cases, freely available on the web. "So you will not
have any luck in meeting stringent [security] requirements."

HTH,
TC

 

[TC]

Hi Don

I've been off for a day or two & just saw your post. I concur with what
Joan says. However, you might not realize that Access is really two
components: MS Access, and MS Jet.

MS Access is really just the user interface stuff: forms & reports, and
VBA code "behind the scenes" to tie it all together. The actal data
store is MS Jet, which stores the tables & queries, executes the SQL
statements, maintains the data indexes, & so on.

You could write an application with all of the forms & reports in
Access, but have the data stored in SQL Server (for example) instead of
MS Jet. And the user level security weaknesses lie with MS Jet - not MS
Access. So, if the user level security features of Access/Jet are not
enough, and you need to go with something more robust, eg. SQL Server,
you can still do the user inteface stuff in MS Access. You do not need
to throw the Access baby out with the Jet bathwater!

PS. You win the $10 prize, for the first person in the history of
usenet to refer to SQL Server (the product) as "SQL Server" (the
product name), instead of just "SQL" (the data access language name) !!

PPS. Can I suggest that you do not change the post title when you post
a reply? Some newsreader programs tie posts together by title, they get
confused if you change the title midstream.

HTH,
TC

 

[Chris Mills]

If MS-Access is the front-end interface, then regardless of SQL Server
security, doesn't a "compromised front-end" provide a "portal" into it? (At
least in some circumstances, such as all the data the user OR PROGRAM has
accessibility to)

(I'm not trying to be controversial. Just thinking, unfortunately)

Chris

 

[TC]

I imagine the front end program (eg. Access form) should require the
user to enter credentials (eg. username/password), & those credentials
would be passed to the back-end data store, which would determine
exactly what that user could do with the data.

So the only way to hack it would be to steal someone else's
credentials. Hacking the front end form code would not help, because
you would still have to provide a valid credential to the back end data
store, before it would let you access the data.

But I'm no expert on using Access together with other back-end stores.
Maybe someone else can comment.

TC

 

[Chris Mills]

Appreciate your thoughts.
Chris

 

[Don]

TC,

Thanks for the additional details! Especially the insight into posturing
Access as ...... well ....... and 'access' tool for backends such as Jet,
SQL Server, Oracle, etc. In fact, I have been trying to keep the front end
of my database as Jet independent as possible (i.e. using ADO) so that I can
change what the connection is and minimizing the re-work on everything else.

Thanks again!

Don

PS ROGER THAT on changing the subject line. I will avoid doing that in the
future.

 

[david epsom dot com dot au]

security, doesn't a "compromised front-end" provide a "portal" into it?

Yes.

Access does not support "program-level" security, so
unless you store a sql server password in the front end
interface, the user will have access to any data the
program has access to.

Windows executables may be assigned permissions, which
may (with some work) be used with SQL Server. MSAccess.exe
could be assigned permissions, but they would apply to
any MDB. An MDB could be assigned permissions, but they
won't pass through MSAccess.exe to SQL Server: Access
does not support "program-level" security.

(david)

 

[TC]

I don't get it. Assuming that SQL Server supports a username/password
type of security - wouldn't you require the user to enter a valid
username/password (once), then use that credential to connect to it?
Why would you write those things into the front-end code?

Not disagreeing, just asking.

TC
(off for the day)

 

[Chris Mills]

Well thank you, David Epsom. (that's a joke, I know you're David Gray)

I realise (I think), in talking about "MS-Access" security it means many
different things to many different "environments".

At one end, a "corporate environment" no doubt has other security measures,
such as "burly guards on the door", "Open-plan office-space" so you can't sit
there and "hack"...

At the other end (mine) the s/w is distributed "willy-nilly" (so-to-speak, not
actually quite that bad it's more "known market"). A totally different
situation applies here.

SQL Server cannot apply in my case above. (Well, MSDE might)

Anyway, I can't conceive of a user having to logon twice (once to MS-Access
ULS, then to SQL-Server). It is more likely the logon is "passed-through", or
the program knows how to log-on to SQL-Server. If MS-Access MDE can be broken,
then the security is compromised?

I know people are saying MDE CODE can't be broken (and provided the db is
encrypted). However, that's only a matter of time. The reason MDE code can't
be broken is due to the current limitation of the breakers, it's not an
inherent law of nature? (Original source is not present, but source can be
reconstructed, in principle)

Another thought, what happens to deleted SQL-Server file-space?

Chris

(Another scenario, which I investigated but fortunately did not go to
implementation. The "Head Poncho Firm" wanted to distribute some data-list,
but did not want others to be able to copy the list and present the data as
their own. Impossible? I mean, you are giving them the data! It was not
impossible (except to smart programmers), but it involved encrypting the data,
disabling all "copy keys" on forms, things like that. Now we have Jeff Conrad
(and other MVP's) saying "Oh hell, that's a waste of time" and much worse
"here's how to break it!!!")(Well thankyou very much)

(I hope I have adequately explained where I'm coming from)

 

[Chris Mills]

It may not have been immediately apparent, I appreciate David's input. On this
and many issues over many years.
Chris

 

[Guest]

If the user knows the user name and password, the
user can attach Excel/ODBC to the database to view
and change the data with whatever permission that
user has.

The way to restrict that is to give certain Programs (.EXE)
permission to do things that users can't. This can be done
through the windows file system, which can associate
permissions with executables in the same way that permissions
are associated with user names.

If you have such a system, you can give users additional
rights when they use a particular program: MyEXE allows
them read data that they can't read using Excel/ODBC.

So for example, a user can report a SSN, but can't view
it. Or can print cheques, but can't read balances.

Access doesn't support this when connected to SQL Server,
and the only way Access can simulate it is by using an embedded
user/password.

This is a common kind of security requirement, and Access
against Jet does support this kind of security, through "owner
permission" queries, but that is back to Access security again,
which pre-dates Windows security, and has not been updated.

(david)

 

[TC]

Ok, we are talking of two different things. I thought you were saying
that if you compromized the front-end code, you could hack in to the
database. But I think we agree, that this would only be possible if you
had hard coded a username/password in the front end code. If you did
not do that - ie. if the users were required to data-enter their
username/password - then, compromizing the front-end code would not, in
& of itself, let you get to the database data.

Agree?

Cheers,
TC

 

[david epsom dot com dot au]

Yes, I'm not sure if I understood the original question,
but I regard "all or nothing" user-level security as
inherently compromised, which was all I meant. The
reference to hard coded passwords was only to point out
that the easy solution was not a robust solution.

However I have seen a report of data cacheing in an MDB
which I did not understand. If true, that is a different
kind of "compromise" which is directly associated with
the MDB.

 

[Chris Mills]

GrayLooks like I made a HAM of that ;-)
BTW, your descriptions are great.
Chris

 

[Chris Mills]

Yes, I'm not sure if I understood the original question,

If you mean my original question here, it was that MS-Access security
limitations seem to break (even SQL Server depending on circumstances). (David
described some perfectly "normal" circumstances)

If I'm confused, it is only because there are so many different circumstances.
Users who aren't supposed to have access at all, sneaky users who are supposed
to have only "limited access". If I have a problem, it is because my damn boat
"leaks" as well <vbg> (I do have a boat and it leaks)

I think it is specious to suggest "SQL Server" is of itself more secure, if
the front-end is "leaky" (even as David pointed out Excel/ODBC). Therefore, it
seems a requirement to hide how the Front-end works.

MS-Access has two obvious security limitations:
-ULS can be broken. Not technically by an "average idiot" though certainly by
an internet search. Even if (MS) 10-timed the technicals, if someone breaks it
and posts on the internet, well, that's how I know about quarks and
galaxies...
-MDE can be broken. Though it is said only forms and reports (so far), in fact
it is more than that. At least public functions are exposed in some
"break-ins". So unless one writes one's app with that in mind (simple example,
function called "decode") then "Houston has a problem". I liked to set SQL
Recordsource in form startup code, rather than in a Query----WHAT A WASTE OF
TIME.

The most secure FE might be a full exe, such as writing in C++. I know C++ (I
write DLL extensions to MS-Access in it), but it takes me (speaking only for
myself) 20x longer to write stuff in C++. Worse, DLL extensions in C++ sill
need to have the callables defined in the VBA, therefore, anyone can call the
individual routines.

Yup. Security makes my head hurt, that's for sure!!
Chris

 

[david epsom dot com dot au]

I try to avoid posting messages where honesty
requires that I use my full name - but perhaps
if I had posted fewer like that, I would have
made MVP by now?

(david)

 

[TC]

if I had posted fewer like that, I would have
made MVP by now?

An opaque process, if ever there was one.

TC

 

[Chris Mills]

An opaque process, if ever there was one.

Clear as mud.

Oh, since this is an "ask TC anything" session, do you use the international
divers flag "A" (Blue & White)? Reason I ask, is it's a TERRIBLE flag to see.
Several divers have been runover and killed here (over several years, we try
not to make a habit of it). I myself have a number of times sailed within the
"exclusion zone" before realising there's some blue hanging off the end of the
"surrender flag", and the diver lookout tends not to react with waving arms
too quickly. There are times when I've had to put the prop into neutral
(though I heard divers make good berley!) and drift out of range as quickly
as...um...breaking MS-Access security? There's some discussion here on a
better flag? Or it might help if it had a wire like the flag on the moon.
Chris