Data security of accdb files (1 Viewer)

[JohnPapa]

In general the data in a accdb file can be viewed.

Are there any steps that can be taken to prevent this from happening by unauthorized users?

 

[jdraw]

Do you have some sort of Login procedure? If so, how do unauthorized get access to same?
Possibly Encryption?

 

[JohnPapa]

I have login procedures, but there are ways to get to the data of any .accdb.

What do you mean by encryption?

I use encryption in my SQL Server solutions where the db is on Azure. In this case encryption is used when data travels on the internet.

 

[ComputerVersteher]

Without a terminal server, you always need access to the backend, via share. You can try to hide the path, but that's bad security by obscurity! Ms Access encryption before Ms Access 2010 is useless (https://www.everythingaccess.com/accessdatabaserepair_info.asp)

On a terminal server you can lock everthing, but the access runtime to the users, so they don't need access to the share.

Best solution is a RDBMS like SQL Server, MariaDB, Postgres, .... They allow per user settings.

 

[jdraw]

This link from M$oft provides details.

 

[JohnPapa]

To simplify the problem, is there a way to secure the data in a .accdb file, once this file is available?

 

[isladogs]

Access databases cannot be made totally secure against a skilled and determined hacker with sufficient time and motivation.
For that reason, they should never be used to store data such as credit card details where high level security is a necessity.
However, you can do a lot to minimise the risk of someone meddling with your data.

See my article for information on what can be done

Improve Access Security 2

This article explains how to apply various security measures to make your databases as secure as possible. An example app is used to illustrate the possible methods available

www.isladogs.co.uk

 

[JohnPapa]

Many thanks Isladogs. Will review.

 

[isladogs]

Ms Access encryption is useless (https://www.everythingaccess.com/accessdatabaserepair_info.asp)

I disagree completely with that statement
There are a lot of weaknesses in Access security but the 128-bit encryption in the ACCDB file format is definitely not useless.
Nor does anything in that article on Wayne Phillips' excellent website have any bearing on your comment.

Now if you had specified that you were referring to the old MDB file format or to the VBA project password, then your comment would have been valid. See my three part article

Compare Access File Security

This article compares the security of the MDB & ACCDB file formats together with the compiled MDE & ACCDE versions.

www.isladogs.co.uk

 

[ComputerVersteher]

I disagree completely with that statement

And now I do the same Mixed that up with sth. else. But to open the BE you need the pwd, what then can be recovered from the FE (or is that wrong too?).

Thanks for correction!

Do you agree on TS, as only way to really secure it?

 

[isladogs]

The BE password can easily be recovered from the BE unless you take steps to prevent this. For example, see

Encrypted Split No Strings

This example app shows how an Access database can be made reasonably secure against hackers whilst still allowing full functionality to authorised users.

www.isladogs.co.uk

As for your question regarding TS, that can certainly help with security but I wouldn't ever state that makes Access really secure.
The kinds of approach I use in the above link are probably far more secure

BTW I only know one other person who uses 'sth' as an abbreviation. Have you just 'outed' yourself?

 

[ComputerVersteher]

BTW I only know one other person who uses 'sth' as an abbreviation. Have you just 'outed' yourself?

No, I always use the same nick except on Github. What are you thinking, who I am?

 

[JohnPapa]

Your comments are very useful.

Can I pose a challenge? Can you post a simple accdb file (say with one table) that you think it is secure and we try to unlock it?

 

[isladogs]

Your comments are very useful.

Can I pose a challenge? Can you post a simple accdb file (say with one table) that you think it is secure and we try to unlock it?

That's what my various security challenges were designed for. They were made in increasing levels of difficulty but all are intended to be solvable.
The first is a bit too easy. Try this one....

Hidden Message Challenge

This is the second in a series of security challenges designed to show ways of making Access apps reasonably secure.

www.isladogs.co.uk

or this

Encrypted Split No Strings

This example app shows how an Access database can be made reasonably secure against hackers whilst still allowing full functionality to authorised users.

www.isladogs.co.uk

 

[Josef P.]

Can I pose a challenge? Can you post a simple accdb file (say with one table) that you think it is secure and we try to unlock it?

I'll start with as simple example with a protected backend (BE encrypt with password) and a frontend with linked table (without password in TableDef.Connect property)

Target:
* Backend/Frontend (multi-user application) - BE is protected, FE will be an accde
* Use normal Access functions in FE

Note: Password for the backend is visible in the frontend.

Problem: if you access the frontend from outside, where the BE connection is open, you can also read the data from outside.

Dim AccApp As Application
Set AccApp = GetObject(CurrentProject.Path & "\FE.accdb")

Dim rst As DAO.Recordset
Set rst = AccApp.CurrentDb.OpenRecordset("Tab1")
MsgBox rst.Fields(0).Value ' <--- read data from linked table (protected BE) in FE

=> Even if you do not show the password in the linked tables, data access is possible as soon as the "original" FE has access.

 

[isladogs]

Problem: if you access the frontend from outside, where the BE connection is open, you can also read the data from outside.

That issue can be prevented by using disconnected ADO recordsets (AKA in-memory recordsets) as in my second example linked above

 

[JohnPapa]

Please look at the attachment. I have managed to not show the hidden tables even though the "Show Hidden Objects" is checked, but the names of the tables appear on the right.

 

[isladogs]

@JohnPapa
As you are probably aware, there are 3 methods of hiding tables in Access, each of which has a different effect
a) Hide in this Group
b) Hidden Property
c) Deep hidden (dbHiddenObject attribute)

Your screenshot indicates you have used method c)
Be aware that anyone knowing the table names can write a query to make the contents of those tables visible

Anyway, attached is a very simple 32-bit ACCDE file with 2 deep hidden tables one of which (tblDeepHide) can be made visible on a button click.
That table contains one field & one record and the data has been made read only.

There is another deep hidden table if you want to try & make that visible as well. The data in the second table can be edited

I can make a 64-bit ACCDE if anyone wants that instead

 

[JohnPapa]

Yes, I used "dbHiddenObject"

tdf.Attributes = dbHiddenObject

My question is why do the table names appear on the right? Seems like a bug.

 

[JohnPapa]

Is the other table "tblMDS"?