Access 2002 Security

[jamjar]

Hi,

I'm developing an HR database with user level security. Trouble is I seem to be able to crack the user codes using a utility called Access Password (even after conversoin to an mde). Yet we have an OTS application in mde format which the utility does not seem to be able to crack. How come? How do I modify my databse to be uncrackable?

I see Gary Robinson has a book which purports to describe how to make a database secure - if Gary or anyone else can assure me it will protect against users with password-cracking programs, I'll gladly buy it to find out how! I would guess all mdw files are decipherable by these utilities, but then how is the commercial mde file I have protected?

cheeres and TIA-
James

[MMcCarthy]

Hi James

Check out this webpage. It has pretty comprehensive information on Access Security.

http://www.jmwild.com/Accesssecurity.htm

Mary

[jamjar]

Thanks Mary.

I used the Microsoft SecFAQ instructions and have user IDs and security established with a FE/BE set up that seems to be working properly. But I the Access Password utility I downloaded lets anyone discover the accounts along with the PIDs and passwords for a given mdw file.

Jack McDonald's white paper concludes I shouldn't be using Access if I am concerned about hackers cracking the mdw file. Anybody disagree?

James

[MMcCarthy]

I've asked some of the other experts to look in with their opinions James.

[Denburt]

O.K. James you crack utility does it specifically ask where the mdw file is or just the MDE file?

You can change the name of the MDW to something like ThisWillReforma t no extension or anything then bury it deep within your system files. I know there are a lot of things you can do, it has been a while so I will try and think of more things that can be done.

Hope that may help

[Rabbit]

The reason that program can crack the .mdw file is while the .mdw file is encrypted, it is always laid out in a certain format. So, they unencrypt the file, and they're all set with the passwords.

What an mde is is a compiled version of all the code. This means you can't edit the code. Here's why the program can't crack an mde. It uses code to implement a security protocol. As such it is all done through code. By compiling the code, you can no longer see how it checks the password. An mde is no where remotely laid out like an mdw. And then there's the matter of all the other code that exists aside from the security code. What this results in is a different result for every mde assuming different coding or objects in the mde.

The only then to crack the password in an mde, as I understand it (I'm not security expert), would be to use a hex editor and to go through all the compiled code and try to understand what it does and to find the section of the code that is checking the password. Quite an undertaking in any sufficiently coded mde.

[NeoPa]

Surely though Rabbit, the MDE file still needs to gain access (small a) via the MDW file. It is there that the security details are kept, so surely there that is vulnerable. No benefit that I can see for 'compiling' the project into an MDE.

Jack McDonald's white paper concludes I shouldn't be using Access if I am concerned about hackers cracking the mdw file. Anybody disagree?

No, I can't really disagree with the statement.
Others may do, and even prove me lacking in understanding, but I can't see that this is easily got around.

[jamjar]

Thanks again for the responses.

To clarify my goal: I'm trying to protect against (say) a read-only user finding out a higher level userID/password and logging on to perform unauthorised queries and transactions. So the user will have read-write permissions on the database file, and the directory, and will know the file path and the file path for the mdw file (since it will be in the shortcut they use to open the database). And it is the data I am trying to protect more so than IP in the way of forms/codes.

The 'Access Password' utility relies upon user specifying the mde/mdb/mdw file. I was thinking of revoking List Files permissions as it is normally selected by GUI, but the file name can be typed in also. When selecting an mdb/mde, it reveals the userID and PID for object owners, and when an mdw is selected it reveals the userIDs/passwords.

A key point I forgot re. the 3rd party mde I have which the utility can't crack: it doesn't have user-level security; it is internal somehow. Of course, I can't read the forms and modules, but I can read the tables. There are a couple with UserID/passwords listed, but I can't get them to work, and I can't find where the password I use is listed, so I assume the security is buried in the code.

I think I could bury passwords in the code as well, with different passwords for different users that align with the highest permission group to which they belong, so that even if a low-level user cracked the mdw userIDs/passwords they would still be kicked out if they couldn't provide a second password that is encrypted in the code.

BUT
a) this would not be very easy to administer (no flexibilty without code changes and re-encryption), AND
b) couldn't a user who had hacked a higher userID could just link to the tables from a new mdb!?

Is there a way of hiding the mdw file from the shortcut and calling it out via some encrypted code? Storing it in an unguessable directory with an unguessable name and extension?

