Feedback requested on my security mod

[irish634]

Hi Everyone,

I've been working on this for a while now and I think I am at the point where I am ready to have it tested. So I am asking you guys/gals to shoot some holes in this so I can correct them.

Attached is my security mod / login. I believe it's more for keeping most users at bay and being able to see who is logged in and using the db. There will also be an audit trail added later.

There are two users in the DB.

1. Tom Smith (PW: default) - has full control level access
2. John Doe (PW: default) - has Read/Add/Edit level access

I know it's taboo to hard code Users and PWs but as a fail-safe I hard-coded the user "Administrator" with PW = "Administrator" So, you can use that as well.

One thing on the log in form is "Request User Access" - In this if any user in the DB has the Yes/No admin box = true, then they will get the email request as long as they have an email stored in the DB. If no admins are in the User List, the requester will be prompted to enter an email address for an admin. Ideally as this is being used, there will be a designated admin or two.

For now, I allow the admin to enable the bypass key, though I am debating on getting rid of the feature as I allow the admins to toggle the db window.

I also plan to use MDE files and split the DB, but this is for testing. I would use an AutoExec macro, but I noticed Access 2007 is finicky about that. I want this to be valid accross most platforms.

A few questions I have:
I have developed this in Access 2000. I have tested in Access 2003 and 2003 runtime. I've also tested in 2007 runtime. What I have noticed:

1. In the runtime versions, the db window can't be shown. Is this a feature of runtime?
2. I disable the "X" and close features. However, in 2007 runtime, the "X" is still active. Does anyone have an idea how to disable it? For users with 2007, is the "X" enabled when you log in?

Anyhow, those are some of the initial questions I have and I am sure I'll have some more as you guys find my errors and holes.

Please let me know what you think, if you get any errors, and what flaws this has. Also, please let me know if you have any ideas how I can improve this.

I appreciate any feedback you can give.
Thank you,
Craig

 

[Atomic Shrimp]

I know it's taboo to hard code Users and PWs but as a fail-safe I hard-coded the user "Administrator" with PW = "Administrator" So, you can use that as well.

You're not planning to leave that in the application when you release it, are you?

In the runtime versions, the db window can't be shown. Is this a feature of runtime?

Yes. It's one of the limitations of the runtime.

 

[irish634]

You're not planning to leave that in the application when you release it, are you?

Probably not. I know it's too easy to discover/figure out.

Yes. It's one of the limitations of the runtime.

Thank you

 

[HiTechCoach]

In the runtime versions, the db window can't be shown. Is this a feature of runtime?

If you allow the database windows at allow, it will be very easy to get past your security. That is why I force all my apps to be in "runtime mode".

Why are hard coded passwords any easier to figure out? If you are using an MDE, they are a lot more secure hard coded that using a table unless you encrypt the data in the table.

Hardcoding the back door is probably a good idea. You just need to use a "stonger" password and a different user name so that it is not so easy to guess.

 

[HiTechCoach]

I disable the "X" and close features. However, in 2007 runtime, the "X" is still active. Does anyone have an idea how to disable it? For users with 2007, is the "X" enabled when you log in?

I have found this is not a good idea. Especially in the runtime environment.

FYI: Because you do this, I will NOT download and test your database. IMHO, It is to unsafe.

 

[Atomic Shrimp]

Why are hard coded passwords any easier to figure out? If you are using an MDE, they are a lot more secure hard coded that using a table unless you encrypt the data in the table.

Hardcoding the back door is probably a good idea. You just need to use a "stonger" password and a different user name so that it is not so easy to guess.

That was what I meant too (should have been more explicit) 'administrator' is a fairly obvious password, the backdoor itself is probably OK with a strong password.

 

[irish634]

I have found this is not a good idea. Especially in the runtime environment.

FYI: Because you do this, I will NOT download and test your database. IMHO, It is to unsafe.

Can you elaborate a little as to why it might be unsafe? I assume it's because of the potential to have it migrate to the application?

What other methods of not allowing "X" can you suggest that would force users to use the menu I've created?

Thank you

Also - Here is the app with that code disabled if you wish to have a look.

 

[Banana]

Why are hard coded passwords any easier to figure out? If you are using an MDE, they are a lot more secure hard coded that using a table unless you encrypt the data in the table.

With apologies, I should point out that this is not necessarily correct. Constants, string assignment and such are still read-able plaintext if the database is open in notepad. So this code block:

If MyPwD = "foo" Then
   '<Give administrator access>
End If

would be read thus in the notepad when converted to MDE:

<lot of gibberish> f o o<some more gibberish>

IMHO, if we are to roll out DIY security (and in general I don't really like to do that- it's much easier to fool ourselves than it is to actually secure it), the correct answer should be that password should be never stored at all. Use some kind of algorithm to resolve the password at runtime so the user always has to supply the missing components to get it running at all. Thus if a copy is stolen, they can't get anywhere because the missing piece is nowhere to be found in the MDE.

HTH.

