views:

179

answers:

7

Hi,

I want to store large files (videos, sounds) and access them via Database. I am balancing now between filesystem (references to files would be stored in DB) and pure DB (which could be enormously large after time). I have to protect the content too, so I thought, that DB solution suits better for this purpose. (probably it is not a good idea).

On the other hand I have got hint to encrypt files to protect them, if I choose to use file system.

How should I do this?

P.S please see the question What database should I choose not to worry about size limit?

thanx

P.P.S Under protection I mean encrypt videofile/soundfile using a crypt algorithm. When the application need to read them, it have to decrypt files... In that way the stolen files are useless unless appropriate decrypt algorithm is present. I thought to use RAR secured with password. As far as I know it is very hard to break it, when password is long enough. (Maybe I am wrong). I am not familiar about MD5....
I can not protect files against theft, but I want to prohibit to read it freely.

+3  A: 

One approach would be to create a background process with an elevated security token that would it access a section of the filesystem only available to administrators and that process. On Windows you'd create a "service". They call it "daemon" on *nix, I believe.

That service could then expose an API via pipes, sockets, or a shared memory region where the unelevated, user-mode database tool could get and set files.

There's no way to completely prevent system administrators from accessing a file directly, so if that is a requirement, you're out of luck. On Windows administrators have a special privilege that allows them to take ownership of any securable item such as a file or directory. Once they're owners, they can do anything they want to the securable item. There's just no way around that.

David Gladfelter
A: 

Use a DB (firebird or -embedded) and keep large content out of it.

If it is encryption you are worrying about, do this at the filesystem level instead of the db level.

All modern OSes have support for encrypted filesystems

Marco van de Voort
Does it mean, that I can encrypt content by calling single API?
lyborko
You can use a few simple calls to encrypt files to only be readable by a single account, at least under Windows. If you're using another OS, the API (if it exists) may be different.
peachykeen
+2  A: 

I have implemented both approaches in different projects with different requirements and constraints. And I would strongly recommend to keep all the contents in the database, storing the media files in large blobs. Eventhough that will require very large tables, that should not be a problem for the latest versions of the most well known databases.

I recommend DB2. DB2 since version 9 supports very large tables. The maximum is monstrously large. 512000 petabytes, half a zettabyte.

PA
Ok, but *why* do you recommend storing files in a DB?
Martin Wickman
Keeping everything in the database has several advantages. (1) Functionally it is simpler, simpler to develop, simpler to maintain. You don't need to synchronize functions to act at different layers. (2) you have solved "out of the box" (by the DB manager itself or by external tooling) several non-functional features; security access control, encription; scalability, both horizontal clustering and vertical parallelization; compression; concurrency; mirroring; backup; ...
PA
A: 

There are merits in both approaches.

If you want to have the files separately in the filesystem, I would encrypt each one individually. A password-protected RAR or ZIP file would be as good a method as any.

Use a different password/decryption key for each file, and store the password in the database along with each file name.

Rob McDonell
+1  A: 

You need to accept that the choice between storing the files in the database vs. in the file system ultimately doesn't matter much - in both scenarios they can be read trivially from outside, unless there is some encryption. That moves the problem from where to store the data to how to store the secret key to decrypt encrypted data, in your application.

This is a hard problem. There's probably nothing you can develop that can't be cracked by a determined attacker in a rather short time. It depends on the audience of your program whether that's a real concern; if it is, then you can't do much. It takes a single successful crack to access your data and make it accessible to all interested in it. The attacker will go for the weakest part, which isn't the hard-to-break file encryption, but your application.

mghie
I strongly agree with mghie on this one. There isn't a single DRM method that can't be hacked and bypassed so don't spend too much time on this, do something simple.
skamradt
A: 

The following is suggested without knowing the specifics of your application.

As you mention that you can not protect against theft, just about the only option to make sure the multimedia files are safe (unusable) by anyone other than the "owner" you need to encrypt them using a cipher like AES or BlowFish and a secure secret Key. These algorithms are different from MD5 that you mention. MD5 is a HASH algorithm.

For Delphi a rather good encryption library is DCPcrypt forund at http://www.cityinthesky.co.uk/cryptography.html. If has both HASH and Cipher algorithms.

Your problem will be Cipher KEY Management, namely "What password to use for encryption?". The simplest solution without thinking about this would be to use the users own password, untill you realize that the user may change the password. If the user does that you need to Decrypt and ReEncrypt every single multimedia file associated with the user.

To answer the actual question about key management I'd suggest reading up on key management. As I'm no expert on cryptography I hope someone more versed in the crypto world can help here... Link: http://en.wikipedia.org/wiki/Key_management.

K.Sandell
A: 

I think it all depends on a few things:

  1. Where do the files come from initially
  2. How will the files be accessed (over the network or locally)
  3. Who do you want to protect the files from

If the initial files come from "you" (the developer) then encrypted database blobs would probably be the best way as most dbs' come with some form of encryption.

If the files come from the user of the software, then using the file system would suffice - possibly using an temporary directory to store and retrieve files if used over the network, but actually storing the files in a non-shared location so that network users don't have access to all the files.

Just a few thoughts.

MarkRobinson