Deploying software on compromised machines - security

I've been involved in a discussion about how to build internet voting software for a general election. We've reached a general consensus that there exist plenty of secure methods for two way authentication and communication.
However, someone came along and pointed out that in a general election some of the machines being used are almost certainly going to be compromised. To quote:
Let me be an evil electoral fraudster.
I want to sample peoples votes as they
vote and hope I get something
scandalous. I hire a bot-net from some
really shady dudes who control 1000
compromised machines in the UK just
for election day.
I capture the voting habits of 1000
voters on election day. I notice 5 of
them have voted BNP. I look these
users up and check out their machines,
I look through their documents on
their machine and find out their names
and addresses. I find out one of them
is the wife of a tory MP. I leak 'wife
of tory mp is a fascist!' to some
blogger I know. It hits the internet
and goes viral, swings an election.
That's a serious problem!
So, what are the best techniques for running software where user interactions with the software must be kept secret, on a machine which is possibly compromised?

It can't be done. Fortunately, banks face exactly the same problem, so those little home chip'n'pin doohickies are pretty cheap.
So, if you want secure online voting, you send a custom voting doohicky to everyone who applies for one. This doohicky signs and encrypts their vote before sending it to the PC to be transmitted over the wire. The only thing an attacker on the wire can do, is eavesdrop whether or not the voter voted at all. Since political parties already do this, by posting party workers outside polling stations, that's not a significant risk to the system ;-)
You still face some of the problems of postal voting, such as vote buying and coercion, or stealing someone's doohicky, but only via physical access, not by compromising their PC. There's obvious DOS attacks if you rely on home internet connections, but there's no reason the voter can't have the option of going to the polling station if their connection goes down.
Whether the doohicky is cheap enough is still doubtful - I guess they cost a few pounds each, which I don't think is cheap on the scale of what is actually spent on elections. But they're not infeasibly expensive. I doubt they save much money at polling stations, unfortunately. The cost of polling in the UK depends pretty much on the number of polling stations. Problems this time notwithstanding, the number of polling stations isn't driven by the need to provide a fast enough throughput, it's driven by a desire that people not have to travel far to get to them. So having fewer voters doesn't really allow you to reduce the number of polling stations. Reducing paper might save time and money at the count, but surely not enough to pay for doohickies.
Finally of course there's still a risk of attack on the hardware. Someone could maybe intercept them in the post and replace them with identical-looking devices. But unlike attacking the hardware at a polling station, the attacker only affects one vote per piece of dedicated voting hardware compromised, so at least the bar is set high to begin with.

So, what are the best techniques for running software where user interactions with the software must be kept secret, on a machine which is possibly compromised?
The only answer is that you cannot / must not do it. If the hardware or OS might have been compromised you cannot guarantee to keep the user interactions secret.
But the other take on this is that no voting system known to mankind (electronic or otherwise) is incorruptible. That is why you need to have people checking for fraud, and people watching the people, and a culture where corrupt behavior is not the norm.
EDIT
... if one can reduce the impact of compromised machines to below the level of corruption in a paper voting system you're achieving a positive gain.
You also have to take into account other forms of corruption that are much easier with electronic voting from home. Like stand-over tactics, votes for sale, the fact that most people do not properly protect their electronic credentials, etc). In short, what you are proposing is hypothetical, and (IMO) unrealistic.
It is simpler to fix the flaws with in-person, on-paper voting than to address a whole bunch of potentially worse problems with a hypothetical from-home, electronic voting.
(Also, you are implying a level of corruption with UK paper voting that surprises me as an ex UK resident. This is off topic, but can you provide references / links that back this up?)

You have two main choices, either sidestep the comprimized part of the machine (e.g. provide the full OS) or work within the comprimise and make it hard to get hold of the data.
The second choice is more practical. Although you can't stop the shady dudes from eventually getting the data, you can make it difficult enough that it will take longer than a day, rendring the leaked voting habits harmless.
Assuming a web application, not using standard UI components and varying their locations on the screen, using multiple layers of encryption, disabling keyboard input, and using animations to fool screen grabbers can all make the process tricker to buy more time.

Obviously you can not ensure confidentiality of the vote if the machine the vote is entered with is compromised. Whatever measures you take, all an attacker needs to do is to execute your software in a virtual machine that records all access to keyboard, mouse and screen. By playing back the recording, the attacker can see how the user voted ...
However, when designing a E-Voting protocol this is the least of your worries. How do you prevent somebody from hacking the election server and manipulating results? How do you even detect tampering? What about the secrecy of my vote if the server is compromised? Can I be forced to reveal my vote?

