Database encryption

Roelof

Hi,

Maybe a weird question, but someone of our clients is worried about creditcard info in his database. He was asking if Navision's database is encrypted if you would dowload it in a text-editor.

Does someone has an answer on that?

Kind regards,
Roelof de Jong.

Savatage

there's one way to find out :whistle:

ara3n

If you are using sql it's not encrypted. You can see all the tables.and their data.

ara3n

just opened a 200 Meg fdb file in hex editor and yeah, can't see the data in clear text. All encrypted.

bbrown

Data encryption is irrelevant if someone gains direct access to your database files. Given the right tools and time, they will get your data. Beyond the user authentication/access rights control of the database/application, you control access by securing your network. Data encryption tends to focus more on how data is transmitted between the server and clients.

I am not sure about the Server/Client data encryption with the native database. I understand that the new tcps protocol provides some of this.

Microsoft® SQL Server™ encrypts or can encrypt:

Login and application role passwords stored in SQL Server.
Any data sent between the client and the server as network packets.
Stored procedure definitions.
User-defined function definitions.
View definitions.
Trigger definitions.
Default definitions.
Rule definitions.


SQL can use the Secure Sockets Layer (SSL) to encrypt all data between the server and clients. Enabling encryption does have a small impact on performance.

DenSter

Don't just start using tcps though, because that has been the cause of most of my problems over this past year. NAS will simply stop working with TCPS, so if you have any reason to believe you will need NAS, tcps is not an option.

bbrown

Good point on NAS and TCPS. I have experienced these issues and have had to move away from tcps.

If data security is of major concern, I would lean toward the SQL version. It is more tightly integrated with Windows Server 2003 and its security improvements. Also the server/client encryption in SQL is proven technology.

sporri

No the data is not encrypted in the database, and you really should not keep those credit card numbers there as you migth likely see somone with physical access to the database run off with them.

That being said:

Log all access to the CC number tables.

Put a firewall between your database server and client, use IPSEC so that your client can only talk to the database server over encrypted layer two tunnel, (works with native and sqlserver). And yes you will need Active Directory for this to be remotly simple in implementation

If you are using web pages, Only allow SSL (https) to those pages on your web server that work with the credit cards.

but, first and foremost dont keep the creditcard info

Sporri

bbrown

I would outline the security issues and concerns (and solutions to address them) to your client. Then let them decide whether or not to keep this data in Navision. Stress to them that these issues are not unique to Navision, and they will face them with most systems. You may consider putting this in writing and having the client sign it if they decide to put the data in the database.

...as you migth likely see somone with physical access to the database run off with them

You must address your physical security along with software security. If you are concerned with someone running off with the database, then review why they have been granted this access and remove it or them.

ovicash

Anyway, you can't copy, view or delete a database that is used by Sql Server. To do that you must de-attach it.

Dakkon

If you do store the credit card information in the native database, then I recommend putting it into a seperate table and restricting permission on who has access to that table to a minimum. I would also store the data in an encrypted format and decrypt it for viewing. This could easily be done with any encryption library that supports a COM interface (there are quite a few).

pdj

bbrown wrote:

SQL can use the Secure Sockets Layer (SSL) to encrypt all data between the server and clients.

I know this is a rather old post, but do you or anybody else have any additional information about this?
Does NAV support this without doing any additional work at the clients?
Is it a killer - performance wise?

Thanks in advance.

bednarb

This is an old dead thread...but since it is on topic... I thought I'd add that...yes in a hex editor the table text fields are not readily visible. Most of the database structure objects are in plaintext or compiled binary...but table data and index keys are "hidden". I had thought that the fields might be compressed to save space internally and not intentionally hidden. However...with a closer look...I find this is not the case (there may be some compressed fields like blobs) -- but the general text data itself is encrypted. Of course the encryption has to be very fast....and able to be applied against a single row or at most a block. Indeed the encryption seems to be database-wide. Once you figure it out...It seems like every text field everywhere (no matter the table or index) decrypts the same way. It may even be the same for multiple databases (possibly controlled by license key?)
I'm breaking it slowly... Of course I need to know a ton more about the btree structure and record structures. If anyone wants to chime in with any additional information about table text encryption it could only help. I agree that physical access to the database files pretty much negates security. It only serves to keep your data locked up inside a proprietary format. If a database wants to support encryption that's all fine and well...but it seems to me it should be up to the database owner...or at least....the database owner should be able to export their own data without paying to do so.

bednarb

Interesting. I just ran my decryption program against my large database which was not created under the same license key or by the same user etc....and it seems to have worked. Where there once was only a bunch of binary gibberish...I now have readable customer names and addresses and part item numbers and descriptions etc. That's a really unexpected surprise. Now I need to figure out how to traverse the btree to get the leaf nodes for the table I want. And I need to figure out how the record offsets into the leaf node are written into the leaf nodes header/"index area".
I still estimate my probability for success at less than 10%....but it was only 2% this morning...so things are looking up :-)