Would that be sufficient, or if the 'Access Password' utility can supply the owner's PID from the mde file, could a new mdw be created and used to open with owner's permissions, and all security revoked?

cheers-
James

[Rabbit]

Surely though Rabbit, the MDE file still needs to gain access (small a) via the MDW file. It is there that the security details are kept, so surely there that is vulnerable. No benefit that I can see for 'compiling' the project into an MDE.
No, I can't really disagree with the statement.
Others may do, and even prove me lacking in understanding, but I can't see that this is easily got around.

Not necessarily. I'm talking not using an mdw at all and coding your own log in form and do it all through code.

[NeoPa]

Not necessarily. I'm talking not using an mdw at all and coding your own log in form and do it all through code.

Oh, that makes sense Rabbit. I'd missed your point somewhat.

Jamjar,
I don't think that you can do what you propose as the MDW file is associated with the setup of each individual PC rather than being database related.
As in previous post, I think Access simply doesn't give strong support for this stuff. Almost anything is possible with code, but making a db inaccessible from other DBs particularly, would be difficult.

[Rabbit]

It would be convoluted but to get around someone linking the table you could have an extra field that is filled by some sort of encryption algorithm for each entry made into the table. This way, since the code is compiled in the mde they wouldn't know how the field was encrypted and the database could delete all records where the field isn't properly encryted.

[Denburt]

Is there a way of hiding the mdw file from the shortcut and calling it out via some encrypted code? Storing it in an unguessable directory with an unguessable name and extension?

I had a project a few years back as I mentioned earlier where I was able to do this but to provide an example of it I am at a loss. I have since over the last few years tried to reopen it examine it etc. unfortunately I used the developers edition of access to deploy my project and I no longer have the program used, I also did not keep enough notes... If I EVER manage to get back into this database I am sure I can figure it out but I can't remember the password or the place I stored the mdw since it was renamed and relocated during deployment.

I did some searching and found an interesting link however I could only find it in googles cache and after a couple of tries I am still exploring the possiblities of it's use. I think this may help resolve your issues so I will post it and see what you think. I also found that I could only access the cached version of this page through my firefox browser I.E. won't let you view it. Hmmmmmm

O.K. i will post a snipet of what I was trying.
Dim wsShell As New WshShell
Dim dbe As PrivDBEngine
Dim wrk As Workspace
Dim dbs As Database
Set dbe = New PrivDBEngine
DskTop = wsShell.Special Folders("Deskto p")
dbe.SystemDB = DskTop & "\123.mdw"
Debug.Print DskTop & "\123.mdw"
dbe.DefaultUser = "BasicUser"
dbe.DefaultPass word = "MyPass"
Set wrk = dbe.Workspaces( 0)
Debug.Print Application.Cur rentProject.Pat h
Set dbs = wrk.OpenDatabas e(Application.C urrentProject.P ath & "\MyDb.mdb" )


<Remove Link>

If i find anything else out i will let you know.

[Denburt]

Ah thanks to some wonderfull site called http://www.thescripts.com I was able to find a link:

PrivDBEngine

[ADezii]

Hi,

I'm developing an HR database with user level security. Trouble is I seem to be able to crack the user codes using a utility called Access Password (even after conversoin to an mde). Yet we have an OTS application in mde format which the utility does not seem to be able to crack. How come? How do I modify my databse to be uncrackable?

I see Gary Robinson has a book which purports to describe how to make a database secure - if Gary or anyone else can assure me it will protect against users with password-cracking programs, I'll gladly buy it to find out how! I would guess all mdw files are decipherable by these utilities, but then how is the commercial mde file I have protected?

cheeres and TIA-
James

I developed a similiar Project, one in which Security was a prime concern. What I did was to simply implement a 2nd Level of Security in which the User, after entering the Access User Name and Password, had to enter an 'Entry Code' in order to access the Database. This is totally independant of any System.mdw. I compiled the Project into an *.mde, and stored the 'Entry Code' in either the System Registry or internally in an Access Table in an encrypted format. This tiny inconvenience of an additional prompt was well worth the peace of mind that it afforded. Should anyone crack the User Name/Password, they still would have to by pass the encrypted 'Entry Code'.

[NeoPa]

Did you stop access via a linked table if the password had been cracked?