Access security - is it just a joke?

[MyReceiver]

Following all recommended best practices to secure the mdb database
(http://support.microsoft.com/default.aspx?scid=KB;en-us;q165009), just
to find out there are tools out there to recover the database password
(http://www.everythingaccess.com/products-services.htm); and worst, a
tool to completely remove the user level security, with or without the
mdw file (http://www.etechrecovery.com/019-MDBrecovery.asp). And it
can be done in seconds, much shorter time than I spent on securing the
mdb database!

I assume the need to set up security is to protect the database. If it
is so easy to defeat, why even bother?

 

[Keith Wilby]

Following all recommended best practices to secure the mdb database
(http://support.microsoft.com/default.aspx?scid=KB;en-us;q165009), just
to find out there are tools out there to recover the database password
(http://www.everythingaccess.com/products-services.htm); and worst, a
tool to completely remove the user level security, with or without the
mdw file (http://www.etechrecovery.com/019-MDBrecovery.asp). And it
can be done in seconds, much shorter time than I spent on securing the
mdb database!

I assume the need to set up security is to protect the database. If it
is so easy to defeat, why even bother?

Not, it's not a joke IMO, it's an effective method of keeping users and
"amateur" "developers" out of your system. I don't believe anyone has ever
claimed that Access ULS can't be cracked by a determined hacker with the
right tools (which all cost money). If you want better security then go for
a non-file-based option such as Oracle.

Keith.
www.keithwilby.com

 

[MyReceiver]

Nothing is 100% secure. This statement is always valid, but not always
acceptable. Nothing worst than a false sense of security! Though I
agree that Access is not enterprise class, the fact that there is
product out there which can hand you the password and remove the
security entirely is simply mind boggling. I was told by a non IT
staff that a free utility could recover the database password. With
the workgroup file available, your user, amateur or expert, could spend
as little as $12 to gain admin control of your mdb file. What they
could do with your database and the data is entirely up to them. With
the false sense of security, you would not even notice! I hope this
scenario will never happen to you.

http://www.thegrideon.com/access-password-recovery.html $12
http://lastbit.com/access/default.asp $35
http://www.lostpassword.com/access.htm $45

 

[Keith Wilby]

I was told by a non IT
staff that a free utility could recover the database password.

That has been common knowledge for years. The database password *is* a
joke.

With
the workgroup file available, your user, amateur or expert, could spend
as little as $12 to gain admin control of your mdb file. What they
could do with your database and the data is entirely up to them. With
the false sense of security, you would not even notice! I hope this
scenario will never happen to you.

It hasn't happened yet to the best of my knowledge but that's the risk you
take. The flaws in Access security are common knowledge. Use Oracle if you
want better security.

 

[Brendan Reynolds]

According to Eric Rucker's blog on Access 12
(http://blogs.msdn.com/access/default.aspx) JET's user-level security
features were never actually intended to be user-level security features.
They were actually designed as navigation features.

<quote>
Since JET is a file based database system where users need physical access
to the file to operate on their data, the concept of user level security in
Jet to assign different levels of user access to the data within the same
file was not recommended. To have multiple people use the database but with
different data access privileges, the recommended practice was to move this
data to a centralized service like SQL server or SharePoint lists. However,
Jet has had this feature for some time and it has worked OK for usability
and custom navigation scenarios but isn't recommended for actual security.
</quote>

Now, I should probably not say what I personally think of the suggestion
that the developers of JET's user and group level security system actually
thought they were developing a navigation feature. It will probably be more
productive if we concentrate not on what this says about the past of JET
security, but what it says about the future of JET security, and on that it
is unambiguous. In the future, if you care about security, use SQL Server.

 

[MyReceiver]

According to Eric Rucker's blog on Access 12
(http://blogs.msdn.com/access/default.aspx) JET's user-level security
features were never actually intended to be user-level security features.
They were actually designed as navigation features.

Wow! The Office/VB Programmer's Guide talks about protecting
intellectual property by securing the mdb file. It states that Access
security protects the database and its data. Unbelievable...

Thanks for clarifying that. I was not quite sure where the security
problem lies. Now it is crystal clear!

Now, I should probably not say what I personally think of the suggestion
that the developers of JET's user and group level security system actually
thought they were developing a navigation feature. It will probably be more
productive if we concentrate not on what this says about the past of JET
security, but what it says about the future of JET security, and on that it
is unambiguous. In the future, if you care about security, use SQL Server.

What a paradox! Access.Security newsgroup should always remind readers
about Access not being secure. By the way, there are professional
Access developers who market their Access solution as secured or
suggested so. Saying like the following are plain misleading:

"multi-user client-server applications protected by user-level
security."
"if you intend to distribute your msaccess database you have no control
of the security unless you provide protection for the mdb file...
MDBSecure has been developed to provide this security..."

If all the security design flaw were true, then the ultimate
misrepresentation comes from Microsoft itself: (MS Office 2000/VB
Programmer's Guide)

"Establishing security for your Microsoft Access database file (.mdb)
or project file (.adp) protects intellectual property such as your
solution's structure and programming code. It also prevents your
solution's users from inadvertently changing object designs or code in
a way that would cause your solution to stop working. If your .mdb file
also contains data, establishing security protects sensitive data
regardless of what program is used to access your database file. This
chapter discusses techniques you can use to secure your Access
solution."

I was simply frustrated in my search for a secured embedded database
solution and lured into believing that Access was a reasonable one.
To everyone who read this thread and responded to my posting, I thank
you for clarifying the insecurity of the Access security.

 

[Brendan Reynolds]

Note that I did say that it would probably be more productive if we
concentrated on what that quote meant for the future rather than the past.
Nothing that I wrote was intended or should be interpreted as criticism of
what others have said about JET security in the past. I merely wish to draw
attention to what Microsoft are saying about JET security going forward into
the future.

 

[my_Receiver]

If the mdw file is available, the $12 software will hand you the
password of users in the Admins group. If the mdw file is not
available, the more expensive tool could remove the User Level Security
entirely. Sadly...

 

[my_Receiver]

Point well taken. Thank you.

 

[Goos van Beek]

A way to protect your password to password recovery files is to use
'unreadable' characters such as Altxxxxx and so on. Use characters from
different charactersets.
It could look like this: ????????????????????

A password recovery program (like Advanced Office Password Recovery)
displays characters like these as questionmarks.
You also can use code to let your application only start in a runtime
environment. Users have to use the /runtime switch. The recovery program
can't use that switch, and won't have access to the application to use a VBA
backdoor.

The free EverythingAccess Password Retrieval tool doesn't work either in
this case. It thinks that the mdb file is not password protected, but you
can't open it.


OK, it's a lot of extra work...

 

[Goos van Beek]

Correction: the latest version of AOPR does offer a commandline to open the
database to use the VBA-Backdoor. But you still have to enter the username
and password...