PS It's another reason why I'm not so a big fan of using built-in encryption- to encrypt the data, we need key. Except that Microsoft decides to not ask us to fill in key but rather creates a key then bury it in the MDB/MDE. Analogous to putting your key under the doormat; the burglar only needs to know where to look so he can let himself inside at leisure.

 

[irish634]

IMHO, if we are to roll out DIY security (and in general I don't really like to do that- it's much easier to fool ourselves than it is to actually secure it), the correct answer should be that password should be never stored at all. Use some kind of algorithm to resolve the password at runtime so the user always has to supply the missing components to get it running at all. Thus if a copy is stolen, they can't get anywhere because the missing piece is nowhere to be found in the MDE.

That makes very good sense. I'm sure there are examples so I'll do some digging and try my hand at that too.

Something to point out, is most users utilizing this initial project aren't that savvy "programmatically" speaking. So if I can restrict them to most of the items that can be found by googling I should be ok. However I don't want the security to be "just OK". My goal is to make it difficult for most anyone to get into (tall order I know) and try to secure the data.

As with anything, I am sure there will be a way around it in one form or another. I just have to minimize it and try to protect the data. So If I can make the security so that someone "really has to know what they are doing" to get into it, and most other users get frustrated and call me some not so nice names because of my security, then I think I've done ok.

 

[HiTechCoach]

Can you elaborate a little as to why it might be unsafe? I assume it's because of the potential to have it migrate to the application?

What other methods of not allowing "X" can you suggest that would force users to use the menu I've created?

Thank you

Also - Here is the app with that code disabled if you wish to have a look.
View attachment 25251

I just create a form level global variable on a the form like:

bolOKtoClose as Boolen

then in the form's UnLoad event use:

Private Sub Form_Unload(Cancel As Integer)

If Not bolOktoCLose Then

   Cancel = True

End If

End Sub

To be able to close the form you must set bolOKtoClsoe to true

So in your "Exit" command button use:

    bolOKtoClose = True

    DoCmd.Quit  ' or could be changed to just close the form

Note: You do not have to initialize the value of bolOKtoCLose to false or 0 since it will have this value by default.


I do this on the main switchboard form so the user can not exit even Access without using your command button

 

[irish634]

I see.
I'll give that a whirl too. It also sounds like a better idea than disabling the close button. Thank you.

I just create a form level global variable on a the form like:

bolOKtoClose as Boolen

then in the form's UnLoad event use:

Private Sub Form_Unload(Cancel As Integer)

If Not bolOktoCLose Then

   Cancel = True

End If

End Sub

To be able to close the form you must set bolOKtoClsoe to true

So in your "Exit" command button use:

    bolOKtoClose = True

    DoCmd.Quit  ' or could be changed to just close the form

Note: You do not have to initialize the value of bolOKtoCLose to false or 0 since it will have this value by default.


I do this on the main switchboard form so the user can not exit even Access without using your command button

 

[Banana]

Not only that, but also this is much more consistent with other applications' behaviors which your users may inconspicuously expect.

If your users don't see a close button they will just give your application good old three-fingered salute and you'd be worse off. Boyd's method works nicely and allows you to display a messagebox warning that it cannot be quit at this point without frustrating your users.

 

[irish634]

Ok... Consensus thus far is that it's not a good idea to disable the close button. I'm scrapping the idea in favor of Boyd's solution. So that is added to my to do list.

Also if I am to keep the "back door" I need to make it a little tougher.

Anyone have any other input?

Thanks
Craig

 

[Banana]

Just one question, though. I just noticed this is for a .MDB, not a .ACCDB. Why do you feel that this should be used instead of User-Level Security? As I noted earlier, I would generally avoid any DIY security solution except for cases there there is a compelling reasons (and usually they're few and far between, IMHO). Even if it's just a mechanism to manage permissions and providing an audit trail, rather than literal security, ULS would be easier to implement and far less bug-prone.

 

[irish634]

Just one question, though. I just noticed this is for a .MDB, not a .ACCDB. Why do you feel that this should be used instead of User-Level Security? As I noted earlier, I would generally avoid any DIY security solution except for cases there there is a compelling reasons (and usually they're few and far between, IMHO). Even if it's just a mechanism to manage permissions and providing an audit trail, rather than literal security, ULS would be easier to implement and far less bug-prone.

I don't have Office 2007, so I am unable to create in .accdb format. Using ULS is indeed an option, I do use that as well with pretty good success, as long as I am the admin. I am just honing my development skills on this. Not to mention, in this case, the project will be turned over to "database admins" and I will be for "development support" only. Not knocking these "admins" but I find with this group, I would be called everytime a user needed to be changed, added, etc. It's more of a training issue than anything else really.

I do understand what you are saying though and I agree.

BTW, I read that .ACCDB does not support ULS?

 

[Banana]

Actually, .ACCDB is 2007 format, but you're using .MDB which supports ULS. If you were using .ACCDB, then DIY security is understandable, but if you're using .MDB, why not use ULS?