Re: Controlling who can run an executable
Cigar wrote: What I want: - the simplest thing that could possibly work! A splash screen that informs the user that it's confidential data, and that unauthorized use will lead to prosecution? Besides, I think it's not the program you need to protect, but the data. Think about that. Who cares about a hardware dongle if they can access the information you're trying to protect in notepad or via ODBC and MS query etc. She's as vulnerable if someone prints out a listing of the clients and takes that, as if someone copies the program. If you have the ability to generate lists of data, you might not want that feature to be accessible to normal users. Finally, there's another nice trick that you can do, now that most computers are hooked up on the net. Make the program report when it's being used. The easiest way might be to make it send an email, but I'm not quite sure how you set it up to do that on a windows box without asking the data-thief about email settings. Virus-programs obviously do this, so it can't be too hard. (Actually, to do something in your program that will alert anti-virus programs might be a good protection!) You could also make the program phone home via a socket etc, but that requires a server that can be reached on the net. But as others have said, you should make this a client-server app, and make sure the server is physically protected, difficult to break into (a DOS box or an old MAC?) and only serve the right kind of data to an authenticated user connected locally. -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
What I want: - the simplest thing that could possibly work! Have the program check for a file hidden somewhere on the computer. For instance, if the file dummyfile.dll doesn't exist in the windows/system32 folder the program just doesn't start. And when you install the program on her computer just add this file. And if anyone copies the program the can't run it on any other computer because they doesn't know the name of the file that's needed to start the program. How about that? -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Mike Meyer wrote: First thing to know; you can't stop someone who's sufficiently determined to run the program. I have explained to her that I can't prevent someone who REALLY wants her program from tossing a rock through her front window and making off with her PC. They'd get the hardware and the executable along with the client and transactions data. She conceeded that that would be out of my scope of being able to protect her program. Ideas I've had to prevent someone from running the app: - ask for a password every time the program is run. (I wonder how quickly they will complain about this, not very secure once everyone eventually finds out what the password is) If only authorized people have the password, then this works. The problem is that her employees are probably authorized, but she doesn't trust them to not take the program to her competition. Which brings up an alternative goal: I may have to just put password protection in and if she hangs herself by 'sharing' the password with underlings she trusts (at the present)... again that's outside of my control of protecting her. What I want: - the simplest thing that could possibly work! Telling her Don't let your employees near the computer with media, or when it's connect to a network. Currently this app is running on a stand alone PC. There was a big concern about hackers getting at her program or data from over the internet. I complemented her on this level of security. No floppy drive either. -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Cigar [EMAIL PROTECTED] writes: I may have to just put password protection in and if she hangs herself by 'sharing' the password with underlings she trusts (at the present)... again that's outside of my control of protecting her. You could have the password automatically change once a month. Give her a master list of passwords and tell her to lock it away. Each month she refers to the list and gives underlings a new password. Currently this app is running on a stand alone PC. There was a big concern about hackers getting at her program or data from over the internet. I complemented her on this level of security. No floppy drive either. If the app is not being used too often, install it on a laptop and lock the laptop in a drawer when not in use. -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Cigar [EMAIL PROTECTED] writes: I think the BIGGEST threat here is a feeling of vulnerablity. She now realizes that she is in a position that her competition was many years ago when she came into possesion of program the 'other side' was using and that she is now vulnerable. She wants to feel safe in the knowledge that she didn't reach into her pocket and pay thousands of dollars for a program that now could now be used by her competition. Nobody wants to pay money to level the playing field for all in a business environment. Suppose that competitor's program that her employee had illicitly brought her wasn't protected, so she was able to run it. You might ask her whether, ethical issues aside, she would be willing to use it on a daily basis, given it sounds like people in her industry know each other enough that word would probably get back to the competitor, and any resulting lawsuit would leave her up a creek. If she's not willing to use her competitor's program under those cirumstances, should she really be afraid of her competitor using hers? Also, if all she got from the competitor was an .exe, she'd have no way to customize it, and vice versa. It's just a collection of names, addresses, phone numbers, birthdays and drivers licences/health cards. I can think of a few dishonest things that could be done with this but her competition has the basically the same clients. Well, that sounds pretty confidential to me, but I'll take your word for it that the competitors are more interested in the code than the data. I do think she's overestimating the threat. Not by my standards but it is slowly replacing a paper system. (Police officer shows up and says 'We've just arrested John Smith. Has he sold you anything in the last 90 days. The client says 'Just a minute' and reaches for a set of 4 d-ring binders and turns hundreds of pages looking for a Smith name...) My client is relived that this senario will soon disappear. Is there something there that you can't do with a few spreadsheet macros? What is the competitor going to do with this code even if they get it? Simplify their lives. See above. Lawsuits don't simplify anyone's life ;-). Also, is there an office network? Maybe you could run the program on a server that most employees wouldn't have access to. They'd use it through some limited client program or through a web browser. A network exists but the client insists on a standalone PC. How about two PC's connected by a piece of ethernet cable, but no outside network connection. The server is a laptop or palmtop locked in a desk drawer. A little hole is drilled in the back of the drawer for the power and network cables. The network cable is connected to a PC on top of the desk that the employees actually use, running a web browser or the like. -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
On Tuesday 04 October 2005 01:43, Svennglenn wrote: Have the program check for a file hidden somewhere on the computer. For instance, if the file dummyfile.dll doesn't exist in the windows/system32 folder the program just doesn't start. And when you install the program on her computer just add this file. And if anyone copies the program the can't run it on any other computer because they doesn't know the name of the file that's needed to start the program. How about that? But wouldn't the file name need to be stored in the program somewhere? as a string which can be discovered using relatively trivial processes? That makes any protection difficult. Being totally not a cryptographic expert... the solution I'd see would be an installer that encrypts the Python package (zip file?) with some hardware-specific key, and then decrypts it before running it (runner would need to be in C or something). Or maybe just embeds in itself a crypographic signature using a hardware key that is verified before the program can run. -Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
In article [EMAIL PROTECTED], Cigar [EMAIL PROTECTED] wrote: I am developing a program for a client. She runs a shop where her clients bring in items for sale or short term buyback. Development of the program has been going great but she's mentioned that there is a 'feature' coming up in the next couple of weeks that she'd like me to implement that has me a bit worried. My client has told me a story of how she hired someone from a competing store and that person had brought a copy of the program her competition was using to track clients and transactions. He couldn't demonstrate the program for one reason or another because it was protected in a way that neither could circumvent. (She didn't remember how it was protected, she had hired this person a long time ago.) Now that I'm three months into the development of this program, my client tells me she would like to protect her investment by preventing her employees from doing the same to her. (Going to the competition and using her program.) ... Call the competition and ask them what they used. Point out that it worked. If they won't tell you, just look at their software until you find out. TonyN.:'[EMAIL PROTECTED] ' http://www.georgeanelson.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Paul Rubin wrote: Suppose that competitor's program that her employee had illicitly brought her wasn't protected, so she was able to run it. You might ask her whether, ethical issues aside, she would be willing to use it on a daily basis, given it sounds like people in her industry know each other enough that word would probably get back to the competitor, and any resulting lawsuit would leave her up a creek. If she's not willing to use her competitor's program under those cirumstances, should she really be afraid of her competitor using hers? Also, if all she got from the competitor was an .exe, she'd have no way to customize it, and vice versa. Oh I agree. (I just thought of something while writing a respond to this) What if she DID get the program running and only told me she couldn't and came up against the same morale, legal and technical issues that you're pointing out here and decided against using the program. I guess maybe part of her doubts that her competition would look at her program and come to the same m,l,t, conclusions about not using it if it fell into their hands. (I'm only guessing at how my client arrived at the decision to protect her program. All indicators suggests she is a moral, ethical and kind hearted person) It's just a collection of names, addresses, phone numbers, birthdays and drivers licences/health cards. I can think of a few dishonest things that could be done with this but her competition has the basically the same clients. Well, that sounds pretty confidential to me, but I'll take your word for it that the competitors are more interested in the code than the data. I do think she's overestimating the threat. Again I agree... but I would like to assuage her concerns as much as I can technically. It will keep a roof over my head awhile longer. Not by my standards but it is slowly replacing a paper system. (Police officer shows up and says 'We've just arrested John Smith. Has he sold you anything in the last 90 days. The client says 'Just a minute' and reaches for a set of 4 d-ring binders and turns hundreds of pages looking for a Smith name...) My client is relived that this senario will soon disappear. Is there something there that you can't do with a few spreadsheet macros? Are you trying to put me out of a job? :) What is the competitor going to do with this code even if they get it? Simplify their lives. See above. Lawsuits don't simplify anyone's life ;-). Costly for all. I do agree. A network exists but the client insists on a standalone PC. How about two PC's connected by a piece of ethernet cable, but no outside network connection. The server is a laptop or palmtop locked in a desk drawer. A little hole is drilled in the back of the drawer for the power and network cables. The network cable is connected to a PC on top of the desk that the employees actually use, running a web browser or the like. That might fly. I'll have to ask her about that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
On 4 Oct 2005 03:49:50 -0700, Cigar [EMAIL PROTECTED] wrote: Paul Rubin wrote: Cigar [EMAIL PROTECTED] writes: Now that I'm three months into the development of this program, my client tells me she would like to protect her investment by preventing her employees from doing the same to her. (Going to the competition and using her program.) Exactly what is the threat here? I think the BIGGEST threat here is a feeling of vulnerablity. She now realizes that she is in a position that her competition was many years ago when she came into possesion of program the 'other side' was using and that she is now vulnerable. She wants to feel safe in the knowledge that she didn't reach into her pocket and pay thousands of dollars for a program that now could now be used by her competition. Nobody wants to pay money to level the playing field for all in a business environment. So the biggest threat would seem to be her competition posting requirements here and having some showoff post a complete solution ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
I would write a companion program that works like this: $ protector -lock filename.exe and $ protector -unlock filename.exe the -lock switch would simply get the file size of filename.exe then generate a random chunk of data the same size, xor it with filename.exe and write the chunk data to a thumbdrive. filename.exe would now be 'garbage' the -unlock switch would then just read in the chunk of data from the thumbdrive then xor filename.exe with it to restore the file. this will stop most anyone from getting at filename.exe without the thumbdrive -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Myles Strous wrote: What's more, Tim Golden's wmi module (see http://tgolden.sc.sabren.com/python/wmi.html) makes getting at these numbers very easy: import wmi c = wmi.WMI () for thingy in c.Win32_NetworkAdapter(): print Network Adaptor, thingy.MACAddress for thingy in c.Win32_Processor(): print Processor, thingy.ProcessorId for thingy in c.Win32_BIOS(): print BIOS, thingy.SerialNumber for thingy in c.Win32_BaseBoard(): print BaseBoard, thingy.SerialNumber for thingy in c.Win32_SystemEnclosure(): print System Enclosure, thingy.SerialNumber for thingy in c.Win32_DiskDrive(): print Disk Drive, thingy.PNPDeviceID for thingy in c.Win32_PhysicalMedia(): print Physical Media, thingy.SerialNumber Regards, Myles. Ah... thing of beauty. One of these will probably make it into my final solution. Thanks millions! -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Istvan Albert wrote: was using to track clients and transactions. He couldn't demonstrate the program for one reason or another because it was protected in a way that neither could circumvent. (She didn't remember how it was protected, she had hired this person a long time ago.) I'd venture to guess that neither of the people above knew much about programming. So do the same, create a security measure that protects against this level of 'threat'. I could ask her, If you can't break it is that good enough security? As others have pointed out the simplest way would be to detect the presence of a hidden file, or some hardcoded system value, mac address etc. Obscure this step even more by encrypting some of the information so that one can't just simply view it in a hex editor. Istvan. -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
I could ask her, If you can't break it is that good enough security? Guess not. Most non-programmers think everyone else who knows some programming is a some sort of hacker genius. Instead come up with a simple solution then explain her how it will works. I think in the ensuing conversation you'll find out more on what approach would put her mind at ease. Istvan. -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Istvan Albert wrote: I could ask her, If you can't break it is that good enough security? Guess not. Most non-programmers think everyone else who knows some programming is a some sort of hacker genius. Instead come up with a simple solution then explain her how it will works. I think in the ensuing conversation you'll find out more on what approach would put her mind at ease. Istvan. Sorry I forgot to put the happy face at the end of that last sentence. Yes I'll be a good boy. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Tony Nelson wrote: In article [EMAIL PROTECTED], Cigar [EMAIL PROTECTED] wrote: I am developing a program for a client. She runs a shop where her clients bring in items for sale or short term buyback. Development of the program has been going great but she's mentioned that there is a 'feature' coming up in the next couple of weeks that she'd like me to implement that has me a bit worried. My client has told me a story of how she hired someone from a competing store and that person had brought a copy of the program her competition was using to track clients and transactions. He couldn't demonstrate the program for one reason or another because it was protected in a way that neither could circumvent. (She didn't remember how it was protected, she had hired this person a long time ago.) Now that I'm three months into the development of this program, my client tells me she would like to protect her investment by preventing her employees from doing the same to her. (Going to the competition and using her program.) ... Call the competition and ask them what they used. Point out that it worked. If they won't tell you, just look at their software until you find out. TonyN.:'[EMAIL PROTECTED] ' http://www.georgeanelson.com/ Sorry. All I have is this wonderful story to tell everyone. This employee she hired no longer works for her and the 'disk' that nobody to could get working is gone as well. Sadly there's nothing left for me to forensically examine. -- http://mail.python.org/mailman/listinfo/python-list
Controlling who can run an executable
I am developing a program for a client. She runs a shop where her clients bring in items for sale or short term buyback. Development of the program has been going great but she's mentioned that there is a 'feature' coming up in the next couple of weeks that she'd like me to implement that has me a bit worried. My client has told me a story of how she hired someone from a competing store and that person had brought a copy of the program her competition was using to track clients and transactions. He couldn't demonstrate the program for one reason or another because it was protected in a way that neither could circumvent. (She didn't remember how it was protected, she had hired this person a long time ago.) Now that I'm three months into the development of this program, my client tells me she would like to protect her investment by preventing her employees from doing the same to her. (Going to the competition and using her program.) What my client cannot prevent: - access to the .exe What my client is looking to prevent: - running of the exe by un-authorized individuals. Ideas I've had to prevent someone from running the app: - ask for a password every time the program is run. (I wonder how quickly they will complain about this, not very secure once everyone eventually finds out what the password is) - make a little hardware dongle and check to see if it's on the parallel port. (old idea) - check for an encrypted flash drive and try to read an encrypted file from it. (new idea) - buy the client a Microsoft Fingerprint Keyboard and figure out if it will make the clients life easier (two minutes of research showed this idea has multiple problems) What I want: - the simplest thing that could possibly work! I guess my problem isn't really a python problem. This is a scenario that any developer in any language might face where an executable should only be run by approved individuals. c.l.p searches I've tried: 'protecting code' - details how to make python files 'unreadable' 'preventing execution' - best one here details encrypting a root password Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Cigar [EMAIL PROTECTED] writes: Now that I'm three months into the development of this program, my client tells me she would like to protect her investment by preventing her employees from doing the same to her. (Going to the competition and using her program.) First thing to know; you can't stop someone who's sufficiently determined to run the program. The best you can do is raise the cost of breaking your security to be more than any value that could be gained from doing so. What my client cannot prevent: - access to the .exe What my client is looking to prevent: - running of the exe by un-authorized individuals. Not quite. Ideas I've had to prevent someone from running the app: - ask for a password every time the program is run. (I wonder how quickly they will complain about this, not very secure once everyone eventually finds out what the password is) If only authorized people have the password, then this works. The problem is that her employees are probably authorized, but she doesn't trust them to not take the program to her competition. Which brings up an alternative goal: Prevent running of the exe on unauthorized hardware. - make a little hardware dongle and check to see if it's on the parallel port. (old idea) - check for an encrypted flash drive and try to read an encrypted file from it. (new idea) - buy the client a Microsoft Fingerprint Keyboard and figure out if it will make the clients life easier (two minutes of research showed this idea has multiple problems) Note that these three all use the idea of unauthorized hardware, not people. You don't need to install special hardware to get that. There are a number of pieces of hardware that you can find in a modern computer that may have a unique serial number you can use as a dongle. Possibilities include a CPU serial number, an HD serial number, and the MAC address of any network cards: ethernet, wireless, and apparently FireWire drivers have them. People have used all of them in the past. What I want: - the simplest thing that could possibly work! Telling her Don't let your employees near the computer with media, or when it's connect to a network. That could possibly work, for some definition of work. You need to define how difficult you want breaking your security to be. Then we know what work means, and can figure out what the simplest thing is. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Cigar [EMAIL PROTECTED] writes: Now that I'm three months into the development of this program, my client tells me she would like to protect her investment by preventing her employees from doing the same to her. (Going to the competition and using her program.) Exactly what is the threat here? Misuse of confidential data, or just the code itself? Does the code do anything that fantastic? Did the employees sign NDA's? Usually this kind of thing is taken care of by legal agreements. Occasionally there are disputes that make the news (Microsoft and Kai-Fu Lee, etc.) but they make the news precisely because they're rare. What is the competitor going to do with this code even if they get it? It's just keeping track of transactions and stuff, right? It's being tailored to one person's specific preferences and requirements, and the competitor's needs will be different and they may as well just use something generic. Your best bet may be to just explain this to the client, that the most valuable thing in a business is relationships; technical secrets aren't nearly as big a deal as some people like to think. Also, is there an office network? Maybe you could run the program on a server that most employees wouldn't have access to. They'd use it through some limited client program or through a web browser. If you really want to do something with a hardware token, I like this stuff: http://basiccard.com. Assuming you're in the USA, buy from the Canadian distributor since shipping from Germany is very expensive. -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Mike Meyer wrote: You don't need to install special hardware to get that. There are a number of pieces of hardware that you can find in a modern computer that may have a unique serial number you can use as a dongle. Possibilities include a CPU serial number, an HD serial number, and the MAC address of any network cards: ethernet, wireless, and apparently FireWire drivers have them. People have used all of them in the past. What's more, Tim Golden's wmi module (see http://tgolden.sc.sabren.com/python/wmi.html) makes getting at these numbers very easy: import wmi c = wmi.WMI () for thingy in c.Win32_NetworkAdapter(): print Network Adaptor, thingy.MACAddress for thingy in c.Win32_Processor(): print Processor, thingy.ProcessorId for thingy in c.Win32_BIOS(): print BIOS, thingy.SerialNumber for thingy in c.Win32_BaseBoard(): print BaseBoard, thingy.SerialNumber for thingy in c.Win32_SystemEnclosure(): print System Enclosure, thingy.SerialNumber for thingy in c.Win32_DiskDrive(): print Disk Drive, thingy.PNPDeviceID for thingy in c.Win32_PhysicalMedia(): print Physical Media, thingy.SerialNumber Regards, Myles. -- http://mail.python.org/mailman/listinfo/python-list