The biggest threat facing e-voting is the ability for an attacker to influence the election. By spending CD's to people you make Massive Identity Leaks more valuable. Not only can an attacker destroy their credit, but they can also destroy their country.
Even forcing people to use specific hardware doesn't work. Look at console modding, or ATM Skimmers and Hardware Keyloggers. You have to worry about transferring the votes to be counted, even SSL has secuirty problems. There are also the problem of the centralized database, sql injection would be devastating.
The real question is, "Is e-voting more secure than paper voting?" What is harder for an attacker to influence? To be honest I don't think e-voting machines would have changed the outcome of the recent Iranian election.

An obvious solution is to send the software to the end user on a bootable CD. The user simply restarts their computer and they're now on a non compromised computer.
However, this is not terribly simple to develop (trying to make the OS on the CD compatible with all the variations of hardware we're going to encounter on machines). Also, I can't imagine that the average home user has their BIOS set to "Boot from CD" and telling voters to modify their BIOS settings is just going to far.

Related

What is the security standard for a small business?

This maybe a very newbie question, but exactly what do I need so that I can say my network is considered "secure"?
To be more specific, if I have a website that deals with login/signup and lots of money transactions, what do I need to protect it?
So far I know I need EV SSL certificate, login system protections like brute force login protection, hashing the password, key stretching. Is there anything I missed?
Besides, is firewall really necessary in my case? I just feel like everything I want to do can be accomplished by the server itself, so is there really a need to get a software/hardware firewall?
To be completely blunt, you should probably hire a security professional to assess and make recommendations about your site. Alternatively, a part or full-time network administrator with security experience/certifications might be a good hire.
I recommend the "don't do-it-yourself" approach not because I want to increase work for my peers, or that I don't believe you are a fully competent individual. Rather, I recommend it because security is really, really hard to get right, and any site that handles money is an ideal target for any attacker out there. From a professional perspective, you would be best served by getting an expert to secure your network, perhaps on an ongoing basis; this is a situation that security professionals are very used to, and very well equipped to handle. From a legal perspective, getting an expert opinion on such a sensitive matter is essential due diligence, and trying to do it entirely on your own opens you to significant liability if your system gets breached and attackers are able to carry off your customer's data. Which, as your business grows and you gain more visibility online, only more and more likely to happen without ongoing, professional help.

Website hacking - Why it is always possible to do?

we know that each executable file can be reverse engineered (disassembled, decompiled). No mater how strong security you will implement, anyway if crackers want to, they do crack!!! Just that is a question of time.
What about websites? May we say that website can be completely safe from attacks of hackers (we assume that hosting is not vulnerable)? If no, than what is the reason?
Yes it is always possible to do. There is always a way in.
It's like my grandfather always said:
Locks are meant to keep the honest
people out
May we say that website can be completely safe from attacks of hackers?
No. Even the most secure technology in the world is vulnerable to social engineering attacks, for one thing.
You can easily write a webapp that is mathematically proven to be secure... But that proof will only hold as long as the underlying operating system, interpreter|compiler, and hardware are secure, which is never the case.
The key thing to remember is that websites are usually part of a huge and complex system and it doesn't really matter if the hacker enters the system through the web application itself or some other part of the entire infrastructure. If someone can get access to your servers, routers, DNS or whatever, they can bring down even the best web application. In my experience a lot of systems are vulnerable in some way or another. So "completely secure" means either "we're trying really hard to secure the platform" or "we have no clue whatsoever, but we hope everything is okay". I have seen both.
To sum up and add to the posts that precede:
Web as a shared resource - websites are useful so long as they are accessible. Render the web site unaccessible, and you've broken it. Denial of service attacks add up to flooding the server so that it can no longer respond to legitimate requests will always be a factor. It's a game of keep away - big server sites find ways to distribute, hackers find ways to deluge.
Dynamic data = dynamic risk - if the user can input data, there's a chance for a hacker to be a menance. Today the big concepts are cross-site scripting and SQL injection, but once one avenue for cracking is figured out, chances are high that another mechanism will rise. You could, conceivably, argue that a totally static site can be secure from this, but then how many useful sites fit that bill?
Complexity = the more complex, the harder to secure - given the rapid change of technology, I doubt that any web developer could say with 100% confidence that a modern website was secure - there's too much unknown code. Taking the host aside (the server, network protocols, OS, and maybe database), there's still all the great new libraries in Java EE and .Net. And even a less enterprise-y architecture will have some serious complexity that makes knowing all potential inputs and outputs of the code prohibitively difficult.
The authentication problem = by definition, the web site lets a remote user do something useful on a server that is far away. Knowing and trusting the other end of the communication is an old challenge. These days server side authenitication is relatively well implemented an understood and (so far as I know!) no one's managed to hack PKI. But getting user authentication ironed out is still quite tricky. It's doable, but it's a tradeoff between difficulty for the user and for configuration, and a system with a higher risk of vulnerability. And even a strong system can be broken when users don't follow the rules or when accidents happen. All this doesn't apply if you want to make a public site for all users, but that severely limits the features you'll be able to implement.
I'd say that web sites simply change the nature of the security challenge from the challenges of client side code. The developer does not need to be as worried about code replication, but the developer does need to be aware of the risks that come from centralizing data and access to a server (or collection of servers). It's just a different sort of problem.
Websites suffer greatly from injection and cross site scripting attacks
Cross-site scripting carried out on
websites were roughly 80% of all
documented security vulnerabilities as
of 2007
Also part of a website (in some web sites a great deal) is sent to the client in the form of CSS, HTML and javascript, which is the open for inspection by anyone.
Not to nitpick, but your definition of "good hosting" does not assume the HTTP service running on the host is completely free from exploits.
Popular web servers such as IIS and Apache are often patched in order to protect against such exploits, which are often discovered the same way exploits in local executables are discovered.
For example, a malformed HTTP request could cause a buffer overrun on the server, leading to part of its data being executed.
It's not possible to make anything 100% secure.
All that can be done is to make something hard enough to break into, that the time and effort spent doing so makes it not worth doing.
Can I crack your site? Sure, I'll just hire a few suicide bombers to blow up your servers. Or... I'll blow up those power plants that power up your site, or I do some sort of social engineering, and DDOS attacks would quite likely be effective in a large scale not to mention atom bombs...
Short answer: yes.
This might be the wrong website to discuss that. However, it is widely known that security and usability are inversely related. See this post by Bruce Schneier for example (which refers to another website, but on Schneier's blog there's a lot of interesting readings on the issue).
Assuming the server itself isn't comprimised, and has no other clients sharing it, static code should be fine. Things usually only start to get funky when there's some sort of scripting language involved. After all, I've never seen a comprimised "It Works!" page
Saying 'completely secure' is a bad thing as it will state two things:
there has not been a proper threat analysis, because secure enough would be the 'correct' term
since security is always a tradeoff it means that the a system that is completely secure will have abysmal usability and the site will be a huge resource hog as security has been taken to insane levels.
So instead of trying to achieve "complete security" you should;
Do a proper threat analysis
Test your application (or have someone professional test it) against common attacks
Apply best practices, not extreme measures
The short of it is that you have to strike a balance between ease of use and security, much of the time, and decide what provides the optimal level of both for your purposes.
An excellent case in point is passwords. The easy way to go about it is to just have one, use it everywhere, and make it something easy to remember. The secure way to go about it is to have a randomly generated variable-length sequence of characters across the encoding spectrum that only the user himself knows.
Naturally, if you go too far on the easy side, the user's data is easy to pick off. If you go too far on the side of security, however, practical application could end up leading to situations that compromise the added value of the security measures (e.g. people can't remember their whole keychain of passwords and corresponding user names, and therefore write them all down somewhere. If the list is compromised, the security measures that had been put into place are for naught. Hence, most of the time a balance gets struck and places ask that you put a number in your password and tell you not to do anything stupid like tell it to other people.
Even if you remove the possibility of a malicious person with the keys to everything leaking data from the equation, human stupidity is infinite. There is no such thing as 100% security.
May we say that website can be completely safe from attacks of hackers (we assume that hosting is not vulnerable)?
Well if we're going to start putting constraints on the attacker, then of course we can design a completely secure system: we just have to bar all of the attacker's attacks from the scenario.
If we assume the attacker actually wants to get in (and isn't bound by the rules of your engagement), then the answer is simply no, you can't be completely safe from attacks.
Yes, it's possible for a website to be completely secure, for a reasonable definition of 'complete' that includes your original premise that the hosting is not vulnerable. The problem is the same as with any software that contains defects; people create software of a complexity that is slightly beyond their capability to manage and thus flaws remain undetected until it's too late.
You could start smaller and prove all your work correct and safe as you construct it, remaking any off-the-shelf components that haven't been designed to that stringent degree of quality, but unfortunately that leaves you at a massive commercial disadvantage compared to the people who can write 99% safe software in 1% of the time. Therefore there's rarely a good business reason for going down this path.
The answer to this question lies close to the ideas about computational theory that arise from considering the halting problem. http://en.wikipedia.org/wiki/Halting_problem To wit, if you could with clarity say you'd devised a way to programmatically determine if any particular program was secure, you might be close to disproving the undecidability of the halting problem on the class of machines you were working with. Since the undecidability of the halting problem has been proven, we can know that over turing machines you would be unable to prove securability since the problem of security reduces to the halting problem. Even for finite machines you might be able to decide all of the states of the program, but Minsk would tell us that the time required for a complete state tree for even simplistic modern day machines and web servers would be huge. You probably know a lot about a specific piece of code, but as soon as you changed the code, or updated it, a complete retest would be required. Fundamentally this is interesting because it all boils back to the concept of information and meaning. Read about Automated theory proving to understand more about the limits of computational systems. http://en.wikipedia.org/wiki/Automated_theorem_proving
The fact is hackers are always one step ahead of developers, you can never ever consider a site to be bullet proof and 100% safe. You just avoid malicious stuff as much as you can !!
In fact, you should follow whitelist approach rather than blacklist approach when it comes to security.

What is the best way to stop an application being copied and used without the owner’s permission?

What is the best way to avoid that an application is copied and used without the owner’s knowing?
Is there any way to trace the usage? Meaning periodically the application communicates back, with enough information so that we can know where it is, and if it’s legal. Next thing, of course, shut it down, if it’s not legit.
Software that "phones home" will be quickly shunned by the vast majority of your users. Just license it appropriately and sell it.
People who use your software professionally will either pay for it or they won't use it. Corporations tend to frown on potential lawsuits.
People who want to use your software without paying for it will continue to do so despite your best efforts to counteract them. Once the software is in their hands, it is out of yours. Without pissing off your users, your only recourse is a legal one.
If your product is priced reasonably, some people will pay for it and some won't. That is just something you need to deal with upfront and it should be factored into your business plan.
Don't do this, don't attempt it, don't even think about it.
This is a battle you can't win. If people want to pirate your software they will. You'll be shamed by the fact that a smart reverse engineer can write a one byte binary patch to subvert all your protection schemes.
The people who are going to pirate your software will do so and all these "security features" you build in will likely end up only inconveniencing your true supporters: the people who have legitimately purchased your software. These draconian DRM / anti-piracy schemes only build resentment among software users.
Hardware dongles are the best way if you are really concerned about piracy IMO. Check out the big industrial CAD/CAM packages worth thousands or tens-of-thousands, or the AV/Music production software, they virtually all have dongle protection. Dongles can be emulated or reversed but not without a significant investment in time, a lot more than just changing a few JEs to JNEs in your assembly.
Phoning home is not the way to go unless you are providing a service that requires a subscription and constant updates (like antivirus products, for example) as part of your business model. You need to have a bit of respect for your users and their privacy. You might have perfectly innocent intentions but what if a court ordered your company to hand over that information (like the US government is doing with Google and its search terms) - would/could you fight it? What if you some time in the future sold your company and the new owners decided to sell all that historic information to a marketing company? Privacy is not just about trusting a company not to abuse your data, it is trusting that company to go out of their way to protect your data. Which is pretty far down the list of priorities for most companies. So basically, the monitoring users thing is not really a good path to go down.
The best (and pretty much only) way to reliably prevent piracy is to have a client/server application instead of a standalone one, where a non-trivial part of the work is done by the server and users need to register. Then you can at least detect and block simultaneous use of the same account.
There are several approaches you could take, but there are three that will be vastly more effective that any of the others.
A. Don't create it.
Software that doesn't exist never suffers from unauthorized use.
B. Don't release it.
If you have the only copy, and you keep it that way, then the chances are exceedingly good that there will be no unauthorized use.
C. Give everyone permission to use it.
If you don't want anyone to use it without permission, then you can give everyone permission and there will be no unauthorized users.
There is a possibility to trace the usage. You can accomplish this by letting phone your tool home and send the information you need. The problem with this is, that first nobody likes software that phones home for this purpose and second with a simple application-level gateway you can block the application to phone home! What you describe in your question is a common problem of software-distributors and it's not an easy one to solve!
There's another thing I haven't seen mentioned yet : You could add loads of settings to the applications' configuration file, and start with ridiculous defaults. Then do the installation & configuration personally, so no-one but you is able to figure out how everything should be set. This can be a mayor put-down for people that are just trying out if a copy is enough. (Be sure to add settings that depend on all sorts of system-settings, like OS-version related DLL-versions that should be loaded, etc). Not very user-friendly tho ;-)

How to enforce locking workstation when leaving? Is this important?

Within your organization, is every developer required to lock his workstation when leaving it?
What do you see a risks when workstations are left unlocked, and how do you think such risks are important compared to "over-wire" (network hacking) security risks?
What policies do you think are most efficient to enforce locking the workstations? (The policies might be either something "technical", like a domain group security settings for screen-savers to be locking, or a "social", like applying some penalties to those who do not lock, or encouraging Goating?)
The primary real world risks are your co-workers "goating" you. You can enforce this by setting a group policy to run the screen saver after X minutes, which can lock the computer as well.
For me, this has become habit. On a Windows machine, pressing Windows-L is a quick way of locking the machine.
The solution might be social rather than technical. Convince people that they don't want anyone else reading their email or spoofing their accounts when they step away.
In my org (government), yes. We deal with sensitive data (medical and SSN). It's instinctual for me: Windows+L every time I walk away.
The policy is both social and technical. On the social side, we're reminded that personal security is important, and everyone is aware of the data with which we are privy. On the technical side, the workstations use a group policy that turns on the screensaver after 2 minutes, with "On resume, password protect" turned on (and unable to be turned off).
No, but I'm an organization of 1 - the last time I worked in a large organization, we were not required, but encouraged to. If I were in an enviroment with other people, I would probably lock my workstation now when I left it.
While certainly people with physical access can add hardware keyloggers, locking it does add an additional level of security. Depending on the type of organization you are, I think the risks are more from internal organizational snooping than over-the-wire attacks.
I used to work at a very large corp where the workstation required your badge to be inserted inside it to work. You weren't allowed to move in the building (you needed the badge to open the doors anyway) without that badge on you. Taking the badge out of the workstation's smartcard reader logged you out automatically.
Off topic but even neater, the workstations were more like "networkstations" (note that it is not a necessity to use the system I've just described, though) and the badge held your session. Pop it into another workstation in another building and here's your session just as you left it when you pulled the badge on the other computer.
So they basically solved the issue by physically forcing people to log off their workstation, which I think is the best way to enforce any kind of security-critical policy. People forget, it's human nature.
The only place I have seen where this is truly important is government, defense, and medical facilities. The best way to enforce it is through user policies on Windows and "dot files" on Unix systems where a screensaver and timeout are pre-chosen for you when you log in and you aren't allowed to change them.
I never lock my workstation.
When my coworker and friend mocked me and theatened to send embarassing emails from my machine, I mocked him back for thinking that locking does ANYTHING when I have physical access to his machine, and I linked him to this url:
http://www.google.com/search?hl=en&q=USB+keylogger
I don't work with any sensitive data my coworkers wouldn't already have equal access to, but I am doubtful of the effectiveness of workstation locking against a determined snoopish coworker.
edit: the reason I don't lock is because I used to, but it kept creating weird instabilities in windows. I reboot only on demand, so I expect my machine to run for months without becoming unstable and locking was getting in the way.
Goating can get you fired, so I don't recommend it. However, if that's not the case where you work, it can be effective, even if it's just a broad email that says, "I will always lock my workstation from now on."
At the very least, machines should lock themselves after X minutes of inactivity, and this should be set via group policy.
Security is about raising the bar, making a greater amount of effort necessary to accomplish something bad. Not locking your workstation at all lowers that bar.
We combine social and technical methods to encourage IT people to lock their PCs: default screen saver/locking settings plus the threat of goating. (The last place I worked actually locked the screen saver settings.)
One thing to keep in mind is that if you have applications (particularly if they are SSO) that track activity, changes, or both, the data you collect may be less valuable if you can't be sure the user recorded in the data is the user who actually made those changes.
Even at a company like ours, where there isn't a lot of company-related sensitive information available to most users, there's certainly potential for someone to acquire NBR data from another employee via an unlocked workstation. How many people save passwords to websites on their computer? Amazon? Fantasy football? (A dangerous goating technique: drop a key player from someone else's roster. It's really only funny if the commish is in on it with you, so the player can be restored ...)
Another thing to consider is that you can't be sure that everyone in your building belongs there. It's much easier to hack into a network if you're actually in the building: of course the vast majority of people in the building are there because they're allowed to be, but you really don't want to be the victimized company when that one guy in a million does get into the building. (It doesn't even have to be an intentionally bad guy: it could be somebody's kid, a friend, a relative ...) Of course the employee who let that person in could also let that person use their computer, but that kind of attack is much more difficult to stop.
locking your workstation each time you go for a coffee means that you type your password 10 times per day rather than once. And everyone around you can see you type it. And once they have that password they can impersonate you from remote computers which is far more difficult to prove than using your PC in the office with everyone watching. So surely locking your workstation is actually more of a security risk?
I'm running Pageant and have my SSH-public key distributed over all the servers here. Whoever sits down on my workstation can basically log into any account everywhere with my keys.
Therefore I always lock my machine, even for a 30s break. (Windows-L is basically the only Windows-key based shortcut I know.)
I personally think the risk is low, but in my experience most of the time it's not matter of opinion -- it's often a requirement for big corporate or government clients who will actually come in and audit your security. In that case, some kind of technical (group policy) solution would be best because you can actually prove you are complying with the requirement. I would also do it in cases where there is a legal privacy requirement (like medical data and HIPAA.)
I worked at a place where the people who supplied some of our equipment were from a company in direct competition with us. They were in the building when the equipment required maintenance. An email would go out every now and then saying they would be there, please lock your machine when you're not at it. If a competitor got our source because a developer forgot to lock their machine, the developer would be looking for a new job.
We are required to at work, and we enforce it ourselves. Mass chats are started professing love for people, emails are sent, backgrounds are changed, etc. Gotta love the first day when it happens to a new hire, everyone is sure to leave a nice note :)
The place I used to work had a policy on always locking your workstation. They enforced it by setting up a company wide mailing list - if you left your workstation unlocked, your co-workers would send an embarrassing mail to the list from your account, then lock your machine. It was kind of funny, and also kind of annoying, but it generally worked.
You could start sitting down at people's workstations and loading up [insert anything bad here] right after they walk away. That will work I'm sure.
In some/most government offices I've visited, that have the possibility of having members of the public walking about they have smartcards that plug into a USB reader on the PC. The card is on a necklace around the user's neck and locks the workstation when it's removed.
The owner of my company (and a developer), will make a minor change to your code window if you left your computer unlocked, making you go crazy wondering why your code isn't working until you find it.
Have to say, I never keep my computer unlocked after hearing about that prank, I go crazy enough as it is with some of my code.
You could rig up a simple foolproof way, have a fingerprint reader plugged into the computer programmed for your password, then wear this necklace with a usb receiver, and if you move away from the workstation, the screen saver actively locks it, then when you appear within the range, swipe your finger off the fingerprint reader to unlock the workstation - I think that would be a quite cheap way of doing it, simple, un-intrusive, and clutter free, no forgetting to lock via 'WinKey+L'
Hope this helps,
Best regards,
Tom.
Is it important or is it a good habit? Locking your computer is may not be important say in your own house, but if you are at a client's office and walk away then I would say it is important.
As for how to enforce...
After reading Jeff's blog entry on Don't Forget To Lock Your Computer; I like to change co-worker's desktop backgrounds to...
1,238px × 929px
Needless to say, co-workers started locking their computers.
GateKeeper is an easy solution to this. It locks the workstation automatically when the user walks away, and unlocks automatically when the user comes back within range of the computer. It can also require two factor authentication and other methods of lock/unlock.

How do you protect your software from illegal distribution? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am curious about how do you protect your software against cracking, hacking etc.
Do you employ some kind of serial number check? Hardware keys?
Do you use any third-party solutions?
How do you go about solving licensing issues? (e.g. managing floating licenses)
EDIT: I'm not talking any open source, but strictly commercial software distribution...
There are many, many, many protections available. The key is:
Assessing your target audience, and what they're willing to put up with
Understanding your audience's desire to play with no pay
Assessing the amount someone is willing to put forth to break your protection
Applying just enough protection to prevent most people from avoiding payment, while not annoying those that use your software.
Nothing is unbreakable, so it's more important to gauge these things and pick a good protection than to simply slap on the best (worst) protection you are able to afford.
Simple registration codes (verified online once).
Simple registration with revokable keys, verified online frequently.
Encrypted key holds portion of program algorithm (can't just skip over the check - it has to be run for the program to work)
Hardware key (public/private key cryptography)
Hardware key (includes portion of program algorithm that runs on the key)
Web service runs critical code (hackers never get to see it)
And variations of the above.
Whatever route you go, charge a fair price, make it easy to activate, give free minor updates and never deactivate their software. If you treat your users with respect they'll reward you for it. Still, no matter what you do some people are going to end up pirating it.
Don't.
Pirates will pirate. No matter what solution you come up with, it can and will be cracked.
On the other hand, your actual, paying customers are the ones who are being inconvenienced by the crap.
Make it easier to buy than to steal. If you put mounds of copy protection then it just makes the value of owning the real deal pretty low.
Use a simple activation key and assure customers that they can always get an activation key or re-download the software if they ever lose theirs.
Any copy protection (aside from online-only components like multiplayer games and finance software that connects to your bank, etc.) you can just assume will be defeated. You want downloading your software illegally, at the very least, to be slightly harder than buying it.
I have a PC games that I've never opened, because there is so much copy protection junk on it that it's actually easier to download the fake version.
Software protections aren't worth the money -- if your software is in demand it will be defeated, no matter what.
That said, hardware protections can work well. An example way it can work well is this: Find a (fairly) simple but necessary component of your software and implement it in Verilog/VHDL. Generate a public-private keypair and make a webservice that takes a challenge string and encrypts it with the private key. Then make a USB dongle that contains your public key and generates random challenge strings. Your software should ask the USB dongle for a challenge string and send it up to the server for encryption. The software then sends it to the dongle. The dongle validates the encrypted challenge string with the public key and goes into an 'enabled' mode. Your software then calls into the dongle any time it needs to do the operation you wrote in HDL. This way anyone wanting to pirate your software has to figure out what the operation is and reimplement it -- much harder than just defeating a pure software protection.
Edit: Just realized some of the verification stuff is backwards from what it should be, but I'm pretty sure the idea comes across.
The Microsoft Software License scheme is crazy expensive for a small business. The server cost is around $12,000 if you want to set it up yourself. I don't recommend it for the feint of heart.
We actually just implemented Intellilock in our product. It lets you have all of the decisions for how strict you want your license to be, and it is very cost effective as well. In addition it does obfuscation, compiler prevention, etc.
Another good solution I have seen small/med businesses use is SoloServer. It is much more of an ecommerce and license control system. It is very configurable to the point of maybe a little too complex. But it does a very good job from what I have heard.
I have also used the Desaware license system for dot net in the past. It is a pretty lightweight system compared to the two above. It is a very good license control system in terms of cryptographically sound. But it is a very low level API in which you have to implement almost everything your app will actually use.
Digital "Rights" Management is the single biggest software snake-oil product in the industry. To borrow a page from classic cryptography, the typical scenario is that Alice wants to get a message to Bob without Charlie being able to read it. DRM doesn't work because in its application, Bob and Charlie are the same person!
You would be better off asking the inverse question, which is "How do I get people to buy my software instead of stealing it?" And that is a very broad question. But it generally starts by doing research. You figure out who buys the type of software you wish to sell, and then produce software that appeals to those people.
The additional prong to this is to limit updates/add-ons to legit copies only. This can be something as simple as an order code received during the purchase transaction.
Check out Stardock software, makers of WindowBlinds and games such as Sins of a Solar Empire, the latter has no DRM and turned a sizable profit off a $2M budget.
There are several methods, such as using the processor ID to generate an "activation key."
The bottom line is that if someone wants it bad enough -- they'll reverse engineer any protection you have.
The most failsafe methods are to use online verification at runtime or a hardware hasp.
Good luck!
Given a little time your software will always be cracked. You can search for cracked versions of any well known piece of software in order to confirm this. But it is still well worth adding some form of protection to your software.
Remember that dishonest people will never pay for your software and always find/use a cracked version. Very honest people will always stick to the rules even without a licensing scheme just because that is the kind of person they are. But the majority of people are between these two extremes.
Adding some simple protection scheme is a good way of making that bulk of people in the middle act in an honest way. It is a way to nudge them into remembering that the software is not free and they should be paying for the appropriate number of licenses. Many people do actually respond to this. Businesses are especially good at sticking to the rules because the manager is not spending his/her own money. Consumers are less likely to stick to the rules because it is their own money.
But recent experience with releases such as Spore from Electronic Arts shows that you can go to far in licensing. If you make even legit people feel like criminals because they are constantly being validated then they start to rebel. So add some simple licensing to remind people if they are being dishonest but anything more than that is unlikely to boost sales.
Online-only games like World of Warcraft (WoW) have it made, everyone has to connect to the server every time and thus accounts can be constantly verified. No other method works for beans.
Generally there are two systems that often get confused -
Licensing or activation tracking, legal legitimate usage
Security preventing illegal usage
For licensing use a commercial package, FlexLM many companies invest huge sums of money into licensing think they also get security, this is a common mistake key generators for these commercial packages are prolifically abundant.
I would only recommend licensing if your selling to corporations who will legitimately pay based on usage, otherwise its probably more effort than its worth.
Remember that as your products become successful, all and every licensing and security measure will be breached eventually. So decide now if it is really worth the effort.
We implemented a clean room clone of FlexLM a number of years ago, we also had to enhance our applications against binary attacks, its long process, you have to revisit it every release. It also really depends on which global markets you sell too, or where your major customer base is as to what you need to do.
Check out another of my answers on securing a DLL.
As has been pointed out, software protection is never guaranteed to be foolproof. What you intend to use depends largely on your target audience. A game, for instance, is not something you are going to be able to protect forever. A server software, on the other hand, is something far less likely to be distributed on the Internet, for a number of reasons (product penetration and liability come to mind; a large corporation does not want to be held liable for bootleg software, and the pirates only bother with things in large-enough demand). In all honesty, for a high-profile game, the best solution is probably to seed the torrent yourself (clandestinely!) and modify it in some way (for instance, so that after two weeks of play it pops up with messages telling you to please consider supporting the developers by purchasing a legitimate copy).
If you put protection in place, bear two things in mind. First, a lower price will supplement any copy protection by making people more inclined to pay the purchase price. Secondly, the protection must not get in the way of users - see Spore for a recent example.
DRM this, DRM that - publishers who force DRM on their projects are doing it because it's profitable. Their economists are concluding this on data which none of us will ever see. The "DRM is evil" trolls are going a little too far.
For a low-visibility product, a simple internet activation is going to stop casual copying. Any other copying is likely negligible to your bottom line.
Illegal distribution is practically impossible to prevent; just ask the RIAA. Digital content can just be copied; analog content can be digitised, and then copied.
You should focus your efforts on preventing unauthorised execution. It's never possible to completely prevent the execution of code on someone else's machine, but you can take certain steps to raise the bar sufficiently high that it becomes easier to purchase your software than to pirate it.
Take a look at the article Developing for Software Protection and Licensing that explains how best to go about developing your application with licensing in mind.
Obligatory disclaimer & plug: the company I co-founded produces the OffByZero Cobalt software licensing solution for .NET.
The trouble with this idea of just let the pirates use it they wont buy it anyway and will show their friends who might buy it is twofold.
With software that uses 3rd party services, the pirated copies are using up valuable bandwidth/resource which gives legit users a worse experience, make my sw look more popular then it is and has the 3rd party services asking me to pay more for their services because of the bandwidth being used.
Many casual wouldn't dream of cracking the sw themselves but if there is an easy assessible crack on a site like piratebay they will use it, if there wasn't they might buy it.
This concept of not disabling pirated software once discovered also seems crazy, I don't understand why I should let someone continue to use software they shouldn't be using, I guess this is just the view/hope of the pirates.
Also, its worth noting that making a program hard to crack is one thing, but you also need to prevent legit copies being shared, otherwise somebody could simply buy one copy and then
share it with thousands of others via a torrent site. The fact of having their name/email address embedded in the license isn't going to be enough to disuade everyone from doing this, and it only really takes one for there to be a problem.
The only way I can see to prevent this is to either:
Have server check and lock license on program startup every time, and release license on program exit. If another client starts with same license whilst the first client has license then it is rejected. This way doesn't prevent the license being used by more than one user, but does prevent it being used concurrently by more than one user - which is good enough. It also allows a legitimate user to transfer the license on any of their computers which provides a better experience.
On first client startup client sends license to server and server verifies it, causing some flag to be set within the client software. Further requests from other clients with the same license are rejected. The trouble with this approach is the original client would have problems if they reinstalled the software or wanted to use a different computer.
Even if you used some kind of biometric fingerprint authentication, someone would find a way to crack it. There's really no practical way around that. Instead of trying to make your software hack-proof, think about how much extra revenue will be brought in by adding additional copy protection vs. the amount of time and money it will take to implement it. At some point, it gets to be cheaper to go with a less rigorous copy protection scheme.
It depends on what exactly your software product is, but one possibility is to move the "valuable" part of the program out of the software and keep it under your exclusive control. You would charge a modest fee for the software (mostly to cover print and distribution costs) and would generate your revenue from the external component. For example, an anti-virus program that is sold for cheap (or bundled for free with other products) but sells subscriptions to its virus definitions update service. With that model, a pirated copy that subscribes to your update service wouldn't represent much of a financial loss. With the increasing popularity of applications "in the cloud", this method is becoming easier to implement; host the application on your cloud, and charge users for cloud access. This doesn't stop someone from re-implementing their own cloud to eliminate the need for your service, but the time and effort involved in doing so would most likely outweigh the benefits (if you keep your pricing model reasonable).
If your interested in protecting software that you intend to sell to consumers I would recommend any of a variety of license key generating libraries (Google search on license key generation). Usually the user has to give you some sort of seed like their email address or name and they get back the registration code.
Several companies will either host and distribute your software or provide a complete installation/purchase application that you can integrate with and do this automatically probably at no additional cost to you.
I have sold software to consumers and I find this the right balance of cost/ease of use/protection.
The simple, and best solution, is just to charge them up front. Set a price that works for you and them.
Asking paying customers to prove that they are paying customers after they've already paid just pisses them off. Implementing the code to make your software not run wastes your time and money, and introduces bugs and annoyances for legitimate customers. You'd be better off spending that time making a better product.
Lots of games/etc will "protect" the first version, then drop the protections in the first patch due to compatibility problems with real customers. It's not an unreasonable strategy if you insist on a modicum of protection.
Almost all copy-protection is both ineffective, and a usability nightmare. Some of it, such as putting root-kits on your customers' machines becomes downright unethical
I suggest simple activation key (even if you know that it can be broken), you really don't want your software to get in your users way, or they'll simply push it away.
Make sure that they can re-download the software, I suggest a web page where they can logging and download your software only after they paid (and yes they should be able to download as many times they wish it, directly, without a single question about why on your part).
Thrust your paid users above all, there is nothing more irritating that being accused from being a criminal when you are a legit users (DVD's anti-piracy warnings anyone).
You can add a service that checks the key against a server when online, and in case of two different IPs are using the same key, popup a suggestion to buy another license.
But please don't inactivate it, it might be a happy user showing your software to a friend!!!!
Make part of your product an online component which requires connection and authentication. Here are some examples:
Online Games
Virus Protection
Spam Protection
Laptop tracking software
This paradigm only goes so far though and can turn some consumers off.
I agree with a lot of posters that no software-based copy protection scheme will deter against a skilled software pirate. For commercial .NET based software Microsoft Software License Protection (SLP) is a very reasonably priced solution. It supports time-limited and floating licenses. Their pricing starts at $10/month + $5 per activation and the protection components seem to work as advertised. It's a fairly new offering, though, so buyer beware.

Resources