Hi,

I'm currently developing my first EDB application, and was wondering if
someone could please give me some advise on how I should do the following:

In previous DBISam tables I have the occasional sensitive table that I don't
want people to be able to access or view from outside of my application.
(Such as a table storing a list of usernames, passwords, pin numbers, etc as
an example).

The application itself still needs full access to the table (to add, delete,
modify records, etc) but the users themselves should never be able to see
the data within these types of tables.

However, I do want to be able to allow users to be able to access other
tables directly using DBSYS.

In DBISam what I have done is encrypt the individual table, and then add the
password to the applications session on startup. This allows the application
full access to the encrypted table. This way uesrs can also use DBSYS to
view all tables externally form the application except for the sensitive
ones.

However in EDB it would appear as though encryption operates differently.
I've found an option to Encrypt the table on disk, but I'm not sure about
the best way to achieve the above. Does anyone have any suggestions?

Thanks & Regards

Adam.

Adam


I did have a thought but it wouldn't work if you need to reference encrypted and unencrypted tables in the same query.

You split the tables into two databases. One encrypted the other not but with all the tables in the same directory.Iin EDBManager don't give them the encryption password for the sensitive stuff.

The problem is that you'd need two sessions since the encryption password is either engine or session level but not database. Whilst you can reference the table's database in a query you can't reference the session.

Roy Lambert [Team Elevate]

Hi Adam,

It may not be the solution for you, but I encrypt certain information
prior to saving it to the EDB table. In other words, I don't use the EDB
encryption options, but selectively encrypt data in my application. It
ain't difficult, but it does let me 'hide' those passwords, codes, and
so forth.

Regards,
Fons

Adam,

<< In DBISam what I have done is encrypt the individual table, and then add
the password to the applications session on startup. This allows the
application full access to the encrypted table. This way uesrs can also use
DBSYS to view all tables externally form the application except for the
sensitive ones. >>

Do you want users to simply not have access to the table from within normal
EDB means, or do you want the table protected from viewing with a hex editor
?

For the first part, you should use the normal user security mechanisms in
EDB to accomplish what you want.  You can set up a role and/or user(s) for
normal users to use with the EDB Manager and any other external access
(ODBC) and exclude any privileges for sensitive system tables from this role
or user(s).   Then, have your application log in using the Administrator
user or some other super-user that has access to the sensitive system
tables.  If using the default Administrator user, just make sure to change
the default Administrator password and don't give users access to it.

For the second part, just alter the table and specify that it should be
encrypted.  That will encrypt the data on disk so that it isn't viewable
with a hex editor.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


How long do you think it will take our DBISAM raddled brains to catch up with ElevateDB?

Roy Lambert

Roy,

<< How long do you think it will take our DBISAM raddled brains to catch up
with ElevateDB? >>

Hopefully not much longer (I'm including myself here).

--
Tim Young
Elevate Software
www.elevatesoft.com

Good Morning all, and thanks for your replies...

Roy - thanks for that idea. A little bit more complicated than I would have
hoped for - dont' make me start wishing I was building this app with DBISam.


Fons - thanks for that advise. It's something I didn't consider, but having
a thought about it, while it would protect users from viewing the
information, it wouldn't necessarily stop them from being able to delete the
information, or alter certain boolean fields (such as an 'Administrator'
boolean field)...

Tim - thanks for your suggestion. It's given me an idea (which is a slightly
different approach to what you have suggested). I think I'll grant all users
administrator access (that way, I can 'see' which users are in the database
at any one time), but have the same password for every user that only I know
(that will be assigned within my app).

I may then create an additional user called 'dbmanager' or whatever that the
users can use to access the database via the EDB manager. This user of
course would not have access to the sensitive tables, but they could still
to all the other tables.

Thanks all for your help!

Adam.