LinqConnect does not have its own authentication mechanisms, so you should use database server security mechanisms to protect your database data. However we can offer some ways to increase your LinqConnect security.

Connection String

Don't store passwords in the connection strings if possible. Not only is a connection string a security risk in its own right, but the connection string may also be stored as clear text in an external mapping file or application *.config file. If you design your model in Entity Developer as a Visual Studio add-in, The connection string is stored in the application *.config file by default, which is not recommended if you are concerned about the security. You may change your DataContext constructor to obtain the connection string from a more secure storage or to form the connection string in the program code.

Mapping

If you use your model as external mapping file, be aware that it completely discloses your database structure, so, if you store it as an unencrypted file or resource, database schema information will be available to those, who have access to this file. If you use Attribute Mapping, it will be substantially harder to restore your database structure, though it still will be possible, using IL-decompiler.

Database-Specific Security Options

Depending of the provider chosen you may use additional provider-specific features to increase security of your LinqConnect applications. If you use SQLite database, you may use third-party CEROD and SEE extensions to encrypt your database. For PostgreSQL database you may use the Standard or Professional Edition of dotConnect for PostgreSQL to connect by secure SSL protocol. And for MySQL you may use Developer, Professional, or Standard Edition of dotConnect for MySQL, which supports both SSH and SSL protocols for establishing secure connections. Read our provider documentation to know how to establish them.