Hi,

In DBISam, I used to have a passwords table for gaguing the rights of my
users. (Things like what areas of the application they could enter, what
menu's were available to them, etc - and even a image of their signature
that they could print directly onto documents by using their username
and password).

To handle this, I used to have a passwords table that held their user
rights, signature image, and obviously their username and password.

I assigned a password to my passwords table, so users couldn't just use
DBSys to view the passwords, or change their access levels. However, I
could go 'in the back door' using DBSys and make any modifications
necessary.

In EDB, I'm a little stuck on how best to achieve this. I notice an
option to 'Encrypt Table On Disk', but there's no option anywhere to
actually specify the password. Since I often access tables from my
application directly (originally through DBSys, and now I plan to
through ElevateDB Manager), I'm not sure on the best way to achieve this.

I was wondering if anyone has any suggestions on what is the best way to
handle this please?

Thanks & Regards

Adam.

Adam


>I was wondering if anyone has any suggestions on what is the best way to
>handle this please?

It depends on just how secure you want to make things.

1.
At the simplest level just use ElevateDB's built in Users and make sure you only grant administrator access to a favoured few (or none apart from yourself).

2.
Moving on from there you can add encryption in to make it more difficult. You then need to store the encryption key in a way that its not easily found (I have a nice system but I'm not posting it openly)

You can also encrypt the catalog making it a bit harder to break

3.
Next up is to have your own users table with whatever security you want have a public password (or multi level authorisation such as some banks use) with a computer generated bloody hard to type (it would be nice if we could come up with an un-typeable one) or guess password that is used for ElevateDB. The user then "logs in" using your system which in turn logs them in to ElevateDB using the same user ID and the invisible password.

Next for the user rights. Tim has built in some good stuff for database level control but I'm more interested in application level so I have a group scheme in place and a lot of my stuff is managed like

  Dialing1.Enabled := HHuac.IsAllowed(uacDialActions);
  CheckMailHeaders.Visible := HHuac.IsAllowed(uacGetEMailHeaders);
 if HHuac.IsAllowed(uacCreateReport) or HHuac.IsAllowed(uacPrintReport) then begin


So it depends on what level and type of access control you want. If its just at database level use the in-built stuff, if application level then use whatever you're using now or mix the two.

I'm sorry that its not massively helpful

Roy Lambert [Team Elevate]

Adam H

Roy is right that you can create USERS and ROLES in EDB, and use loads of other security measures as per his suggestions.

Another useful option to "partition off" part of the data of your system is to have more than 1 database.

UserDB: This is the main database with all your user data. You give users access to this.

AdminDB: A second DB, on the same session as UserDB, but with its own path & table content.

The tables on AdminDB still need to be encrypted etc., but I find it makes for a really useful separation of data I don't want users to mess with.

If you go 1 step further you can easily write a Delphi app which uses 2 totally separate EDBSessions. One of these can be pointing to data only you the programmer know about, it could even be on a remote machine.

Adam

>If you go 1 step further you can easily write a Delphi app which uses 2 totally separate EDBSessions. One of these can be pointing to data only you the programmer know about, it could even be on a remote machine.

But then you can't get those two sessions talking to each other if you ever need to.

Roy Lambert [Team Elevate]

Thanks Roy and Adam for your replies...

I'm talking about a Application level rights. In one of my applications
there are more than 70 individual 'allow/deny' options that can be
turned on or off per user. I don't think the built in feature will
assist me at that level, only at the database level. (Drops, Alters,
Edits, etc)...

Effectively it doesn't need to be majorly secure. I'm not writing
banking apps, thankfully. As such, I dont' want to overcomplicate
things either. The simpler, the better.

I basically just want to store data in one table that will only ever be
able to be viewable or edited by either the application, or myself. The
password protection on DBISam was perfect for this, but I'm trying to
find another way to do this in EDB.

> 1.At the simplest level just use ElevateDB's built in Users and make
sure you only grant administrator access to a favoured few (or none
apart from yourself).

Roy - are you saying that if I mark a table as 'encrypted' only an
Administrator can view that table through the EDBManager? (Yet I can
still access that table through my application, or have I misunderstood)

Cheers

Adam.

Adam

My app level stuff consists of groups stored in my config table. Here's one

--------------------------------------------------x-------x---x-----------------------------------------------------------------------------------------------------------------------------------------

basically a load of dashes with x where a function is allowed. I then have a slew of constants eg

uacNewCompany = 1;
uacCloneCompany = 2;

for those accesses I want to control. Then its a simple test

function THHuac.IsAllowed(sParam: integer): boolean;
begin
if (Privileged or (not GetCfgBool(cfg_UAchk))) then Result := True else if sParam < 1 then Result := False else begin
 if Length(uacs) > sParam
  then Result := uacs[sParam] = 'x'
 else Result := False;
end;
end;

function THHuac.CheckValidated: boolean;
begin
if FuehCpt <> nil then FuehCpt.Enabled := False;
Application.CreateForm(TCheckDialogForm, CheckDialogForm);
//  CheckDialogForm.Position := poDesigned;  - leave this in and it screws the display!!!!!!!
CheckDialogForm.Top := Mouse.CursorPos.Y;
if CheckDialogForm.Top + CheckDialogForm.Height > Screen.WorkAreaHeight then CheckDialogForm.Top := Screen.WorkAreaHeight - CheckDialogForm.Height;
CheckDialogForm.Left := Mouse.CursorPos.X;
if CheckDialogForm.Left + CheckDialogForm.Width > Screen.WorkAreaWidth then CheckDialogForm.Left := Screen.WorkAreaWidth - CheckDialogForm.Width;
if CheckDialogForm.ShowModal = mrOK then begin
 Result := Check = CheckDialogForm.Authority.Text;
end else Result := False;
CheckDialogForm.Free;
if FuehCpt <> nil then FuehCpt.Enabled := True;
end;

function THHuac.ACT(sParam: integer; const ForceTest: boolean): boolean;
var
IsCheckWanted: boolean;
begin
Result := IsAllowed(sParam);
if Result then begin
 if not GetCfgBool(cfg_IgnoreSecurityCheck, False) then begin
  if ForceTest then Result := CheckValidated else begin
   if sParam < 0 then IsCheckWanted := GetCfgBool(cfg_UtilsForceUA, True) else IsCheckWanted := GetCfgBool(cfg_UAchk, True);
   Result := (not IsCheckWanted) or CheckValidated;
  end;
 end;
end else MessageDlg('Your user access group does not allow this operation', mtInformation, [mbOK], 0); //oldversion
end;


The string gets set up for each user at logon.


>Roy - are you saying that if I mark a table as 'encrypted' only an
>Administrator can view that table through the EDBManager? (Yet I can
>still access that table through my application, or have I misunderstood)

Yes ..... and no <vbg>. If encryption is applied then EDBManager needs the encryption password to access the data. If you look at the ini file that controls EDBManager you'll find a couple of lines for each session

Local Encryption Password=elevatesoft
Remote Encryption Password=elevatesoft

If the correct encryption password isn't supplied NOONE can access the data. The encryption refers to how things are stored on disk. As an example I have both company and contact tables in my app. The contacts table is encrypted but the company one isn't so if I used a hex editor I could "read" the company table but not the contacts one.

For EDBManager if you set up the users with appropriate privileges then that's all they can do. Administrator by default gets everything so don't give regular users the rights to create a table. Then they're stopped either in EDBManager or your app. Inside your app you can of course switch user transparently backwards and forwards.

In my case all users get admin but I don't distribute EDBManager and I'm not about to tell anyone (apart from Tim) the encryption password.

Roy Lambert [Team Elevate]

Hi Roy,

Thanks again for your help, and your example. I'll need a bit of time to
get my head around the code you've just posted.

I guess what I'm struggling with at the moment is where the user details
are actually stored. You mention the config table. Is this just a table,
with a username (which the user logs on with to EDB) that it then
locates and assigns.

It looks like you use a very similar concept to what I do alternatively.
(Except my strings are either 1's or 0's, and not x's )


In regards to encryption - would I be fine in simply setting a password
for both my application, and also EDB Manager to the same. (Like
'myPassword' and have it global for all my applications.)

I figure this way it would allow me to view, but only me (or the
application), and get around anyone else who downloads EDBManager?

Also - Am I correct in assuming if I want to change the password at a
later date, I can simply turn off enable encryption, then change the
password in the config file, and then re-enable encryption again?

Cheers

Adam.

Adam

>I guess what I'm struggling with at the moment is where the user details
>are actually stored. You mention the config table. Is this just a table,
>with a username (which the user logs on with to EDB) that it then
>locates and assigns.

The config table I refer to is a standard ElevateDB table which I use to store all of the application level (as opposed to user level) settings.

>It looks like you use a very similar concept to what I do alternatively.
>(Except my strings are either 1's or 0's, and not x's )

Well I thought of that but I always like to take account of human viewing of data as well as the computer and --x-x-- is easier than 0010100 as far as my eyeballs are concerned (its also the reason I HATE null <> emptystring)

>In regards to encryption - would I be fine in simply setting a password
>for both my application, and also EDB Manager to the same. (Like
>'myPassword' and have it global for all my applications.)
>
>I figure this way it would allow me to view, but only me (or the
>application), and get around anyone else who downloads EDBManager?

It will as long as no one else guesses the encryption password. Remember this has to be given to the engine/session in your app so it will have to be stored somewhere (the sneakier the better).

>Also - Am I correct in assuming if I want to change the password at a
>later date, I can simply turn off enable encryption, then change the
>password in the config file, and then re-enable encryption again?

Sorry - no its not that simple - from a 2009 post

---------------------------------------------------------------------------------
Roy,

<< I'm about to add encryption into an app. From reading the newsgroups,
manuals and looking at EDBManager it seems easy enough unless some pleasant
person downstream wants to change the password. My thoughts are that it
would involve reverse engineering with data and running the sql generated.
Is there another way? >>

No, that's the easiest way.

Tim Young
Elevate Software
www.elevatesoft.com
-----------------------------------------------------------------------------------------

This may have changed and I may have missed it.

Essentially think of the encryption password as a gatekeeper into the app. Without it no one can open the tables. Individual tables can then have that password applied or removed. In my app I have a form for users to enable/disable encryption only about 20% are encrypted as standard - those that contain personal or sensitive data.


Roy Lambert [Team Elevate]

Adam,

> Also - Am I correct in assuming if I want to change the password at a
> later date, I can simply turn off enable encryption, then change the
> password in the config file, and then re-enable encryption again?

I talked about that with Tim quite often and asked him to simplify that
- at the moment it seems that he has not the time to change something.

To change the password, this should work:

Note that the password is stored in the edbmgr ini-file like Roy already
mentioned.
Use the config-file only for your encrypted database.

1. Disable the encryption of all tables.
2. Delete the config-file.
3. Create a new session (thus a new config-file), but do NOT open it.
4. Edit the edmgr ini-file and change the password(s) to the desired
value(s).
5. Open the session.
6. Create a new database and connect it to the folder that contains your
(unencrypted) tables.
7. Encrypt the tables again.

Regards Uli

Uli

>1. Disable the encryption of all tables.
>2. Delete the config-file.
>3. Create a new session (thus a new config-file), but do NOT open it.
>4. Edit the edmgr ini-file and change the password(s) to the desired
>value(s).
>5. Open the session.
>6. Create a new database and connect it to the folder that contains your
>(unencrypted) tables.
>7. Encrypt the tables again.

I haven't tried that. Have you? If you're right its something that would be easy enough to do programmatically.

Roy Lambert