Best security login function
- Thread starter jedder18
- Start date
- Local time
- Today, 13:32
- Joined
- Feb 28, 2001
- Messages
- 30,562
The question isn't Win7 vs. WinXP vs. Win98. It is FIRST, how do they log in? If through an authenticating domain controller system with LDAP, then you can make calls to determine who logged in.
Failing that, you need to look into some sort of hashing algorithms using one of the security DLL files that you reference (as in, from the VBA window, follow Tools to References and check the appropriate library) so that you can encrypt or hash the user's passwords and do the equivalent of a Purdy algorithm. You ask for a username and a password, but you never store the real password. You store the hash/encryption thereof. Then at next attempt to login, you take the username and the input password to generate the hash again and compare hashes.
Either with a trusted authentication server scheme such as domain login, or when you "roll your own" as I described, THEN you can decide to whom you are speaking and can identify your user.
Once you have that, you need to assign a code number (could be just an autonumber based on a table of authorized users). If each user's records are unique and NEVER overlap, you include the record's owner as a field in the table. Then as stated previously, never show anyone any record not marked as belonging to them.
But here is what else you need to know: This goal to limit what each person sees also means you must NEVER EVER let the world see your underlying tables. Show everyone forms that cannot be seen in design mode, only in form view. Put your record-limiting filters in that form. Because the moment your users see the objects of the database directly, you have zero point zero zero privacy. I.e. there IS no security at that point.
Failing that, you need to look into some sort of hashing algorithms using one of the security DLL files that you reference (as in, from the VBA window, follow Tools to References and check the appropriate library) so that you can encrypt or hash the user's passwords and do the equivalent of a Purdy algorithm. You ask for a username and a password, but you never store the real password. You store the hash/encryption thereof. Then at next attempt to login, you take the username and the input password to generate the hash again and compare hashes.
Either with a trusted authentication server scheme such as domain login, or when you "roll your own" as I described, THEN you can decide to whom you are speaking and can identify your user.
Once you have that, you need to assign a code number (could be just an autonumber based on a table of authorized users). If each user's records are unique and NEVER overlap, you include the record's owner as a field in the table. Then as stated previously, never show anyone any record not marked as belonging to them.
But here is what else you need to know: This goal to limit what each person sees also means you must NEVER EVER let the world see your underlying tables. Show everyone forms that cannot be seen in design mode, only in form view. Put your record-limiting filters in that form. Because the moment your users see the objects of the database directly, you have zero point zero zero privacy. I.e. there IS no security at that point.
