A
Arejan
previous versions of Ms Access is not secure .
Is it still the same ?
if not
how to upgrade and secure an .mdb in Access 2007.
Is it still the same ?
if not
how to upgrade and secure an .mdb in Access 2007.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
D
Douglas J. Steele
There is no user-level security in Access 2007 (at least, not in the new
database format: you can still use it if you continue to use the MDB format,
but it's no different than before).
database format: you can still use it if you continue to use the MDB format,
but it's no different than before).
A
Arejan
I am Intending to distribute the access file along with the application
so
is it still possible to retrive the password by using tools like
Accesspassword recovery as
in older versions ?
(which leaves a critical security hole
even if access security /windows is configured .
giving the only option to switch to other RDBMS.)
so
is it still possible to retrive the password by using tools like
Accesspassword recovery as
in older versions ?
(which leaves a critical security hole
even if access security /windows is configured .
giving the only option to switch to other RDBMS.)
R
Rick Brandt
Arejan said:I am Intending to distribute the access file along with the
application
so
is it still possible to retrive the password by using tools like
Accesspassword recovery as
in older versions ?
(which leaves a critical security hole
even if access security /windows is configured .
giving the only option to switch to other RDBMS.)
To secure data from non-users use network permissions on the file or folder.
To secure data from USERS don't store it in an Access file.
S
solsyd
Rick Brandt wrote:
????
To secure data from USERS don't store it in an Access file.
????
K
Keith Wilby
solsyd said:Rick Brandt wrote:
????
And your point is ... ?
D
Douglas J. Steele
Keith Wilby said:And your point is ... ?
Presumably he/she didn't understand Rick's point that you can't successfully
protect data in an MDB/MDE file.
A
Alan Cossey
Doug and friends,Douglas J. Steele said:Presumably he/she didn't understand Rick's point that you can't
successfully protect data in an MDB/MDE file.
A gentleman called Brent Spaulding and I had a long discussion on this
over at UtterAccess.com and came up with what we think is a decent way
of securing data from users in Access 2007 files (as in accdb/e files,
not mdb/e files). However, despite the thread being viewed over 3000
times, only one other person tried it out :-(.
I would be most interested in you opinion if you had the chance to
have a look. I summarised the discussion in a PDF file which you can
get at http://www.pdtltd.co.uk/pdtl/technicalresources.htm.
Alan Cossey
J
Jeff Conrad
Hi Alan,
I saved that thread on UA in my Favorites a long time ago for future reading. I'm too busy right now
with my current project to fully test your findings, but as soon as my time is available again, I'm
very interested in trying this out. I'm quite curious myself to see this process.
I'll personally try and get back with you when the time comes.
--
Jeff Conrad
Access Junkie - MVP
http://home.bendbroadband.com/conradsystems/accessjunkie.html
Access 2007 Info: http://www.AccessJunkie.com
in message:
I saved that thread on UA in my Favorites a long time ago for future reading. I'm too busy right now
with my current project to fully test your findings, but as soon as my time is available again, I'm
very interested in trying this out. I'm quite curious myself to see this process.
I'll personally try and get back with you when the time comes.
--
Jeff Conrad
Access Junkie - MVP
http://home.bendbroadband.com/conradsystems/accessjunkie.html
Access 2007 Info: http://www.AccessJunkie.com
in message:
L
Lynn Trapp
Doug and friends,
Alan,
I did a quick scan of the PDF and it looks very interesting. I'm wondering,
at first glance, if a hacker can mine the mid-tier database password from
the FE and, then, open the mid-tier database and mine the backend database
password. I haven't used 2007 at all yet, so can't test it out, but will do
so as soon as I have a machine with 2007 on it.
A gentleman called Brent Spaulding and I had a long discussion on this
over at UtterAccess.com and came up with what we think is a decent way of
securing data from users in Access 2007 files (as in accdb/e files, not
mdb/e files). However, despite the thread being viewed over 3000 times,
only one other person tried it out :-(.
I would be most interested in you opinion if you had the chance to have a
look. I summarised the discussion in a PDF file which you can get at
http://www.pdtltd.co.uk/pdtl/technicalresources.htm.
Alan,
I did a quick scan of the PDF and it looks very interesting. I'm wondering,
at first glance, if a hacker can mine the mid-tier database password from
the FE and, then, open the mid-tier database and mine the backend database
password. I haven't used 2007 at all yet, so can't test it out, but will do
so as soon as I have a machine with 2007 on it.
A
Alan Cossey
Cheers, Jeff. I look forward to hearing from you.
Alan
Alan
A
Alan Cossey
Hi Lynn,
There are three possible weaknesses with vPPC (when used with an
Access back end) that I know of. These are:
1) Ability to get at the data via Automation if the hacker knows the
location of the back end. An example of this might be where a form is
open in the Access front end and a user uses VBA from another
application, e.g. Excel. If they use GetObject to hook into the
already open Access application, they can use this to
read/modify/delete data in the back end if they know where that back
end is. If they know or can guess the names of the tables in the back
end, they can do this quickly; if they don't, they could find out the
names from one of the system tables. However, if the back end location
is not known to the hacker, I don't know of any way of getting at the
data using "normal" methods such as using VB/VBA. Note that if the
back end is a server database such as SQL Server, it appears to be
free from this weakness.
Having said all the above, I can't remember how I hacked into a back
end. It is a while since I did it and didn't keep my code. Will try
again later. I wonder whether I had got some linked tables in my front
end at the time and was looking at those....
2) "Mining" the mid-tier database password from the front end. In my
example, I just set up that password in the declarations section of a
module. It may be that if the front end is encrypted that this will
stop people from getting to it from some tool outside Access. If the
encryption method is all it is cracked up to be (pun intended) and you
make the front end into a .accde file, maybe this is sufficient. If
not, obfuscating it may be the only means of hiding it, e.g. creating
on the fly with some really obscurely written code.
3) One of these sniffer thingies that can read network traffic and
which can pick out the database password as it whizzes across the
network. If there is a possibility of this happening, then we are in
trouble (as are SQL Server junkies using SQL Server authentication?).
Alan
There are three possible weaknesses with vPPC (when used with an
Access back end) that I know of. These are:
1) Ability to get at the data via Automation if the hacker knows the
location of the back end. An example of this might be where a form is
open in the Access front end and a user uses VBA from another
application, e.g. Excel. If they use GetObject to hook into the
already open Access application, they can use this to
read/modify/delete data in the back end if they know where that back
end is. If they know or can guess the names of the tables in the back
end, they can do this quickly; if they don't, they could find out the
names from one of the system tables. However, if the back end location
is not known to the hacker, I don't know of any way of getting at the
data using "normal" methods such as using VB/VBA. Note that if the
back end is a server database such as SQL Server, it appears to be
free from this weakness.
Having said all the above, I can't remember how I hacked into a back
end. It is a while since I did it and didn't keep my code. Will try
again later. I wonder whether I had got some linked tables in my front
end at the time and was looking at those....
2) "Mining" the mid-tier database password from the front end. In my
example, I just set up that password in the declarations section of a
module. It may be that if the front end is encrypted that this will
stop people from getting to it from some tool outside Access. If the
encryption method is all it is cracked up to be (pun intended) and you
make the front end into a .accde file, maybe this is sufficient. If
not, obfuscating it may be the only means of hiding it, e.g. creating
on the fly with some really obscurely written code.
3) One of these sniffer thingies that can read network traffic and
which can pick out the database password as it whizzes across the
network. If there is a possibility of this happening, then we are in
trouble (as are SQL Server junkies using SQL Server authentication?).
Alan
A
Alan Cossey
Hi Lynn,
Sorry about the top posting. Slipped into it without thinking. Will
try harder next time.
The sort of code referred to in 1) below is as follows (once you have
set references to the Microsoft Access 12.0 Object Library and
Microsoft Office 12.0 Access Database Engine Object Library where
C:\test\fe.accdb (or .accde) is the front end and C:\test\data.accdb
is the back end. This works if fe.accdb has a form open.
Public Sub HackQuery()
Dim app As Access.Application
Dim rst As DAO.Recordset
Dim db As DAO.Database
Set app = GetObject("C:\test\fe.accdb")
Set db = app.CurrentDb
Set rst = db.OpenRecordset("Select tblNames.* from tblNames in
'C:\test\data.accdb'")
rst.Edit
rst(2) = "Wiseman"
rst.Update
rst.Close
Set rst = Nothing
Set db = Nothing
Set app = Nothing
End Sub
Alan
Sorry about the top posting. Slipped into it without thinking. Will
try harder next time.
The sort of code referred to in 1) below is as follows (once you have
set references to the Microsoft Access 12.0 Object Library and
Microsoft Office 12.0 Access Database Engine Object Library where
C:\test\fe.accdb (or .accde) is the front end and C:\test\data.accdb
is the back end. This works if fe.accdb has a form open.
Public Sub HackQuery()
Dim app As Access.Application
Dim rst As DAO.Recordset
Dim db As DAO.Database
Set app = GetObject("C:\test\fe.accdb")
Set db = app.CurrentDb
Set rst = db.OpenRecordset("Select tblNames.* from tblNames in
'C:\test\data.accdb'")
rst.Edit
rst(2) = "Wiseman"
rst.Update
rst.Close
Set rst = Nothing
Set db = Nothing
Set app = Nothing
End Sub
Alan
L
Lynn Trapp
Hi Alan,
Worry thou not. I'm neither an advocate of top posting or bottom posting.
I'll take it either way I can get it. Thanks for the additional information.
Hopefully, I'll have A2007 installed somewhere soon so that I can check all
this out. I've been somewhat concerned with the absence of ULS in 2007.
Worry thou not. I'm neither an advocate of top posting or bottom posting.
I'll take it either way I can get it. Thanks for the additional information.
Hopefully, I'll have A2007 installed somewhere soon so that I can check all
this out. I've been somewhat concerned with the absence of ULS in 2007.
A
Arvin Meyer [MVP]
Douglas J. Steele said:Presumably he/she didn't understand Rick's point that you can't
successfully protect data in an MDB/MDE file.
That's true of any file. If someone wants data and they know enough and try
hard enough, they will get it, assuming that they don't get caught trying
first. But that is relative. It is easier with Access than Oracle, or
SQL-Server, but not impossible with either. Data stolen from ChoicePoint and
credit card processors have proven that. Once data can be stored locally, it
is not secure at all. Laptops stolen from Wells Fargo, the VA, and many
other sources proved that this year.
D
David W. Fenton
That's true of any file. If someone wants data and they know
enough and try hard enough, they will get it, assuming that they
don't get caught trying first. But that is relative. It is easier
with Access than Oracle, or SQL-Server, but not impossible with
either. Data stolen from ChoicePoint and credit card processors
have proven that. Once data can be stored locally, it is not
secure at all. Laptops stolen from Wells Fargo, the VA, and many
other sources proved that this year.
The biggest security vulnerability in any organization comes from
the fact that you have to give your legitimate users permission to
use and edit the data. Hacking is really the least of your worries.
K
Keith Wilby
Alan Cossey said:Doug and friends,
A gentleman called Brent Spaulding and I had a long discussion on this
over at UtterAccess.com and came up with what we think is a decent way of
securing data from users in Access 2007 files (as in accdb/e files, not
mdb/e files). However, despite the thread being viewed over 3000 times,
only one other person tried it out :-(.
I would be most interested in you opinion if you had the chance to have a
look. I summarised the discussion in a PDF file which you can get at
http://www.pdtltd.co.uk/pdtl/technicalresources.htm.
Hi Alan.
I must admit that my interest in A2007 has been nil up until now since ULS
isn't supported in the new format but reading your paper has now given me a
reason to download the beta and have a play. Thanks.
Regards,
Keith.
www.keithwilby.com
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.