Important security issue - security hole in Access

[alfalf]

Hello all.

Recently I run into two mda files on Internet (will not mention names), free to download from legal site (will not mention name).

Those "Add-ins" are: one for viewing database password and other for viewing user's passwords from system.mdw file.

And, really, when I used "add in" for viewing user's pwds from system.mdw file -> VOILA! All usernames & passwords have been revealed!

Situation with other "add-in" (that reads database password) is different, as I use Acc2000 & my dbs are encrypted, the add-in couldn't correctly read my db password for any of selected db.

Therefore conclusion -> so much about security going on in Access. I posted two threads concerning security of Access databases (with wich I work since Version 1.0), and must say am completely devastated with my latest findings.


LITERALY, ANYONE CAN SEE USERNAMES & PASSWORDS.

But, here's very important conclusion concerning security to all access & VBA programmers:

1. USE ONLY PASSWORD FOR PROTECTION OF DATABASE
(As db passwords cannot be properly read with any of tested "add-in", and therefore CANNOT BE missused)
2. DO NOT USE INTEGRATED USER & PREMISSION SECURITY TOOL!!!
(Do not make user accounts and give them passwords as those can be EASILY viewed by any in Your company or wherever)
3. BECAUSE YOU'LL USE ONLY DB PASSWORD TO PROTECT DATA, DO NOT LINK TABLES FROM PWD PROTECTED DB!
(As from my previous thread about import/security, it's obvious that anyone can compromise that too!)
4. BUILD YOUR OWN SECURITY SYSTEM AND CUSTOMIZED LOGIN
(Make an additional pwd protected db, store pwds there, and use Code to reach that db and pwds stored).
5. ENCRYPT.

DO NOT DOUBT ANY MINUTE ABOUT THIS ISSUE.


For more help ask.
DB

 

[Ed2020]

Are you really suggesting that a simple database password provides better protection than user level security?!

How do you suggest developers restrict design view access then?

Ed.

Please do not feed the trolls.....

 

[alfalf]

No. I don't suggest only that.

As I experimented with every aspect od Access (2000) Security, for days now, I found out that there's a lot of holes and issues concerning Access Security. Practicaly every Access (97/2000) built in security option is easily breached (by third-party maliciusware). I tested various procedures (and add-ins) to read db password. At least 3 different codes. No one have read password database correctly (no matter when I combined different Access Sorting Language options), while only one "add-in" read usernames and passwords from users accounts stored in system.mdw.

That's why I concluded that Users Premissions are not sufficient, at least speaking, if You use only that, aren't at all.

All I want to say to all other programmers is, that all should use completely different concepts of data protection in Access 97/2000, wich, regreting me to say, isn't none of built-in security options Access standalone, or even in combination.

Look, db password can be sniffed (not read, but who knows, perhaps there's code to read it properly), usernames & passwords are prooven to be easily viewed. What a hacker wants more?

So what is left to protect data (code is successfully protected with mde format)?

1. Is to use another database server technolgy (MSSQL for example, and inherit Server Security Settings), or
2. If still want to use Access 97/2000, there have to be used an trick with self produced system.mdw workgroup info file wich is different for different mashines (copies of Access). The trick is to make customized system.mdw for Your application (users, pwds, premissions) on one mashine, and then deploy THAT application without system.mdw to other mashines. As others have their own system.mdw file wich differs from Yours, and since Your workgroup information file was left on Your mashine, noone can read it's usernames and passwords and cannot see/alter design of tables/queries and directly alter data (only through forms in compiled mde distribuiton copy). THAT IS THE ONLY SUFFICIANT PROTECTION. (Yet, only for deployment!). For developement stage I still haven't figured it out, except to be completely disconnected from network.

Finaly, point is that common knowledge of security in Access 97/2000 could lead people to think that built-in protection is sufficiant. It's not. I see a lot of people on Internet's Forums getting in trouble because someone changed their access passwords (db's or user's). And their panic or even job loss. Because they thought offered way of protection is sufficiant. In MS Access Help file Topic User Object, there's statement that says: "You can't return the PID and Password properties of an existing User object", wich is False Statement! One can, easily, it's proven.

That's what I tryed to say. If You, or anyone else want this trick I found - how to manage Acc 97/2000 (or 2002/2003, wich is a bit different, since in them security improved) Security without Login (and for distribution of Your mde application without defined premissions workgroup information (e.g. system.mdw)), as I don't know if here are allowed email addresses, I will gladly share it. Or even post it here, if administrators of this site agrees.

Thats that.
DB