3

I am in the process of upgrading an existing application that was written in flash to play mp3 files of phone calls. The purpose of the application is to train employees of how to work with customers. Some of the calls are "negative" calls and those are used to train employees of what NOT to do.

The reason I need to not provide a location of where the mp3s are, is that if someone were to become disgruntled and leave the company and decide to take some of the negative calls with them, that would be bad. I don't ever like to underestimate the intelligence of our users so I'm sure some could figure out a way to get them regardless.

The current implementation as I said was written in flash and it loads up all of the mp3s as the swf file loads on the client thereby mitigating the necessity to ever make a call up to the server to grab a new mp3 file. None of these mp3s are huge in file size because they're all only about 30 second phone call clips.

Are there any ways to prevent a direct download of an mp3 from an IIS server. Could I serve them up with c# as an aspx file that requires a specific hash or salt in order to play?

I really dont' want to have to have them all brought into a swf like the current implementation if I can avoid it.

any suggestions welcome.

TIA

Christopher Johnson
  • 2,629
  • 7
  • 39
  • 70
  • Even with the flash application someone could still use wireshark to learn the locations of the files. A knowledgeable user will always be able to get the file, because it needs to be local to be able to play locally. – Daniel Hilgarth Sep 17 '13 at 16:20

1 Answers1

2

Honestly, if a user is that determined to get the data, they will. I believe the balance here is at what point will said hypothetical employee feel the gain to be had by obtaining the data is not worth the effort to get it. And how much effort you have to go through vs. what it is worth to the company.

If the audio will always be played back on your application, one simple layer of security would be to encrypt the files. Keeping it simple, you can use a symmetric key, store it in the application, and decrypt the file in memory before it is played (this way it's not stored in a temporary file the user could just grab). Sure a user with 3/4 of a brain could probably fish the key out of the executable, but frankly the sound is playing on their speakers and I'm sure they have a smartphone. They could just as easily record the output with Sound Recorder as it plays too.

Simply speaking, I believe a very minimum layer of technological security mixed with a binding confidentiality agreement should give you enough recourse. The security will keep the would-be-honest honest and deter the lazy, as well as giving you a leg up in proving the employee obtained the audio through nefarious means (i.e. it wasn't just "available for the taking").

lc.
  • 113,939
  • 20
  • 158
  • 187
  • I appreciate the ideas. +1. I'm interested in your suggestion of at least encrypting the files. I'm still on the fence of what I want to use as an mp3 player in the user's browser. I really don't want to write a flash solution (I'd prefer to use something out a box somewhere (like jplayer or the like)). I'm not entirely sure how I could incorporate a decrypt mechanism on the client side and then plug the file into a player system like that. – Christopher Johnson Sep 17 '13 at 17:18