Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 7 of 7 total |
Advice for Password Table |
Sun, Jul 19 2009 9:35 PM | Permanent Link |
"Adam H." | 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. |
Mon, Jul 20 2009 3:51 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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] |
Mon, Jul 20 2009 5:29 AM | Permanent Link |
Fons Neelen | 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 |
Mon, Jul 20 2009 11:42 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Jul 20 2009 1:44 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
How long do you think it will take our DBISAM raddled brains to catch up with ElevateDB? Roy Lambert |
Mon, Jul 20 2009 3:10 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Jul 20 2009 9:13 PM | Permanent Link |
"Adam H." | 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. |
This web page was last updated on Saturday, May 4, 2024 at 09:18 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |