Data Access Worldwide Knowledge Base
Article Text
QUESTION:
I am using Pervasive 9.5 and Pervasive.SQL Connectivity Kit 3.0. I converted some files and would like to know if there is a way of encrypting the user/password and owner information that get saved to the intermediate (INT) files.
From what I saw, in the configuration file DfBtrDrv.int we have "OWNER <ownername>"; in the .int files for each converted table, we have the URI to connect to pervasive with the username and password.
Is there any way to encrypt this information? Would that work with both transactional and relational engines?
ANSWER:
It is not possible to use encryption for the .int files, but there are other ways to hide usernames and passwords.
Owner names:
You can specify an owner name at runtime with the DFBTR_ADD_OWNER command.
Maybe even reconsider if you need to use ownernames. The use of owner names is an older security mechanism that originates from the time Pervasive.SQL was called Btrieve. When using Pervasive.SQL security (and Database_Mode) the protection from unauthorized access is much better than when using owner names. If properly setup you can hide all physical data files from end-users and make sure they can only see the data they have rights to.
You _can_ use owner names in addition to Pervasive.SQL security, but I don't think it really adds extra security.
When you have defined an owner name on a table, you can access the table from both the DataFlex environment and through the SQL interface. From the DataFlex environment you specify the owner name in the INT file, in the DFBTRDRV.INT file or with the DFBTR_ADD_OWNER command.
From the SQL environment you must specify the owner name in a GRANT statement. This is described in the PSQL documentation (see link below).
URI:
Firstly, you should not use the Master user in URI's. The whole purpose of security is to assign users only those rights they really need. Add users and rights in Pervasive Control Center and use them in the URIs.
To avoid having usernames and passwords in the INT files you can:
1. Use the login command to login to the database first, before opening a table.
In this case you can omit the username and password from the URI in the .INT file.
2. Specify an URI at runtime using the Open As command:
For example:
Open "DFBTRDRV:btrv://psqluser@MyPSQLServer/Order?table=salesp&pwd=secret"
as hFile
Also, you don't have to hardcode owner names, user names or password in your source. You can use variables in the DFBTR_ADD_OWNER and LOGIN commands and the Open As with Uri command.
For example:
Get psUriUser To sUriUser
Get psUriPassword To sUriPassword
Move ("DFBTRDRV:btrv://" + sUriUser +
"@MyPSQLServer/Order?table=salesp&pwd=" + sUriPassword) To sUri
Open sUri As SALESP
How you fill the psUriUser and psUriPassword properties is up to you. You could, for example, write a routine that gets it from an encrypted file.
Contributed By:
Martin Moleman
Company: Data Access Worldwide
email: martin-m@dataaccess.nl
Web Site: http://www.dataaccess.com
Web Links Related to this Article
Pervasive - Owner Names
URL=http://www.pervasive.com//library/docs/psql/950/advops/advops-08-3.html#wp71786
Email this Article
Email this Article to a Colleague
Send Feedback on this Article to Data Access Worldwide
Copyright ©2010 Data Access Corporation. All rights reserved.
| The information provided in the Data Access Technical Knowledge Base is provided "as is" without warranty of any kind. Data Access Corporation disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Data Access Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Data Access Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. |