DelphiRulez
asked on
Delphi application Logon Account security ?
I have an application that on its "First Run" checks the registry for a FirstRun (boolean) value and also checks a database for the existance of a SysAdmin user account in the users table.
If neither of these two exist, the user is prompted to create a sysadmin (userId & password) account, before the application will run. The new user account is stored in the users table with a user type of "SysAdmin". I allow two other user types (Admin, User), each with their own specific roles. Only one SysAdmin account can be created and its created at "First Run". If the SysAdmin account is sussfully created at first run then the registry value FirstRun is created in the registry and set as true.
Once a user of type SysAdmin is logged into the system, they can later change the password via the System Administration Panel.
If either the FirstRun registry value or the SysAdmin user account DO NOT exist, then the application terminates, and the FirstRun value in database is never created (does not exist).
Question 1: Do I really need the First Run value in the database, Im thinking that i just need to check the existence of the SysAdmin user account in the users table.
Question 2: Would you implement it in a different manner? If so, how?
If neither of these two exist, the user is prompted to create a sysadmin (userId & password) account, before the application will run. The new user account is stored in the users table with a user type of "SysAdmin". I allow two other user types (Admin, User), each with their own specific roles. Only one SysAdmin account can be created and its created at "First Run". If the SysAdmin account is sussfully created at first run then the registry value FirstRun is created in the registry and set as true.
Once a user of type SysAdmin is logged into the system, they can later change the password via the System Administration Panel.
If either the FirstRun registry value or the SysAdmin user account DO NOT exist, then the application terminates, and the FirstRun value in database is never created (does not exist).
Question 1: Do I really need the First Run value in the database, Im thinking that i just need to check the existence of the SysAdmin user account in the users table.
Question 2: Would you implement it in a different manner? If so, how?
ASKER
8080 Driver:
>>>•What is the database that you are using?
Not sure why this is relevant?
>>>•Are you creating the database during the process of installing the app?
No!
>>>•Are you installing an empty version of the database at the time the app is installed?
Yes!
>>>•Does the user really need to know the SysAdmin username and password? \
They don't! What leads you to believe that? Did i mention something that made you think that?
>>> Permissions
I dont have as an elaborate system as you, therefore, i have a less elaborate permissions scheme.
I have three types of users (SysAdmin), (Admin) and (User).
SysAdmin has access to everything, including system admin account, system options, user management, ect. I wont explain the other two levels, lets just say that they have much less access.
When the program starts for the first time, there is an empty database (Completely empty). The program goes to the registry to see if this is the first run and checks the database for a user whos type is sysadmin. If it is the first run and there is no user account for sysadmin, then the user is prompted to create a sysadmin account. After the account is created, the system starts up, and the user can log in using the sysadmin credentials and configure the system, add users, etc.
>>>•What is the database that you are using?
Not sure why this is relevant?
>>>•Are you creating the database during the process of installing the app?
No!
>>>•Are you installing an empty version of the database at the time the app is installed?
Yes!
>>>•Does the user really need to know the SysAdmin username and password? \
They don't! What leads you to believe that? Did i mention something that made you think that?
>>> Permissions
I dont have as an elaborate system as you, therefore, i have a less elaborate permissions scheme.
I have three types of users (SysAdmin), (Admin) and (User).
SysAdmin has access to everything, including system admin account, system options, user management, ect. I wont explain the other two levels, lets just say that they have much less access.
When the program starts for the first time, there is an empty database (Completely empty). The program goes to the registry to see if this is the first run and checks the database for a user whos type is sysadmin. If it is the first run and there is no user account for sysadmin, then the user is prompted to create a sysadmin account. After the account is created, the system starts up, and the user can log in using the sysadmin credentials and configure the system, add users, etc.
>>>•What is the database that you are using?
Not sure why this is relevant?
Well, some database have to have a SysAdmin user and password defined when they are created and some don't. For instance, if you are using MS Access, then the universal dtabase access with Admin and a blank password tends to come with the package when you create the database.
>>>•Does the user really need to know the SysAdmin username and password? \
They don't! What leads you to believe that? Did i mention something that made you think that?
The following is a quote from your original post:
the user is prompted to create a sysadmin (userId & password) account, before the application will run
That sure sounds like they would know the SysAdmin userid and password . . . I know I would write it down. ;-)
>>>•Are you installing an empty version of the database at the time the app is installed?
Yes!
In that case, why don't you set the SysAdmin userid and password and then just use it rather than making the user set those? :-/
When the program starts for the first time, there is an empty database (Completely empty).
As in, "no tables, no nothing" empty or as in "no users defined" nothing? As I said, my sstem is going to be shipping without a database but the installation process is going to create an essentially empty database (i.e. no data in the tables, for the most part) but the installation will set up the actual sysadmin account and some auxilliary tables that have "common knowledge" data in them.
Actually, for the most part, my app is going to have a SysAdmin (inaccessible to the users), one or more Admin users, and, potentially, a set of users that will have what might be thoguht of as "deptartment level" restrictions. I just turn on and off menu items based on ANDing the user Permission with a Tag value. ;-) Because there are several menuitems, I find it easier to just cycle through them, ANDing each of their Tag values with the user's Permissions setting and enabling the menuitems by setting their Enabled property to something like the following:
TMenuItem(ThisMenuItem).En
If the Tag is 8 and the User Permissions is (8 + anything), then that statement is True but if 2^3 is not part of the permissions value, then it is False. Your system could hanlde that with:
const
SYSADMINPERMISSION = 4;
ADMINPERMISSION = 2;
USERPERMISSION = 1;
GUESTPERMISSION=0;
This would let you set your SysAdmin Only tags to 4, your SysAdmin and Admin tags to 6, and your SysAdmin, Admin, and User tags to 7. Then you set the UserId permissions to either SYSADMINPERMISSION, ADMINPERMISSION, USERPERMISSION, or combinations of them (e.g. SYSADMINPERMISSION + ADMINPERMISSION + USERPERMISSION for the SysAdmins).
The nice thing is that if you decide to get more complex later on, you have the mechanism in place for doing so. ;-)
Not sure why this is relevant?
Well, some database have to have a SysAdmin user and password defined when they are created and some don't. For instance, if you are using MS Access, then the universal dtabase access with Admin and a blank password tends to come with the package when you create the database.
>>>•Does the user really need to know the SysAdmin username and password? \
They don't! What leads you to believe that? Did i mention something that made you think that?
The following is a quote from your original post:
the user is prompted to create a sysadmin (userId & password) account, before the application will run
That sure sounds like they would know the SysAdmin userid and password . . . I know I would write it down. ;-)
>>>•Are you installing an empty version of the database at the time the app is installed?
Yes!
In that case, why don't you set the SysAdmin userid and password and then just use it rather than making the user set those? :-/
When the program starts for the first time, there is an empty database (Completely empty).
As in, "no tables, no nothing" empty or as in "no users defined" nothing? As I said, my sstem is going to be shipping without a database but the installation process is going to create an essentially empty database (i.e. no data in the tables, for the most part) but the installation will set up the actual sysadmin account and some auxilliary tables that have "common knowledge" data in them.
Actually, for the most part, my app is going to have a SysAdmin (inaccessible to the users), one or more Admin users, and, potentially, a set of users that will have what might be thoguht of as "deptartment level" restrictions. I just turn on and off menu items based on ANDing the user Permission with a Tag value. ;-) Because there are several menuitems, I find it easier to just cycle through them, ANDing each of their Tag values with the user's Permissions setting and enabling the menuitems by setting their Enabled property to something like the following:
TMenuItem(ThisMenuItem).En
If the Tag is 8 and the User Permissions is (8 + anything), then that statement is True but if 2^3 is not part of the permissions value, then it is False. Your system could hanlde that with:
const
SYSADMINPERMISSION = 4;
ADMINPERMISSION = 2;
USERPERMISSION = 1;
GUESTPERMISSION=0;
This would let you set your SysAdmin Only tags to 4, your SysAdmin and Admin tags to 6, and your SysAdmin, Admin, and User tags to 7. Then you set the UserId permissions to either SYSADMINPERMISSION, ADMINPERMISSION, USERPERMISSION, or combinations of them (e.g. SYSADMINPERMISSION + ADMINPERMISSION + USERPERMISSION for the SysAdmins).
The nice thing is that if you decide to get more complex later on, you have the mechanism in place for doing so. ;-)
ASKER
Now that you mention it, I am using MS Access. I have a password that is used to connect to the MS ACCESS database. It is unknown to the users. Again, not relevant here, since I am refering to user logo accounts to a database that is already connected to my app.
I think you are reading way too far into things here.
>>>"the user is prompted to create a sysadmin (userId & password) account, before the application will run "
Yup, thats my quote, but it says (and i repeat) "the user is prompted to create a sysadmin userid and password account"
Again, not sure where you think they already know SysAdmin userid and password.
You wouldn't write it down, cause you have no idea what it is.
1.) If you are refering to the actual admin database user name and password, it is not known to you. Only i know the info.
2.) If you are not refering to #1, then like i said, the database is empty, so therefor there is no sysadmin account yet! The first run user must create one.
>>>>>In that case, why don't you set the SysAdmin userid and password and then just use it rather than making the user set those? :-/
You are really not getting the point here.......
I wont get into a discussion about permission/roles/rights, etc, since it was not part of my original question.
I will assume that what I have done is correct (since it works just fine). I will also give time for others to comment.
I think you are reading way too far into things here.
>>>"the user is prompted to create a sysadmin (userId & password) account, before the application will run "
Yup, thats my quote, but it says (and i repeat) "the user is prompted to create a sysadmin userid and password account"
Again, not sure where you think they already know SysAdmin userid and password.
You wouldn't write it down, cause you have no idea what it is.
1.) If you are refering to the actual admin database user name and password, it is not known to you. Only i know the info.
2.) If you are not refering to #1, then like i said, the database is empty, so therefor there is no sysadmin account yet! The first run user must create one.
>>>>>In that case, why don't you set the SysAdmin userid and password and then just use it rather than making the user set those? :-/
You are really not getting the point here.......
I wont get into a discussion about permission/roles/rights, etc, since it was not part of my original question.
I will assume that what I have done is correct (since it works just fine). I will also give time for others to comment.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
- What is the database that you are using?
- Are you creating the database during the process of installing the app?
- Are you installing an empty version of the database at the time the app is installed?
- Does the user really need to know the SysAdmin username and password?
I have an app that i am working on that has a "gatekeeper" login that has extremely limited access to the database. About all it can do is validate a login. During the process of creating the database (which I do programmatically with DDL statements), an Admin account is created but the access it is given is only to certain stored procedures that let users be added and permissions granted to them.If you know about D&D or Unix systems, there is a "god-level" (SysAdmin) user who can do anything but the users are restricted from that one (that one is mine! ;-). The Admin user is a "demi-god level" user who has a lot of power but not total power. Other users are created by the demi-god and have no more (but usually fewer) powers than the demi-god that created them.
I keep the created users in a table which also contains a Permissions. My Permissions setting is a numeric value that indicates, via powers of 2, the various pieces of the system that the user can access. For example, even a permission of 0 can access the Aboutbox, the Exit button, and the LogIn menue selection; however, if the log in fails, those are still the only things that the User can access. (Permissions = 0 is sort of like a "Guest User" who can't do anything except try to log in or exit the app.)