|
|
Posted by David Portas on 12/09/05 11:55
Martin wrote:
> Let's say that you develop an application. This application does some work
> and needs to allow the user to save it to files. Much like MS Word or
> Photoshop let you save files. Now, the application can be best written if
> it can use database technology while doing its job. However, the resulting
> files need to be encrypted for security reasons. There are many possible
> reasons for this. One may be that you don't want your competition to
> benefit from your work product and extract data from your files.
Attempting to protect proprietary data distributed with your
application may be reasonable enough. Locking away the *customer's*
data to prevent interop with competitor apps is not in the customer's
best interests however. I have come across one or two cases of that
over the years and if I were a customer I would not want to consider
purchasing such a system.
> The choices, as I see them, are:
>
> 1- Create a completely custom file format, re-invent the wheel and roll out
> your own db-style code. The file would be encrypted upon storage and
> decrypted upon loading.
But the customer still needs to possess the decryption key. If the key
is in the software this is merely obfuscation rather than security. The
price is the performance impact.
>
> 2- Use some sort of db system that is encryption-capable. Something like
> SQL server isn't a possibility because customer machines will not have this
> available.
You can distribute SQL Server with your app, either Express Edition or
with a runtime licence. Why else are you posting in a SQL Server group?
--
David Portas
SQL Server MVP
--
Navigation:
[Reply to this message]
|