I wrote a small application that is commercially used by an company. The application runs stable, but I am currently trying to get it to work on the companys computers after they have updated their security policy.
I am using Visual Studio 2019 and publish the application as an One-Click Application. It works on my personal system and also had worked on the companys systems. Besides the .Net system libraries, I am using the File Dialog to save and load files, TCP sockets to communicate with one other software and read and write one registry key in the user space.
Before their policy switch, it was possible to install it and run it. After the switch they required Admin Rights to install it and it will work, but as soon as the IT department revokes the admin rights, the program will not launch.
I am a stuck, because the users I work with are not very technically versed and Information I get is usually not very helpful. It is also not very helpful that I can't reproduce the issue and at that point it is just stabbing in the dark.
So would be glad about any help regarding to fix it on my end, be it settings for the publishing process, information they can extract and send me, or how I would be able to reproduce it.
I tried a few things on changing how the application is published, but that didn't change if it runs after the revoked.
I'd recommend working on two sides concurrently :
First, trying to have a usual process / documentation for the IT of your clients so that they are aware that your software needs admin rights.
It's not uncommon that some employees need some specific software, which requires elevated rights, while the IT department put restrictions on the actual user rights.
You need to make the IT departments of your customers aware that your software falls into this category. It's "their problem" to make it work, and for future clients you should even add some words about this in your contract.
This will ease the things if you give some clear, standard formatted documentation about this to your customers, so that they can forward it to their IT department for proper collaboration.
Of course, in parallel, you want to understand what is going on, and see if you can "fix as much as possible" yourself, as you are trying to do.
For that, a very good way is to have some "special users", some of your customers that you know are willing to help you by giving you reports of installation, because they have a more cheerful personality and/or are more technically savvy so they can easily give you some meaningful information.
With these users, you can try to experiment a bit more, add some proper logging to the installation process as much as you can and do rapid iterations to try to improve things.
Related
My website provides extremely sensible information (think of bank account numbers) publicly available through webpages and webservices. The customers may modify these information when authentified with a username and a password.
Any hacking intrusion that would successfully modify the entries of the database, or modify the information displayed on the webpage, would be disastrous, as account numbers might then be incorrect and money could be directed to a malicious bank account.
Do you have any general advices about the architecture that would make such a service as robust as possible? I would not be responsible in case of a weak password, so my main concern is about attacks that would simply bypass the authentication process and modify the database without triggering any alert on my side; it could also be the html code of the webpage that is directly modified to show different information...
Thank you
In this case i would make sure to harden the system itself as good as possible. This includes a very broad spectrum reaching from Security Roles over transaction based usage of the database, logging as well as the prevention of all sorts of attacks like SQL injection, cross site scripting in general and maybe if its a that sensible system use certificates and general IP checks (like have a white list of IPs that are allowed to populate requests to the system that do not instantly get refused). Not to mention your Host architecture has to be protected regardless of the implemented security features inside your system (key words: firewalls, user privileges etc.). During the development process there should always be auto code checking software (like Sonar) running to detect logical errors and stuff.
Then it could also be a good idear to have a second system just to monitor your primary systems status. This system should log and notify you on:
changes made to the system itself (like if someone has access to your business logic and for examply removes authentication logic)
changes made to the database that are not consistent with your primary systems state.
detect suspicious actions: Banks for example have rules that apply on your account. Like if you used to make payments within europe for the last time and then out of nothing make a huge payment to lets say china you would recive a notification to commit this payment. The payment then would not be triggered unless that second commitment of the customer.
In the end you already pointed out correctly that you just can harden it as good as possible but generally not make it "100%" safe (at least in theory) so to have a good level of security part of the total system would include beeing able to detect unwanted changes, identify the exact changes already beeing made and have information on the overall status of your system to allow a rollback or manual correction of a corruptet state in case it already happened.
Even after having implemented mentioned techniques you would have to continously check for security bugs in used frameworks, librarys and the system as a full (like using security penetration frameworks that auto try to corrupt your system).
What i want to show you with my answer is what the comments already suggest: It is a very broad and complex topic with multiple layers of security concernes you will have to either study yourself or have framework solutions that "ensure" you to take care of the topic (like Webframeworks often include basic XSS prevention).
Without wanting to sound harsh, but if you have to ask this question on Stack Overflow, you're not really qualified to work on this project.
The financial value of your data sounds like it's enough for an attacker to expend significant resources breaching your defenses - and the consequences of such a breach would be disastrous for your organization and its customers; it could lead to the organization having to close down. You really don't want to be learning about security from strangers on the internet in this case.
One place to start learning in is with the established standards for managing financial information, often referred to as "PCI standards"; these provide guidelines for hardware, software and processes for organizations that deal with payment details.
There are numerous books on IT security; I like the "Hacking Exposed" series, and "Security Engineering".
You might also bring in specialized IT security consultants; I've worked with a number of these guys, and many of them are very good at helping you engineer security into your solution.
i want to sell one program to customer， but I want to make one program can run at one server with only one lisence code, if customer want to run the program at other servers, he needs to buy more activation codes.
so is there a good method to generate activation code? i imagine that it will be related with one password and server mac-address
BTW: I just need one easy method, because my customer is not technology man
I can give you a rough idea, but, it isn't very easy.
Have a server running, and, at the start of your program, make it query your server with an activation code and a generated hash code (that is unique to each compile of the program) and have your server check if the combination has been queried before.
There are well-established solutions for [product activation][2], and they already deal with the issues you need to think about, including:
Securely activating licenses on systems without an Internet connection
Allowing users to securely relocate licenses
Allowing installation on virtual systems without enabling unlimited copying
When a user's system crashes, how you get their license up again on another system.
Protecting against various hacking attacks
What to use for locking? And as Alex says, the MAC address is not a good choice, even if it has been a common one. A combination of systems parameter is best, but then how do you deal gracefully with a user who does a minor system upgrade?
Secure trial licenses, whether time-limited, function-limited, or indeed both.
Configuring product features
Licensing upgrades...
....and much more.
There is no perfect way to do this since virtualization can basically emulate any environment to amazing detail. License files, signed executables, and remote license servers are all options but are such a strain on your customer. I recommend you form a license agreement with your customer and trust them. There is no reason that you couldn't adopt some sort of periodic audit but in the end it comes down to a matter of trust vs convenience.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have a commercial plug-in on top of Visual Studio.
My product is licensed per individual developer, so the developer may make copies on more than one computer, as long as the use of the product is by the same developer.
After a period of time I discovered that many of my customers purchase one developer license and distribute the product over all the team members (and it is not rare case).
I spent many hours (here in StackOverFlow and outside) searching on how to prevent this issue, but I found most of people talk about protecting per-machine license.
My question is how can I prevent my legitimate customers from illegally distribute my product over more machines if I can not restrict them to any number of machines?
Throw my search I get one solution, but I want to ask you if it is acceptable or not?
I can restrict the license per Windows user name, while the customer activate the product for the first time I record the windows username with the product serial number, so he can not run (or even reactivate) the product on any machine with another Window username.
If you purchase any product that licensed per-developer, is this approach is acceptable for you?? (or in the other side this policy may be reduce my sales?).
Best Regards,
You can use many forms of DRM to protect your product. Consider though that you will be hurting and annoying legal owners on occasion. If someone changed computers or reinstalled windows then he will not be able to install your product again. DRMs can also be broken and are usually never worth the time invested in them.
My advice is that you don't try to prevent piracy of your software, since you can't stop it. If you are aware of a specific client that abuses your license, send them a friendly but firm Email requesting they acquire legal licenses for all their copies. Failing that, you might want to pursue legal actions.
All in all, trying to fight software piracy is a lost cause. You might consider other types of licenses that make it easier for a company with multiple developers to acquire your plugin. If you give group discounts they are more likely to pay.
I guess it depends on how the plugin is used. If it's primarily used in an office environment where having computers set up in a windows domain is the de facto standard, then yes, it could be acceptable.
It could become a problem if the developers are used to being able to use the plugin at home on their home computer as well, since the username will probably not match.
Edit: You could perhaps set a limit of 2 usernames per user. That could solve the use-at-home problem.
I'd say trying to bind the license to the windows user name would be sufficient, and somewhat acceptable. In your case you likely don't have any protection against several machines/users/etc. using many copies of your license - making it trivial for several people to use it. Most legitimate people will buy the additional licenses if it becomes non-trivial to do otherwise, binding it to the login name provides easy incentive to get additional licenses.
Just keep in mind:
You can't protect against every way to circumvent licensing.
You don't need fancy license protection, you just need it to be easier
to get an additional license than it is to circumvent the licensing.
Don't make it hard to use a licensed product.
One caveat I have as a sole developer on some projects though, is stuff bound to just 1 machine (or perhaps user account) - I always need 1 additional license for my build server and/or my machine-at-home.
it is very annoying to have to pay for a license for that machine even if it's just me using it - so think about that. For your product, it'd mean I'd have to have at least 2 licenses - one for my work computer, one for my home cumputer (different users/domains).
Invent some kind of setting which everyone will want to have set their own way, and keep that setting value on your server, for a license. If it's the same programmer using the app from three different PCs, he'll have no complaints on that the setting is the same everywhere. (In fact, he'll like it). But different people have different tastes, and people will soon be tired of re-setting the option the way they like it only to later find it reset back to someone else's preference again. They'll think that maybe buying a cheap personal copy instead of going through all this crap is not a bad idea after all.
The more of user preferences you automatically move around, the better it is for a single user and the worse it is for cheaters.
Goerge, what you describe is pretty common in your industry. The battle is lost already. Small companies will not purchase as much license as they should, but bigger ones will eventually respect your licensing terms.
You must adapt your pricing strategy and take in consideration this fact.
Adding more protection will do the inverse, preventing you from getting new customers or keeping the existing ones.
Don't make it hard to use. I have seen bad results, like Blu-ray which almost failed because of so much DRM on them. Some people had to resort to Slysoft Any HD-DVD to play blu-ray because software player that was supposed to play Blu-ray wouldn't play the disc they bought.
Our clients must pay a monthly Fee... if they don't, what is the best way to block the asp.net software usage?
Note: The application runs on the client own server, its not a SaaS app...
My ideas are:
Idea: Host a Web Service on the internet that the application will use to know if the client can use the software.
Issue 1 - What happen if the client internet fails? Or the data center fails?
Possible Answer: Make each web service access to send a key that is valid for 7 or 15 days, so each web service consult will enable the software to run more 7 or 15 days, this way the application will only be locked after 7 or 15 days without consulting our web service.
Issue 2 - And if the client don't have or don't want to enable internet access to the application?
Idea 2: Send a key monthly to the client.
Issue - How to make a offline key?
Possible Answer: Generate a Hash using the "limit" date, so each login try on software will compare the today hash with the key?
Issue 2 - Where to store the key?
Possible Answer: Database (not good, too easy to change), text file, registry, code file, assembly...
Any opinion will be very appreciated!
Ah, the age old issue of DRM. And that's what you're talking about here. Frankly, the fundamental answer to your question is: you can't. No matter what you do to the system, it can be hacked and modded in such a way that your DRM authentication scheme can be bypassed and/or broken.
This is a fundamental fact of software development: it can and will be pirated.
So, the answer to your question is that you will have to trust the client to pay you the fees you determine to be correct (which is the whole point of contracts in this situation).
Any other actions you take are a hardship and annoyance on your paying customer, and has the potential to erode your customer base.
Now, if you want control of your software in the nature described, then do not provide it to users to run on their own servers. Force them to be SaaS. In that way, you control all of that. But this is the only way.
Something that you don't appear to be thinking about, but I have seen networks which do not allow any type of "dial home" solutions, as a majority of the systems were internally focused and thus these internal servers were NOT allowed to contact the outer internet. At all. It was deemed a security risk to even allow them access. How would you handle those networks?
Frankly, if I was the customer, and I paid my fees to license your software (which I installed on my own device) I would be irate if I had to allow that device access to the internet in order for it to work. Doubly so, if the software in question was any type of financial management, customer management, HR management, quality management, inventory management, sales, or just anything related to my business, customers or employees. I don't trust software developers enough to have their software talk to something else when my business-relevant data is held in their software.
In the end, what you are describing is an antagonistic approach to take with your paying customers. If you don't believe me, look at the comments that UbiSoft is getting for their latest customer-hating DRM scheme.
IMO, you have two good paths here:
Go SaaS
Ensure your contract has a
bite for non-payment
usually you provide an scrambled key that includes a valid authorization token and the expiration date through which service is paid. Then the installer will use this to "activate" your software. Not sure how this would be viewed if you have 1-2 week periods. you'd want to warn them about upcoming expiration. Also not sure how to tell if they've set their own clock back.
In short, nothing will be perfect.
I've dealt with this before and its not possible to make a perfect system. There are risks in anything you do. The best thing is to weigh your options, and determine the method that has the least likelihood of being hacked and the most likelihood of working correctly and easily for the customer.
Like others have said, they could change their clock and invalidate the license checking mechanism. If you didn't trust the user, you could make the license system connect to your servers. You would then need to ensure that they always have a connection to your servers to check the license.
What if there is a valid reason that they cannot access your server?
Their internet connection has a problem.
YOUR internet connection has a problem.
In that case, should you disable the application? Probably not. But then again, what if they shut down the connection on purpose? Then you would WANT to disable the application.
If you give them a monthly key, you're adding a monthly annoyance and you may lose a customer after a while (people tend to do business with those who make it easy).
For example: If you base it on their clock, and the application needs their clock to be accurate for some reason, then its unlikely that the customer will change their clock.
I agree with Stephen but ultimately, I think that your contract is your best ally here.
As been previously mentioned, you don't want to inconvenience customers, especially if you have a large deployment.
As for SaaS, if I were a customer using your product and you said that the model is changing and we need to access the software from your server and ours must be decommissioned, I'd not be happy. I'd probably use the opportunity to switch packages.
In corporate settings, the contract really is the best way to handle these issues. I've worked on licensing issues for desktop and ASP.NET applications and they can cause a number of headaches for both you and your client.
However, if you insist on using something like this I suggest you go with a middle ground. Instead of only unlocking the application for a week or two, provide a license for 6 months or a year. This way, if you run into licensing issues (and you will run into issues) they only occur once a year rather than a couple of times per month. That will be cheaper for you in support and your clients will be less unhappy about dealing with licensing issues. If the company stops paying and you need to terminate the license you can handle that on a one-off basis, using contract enforcement as needed.
On the web service or client license options, I think a good license system would incorporate both. A client license to provide a the application a stable license and a web service to generate and deliver the license key when it is time for the application to be renewed. If the client won't allow the application to call home to get the license key also provide a manual entry method.
If you are going to store a license on the client, do not try to build a component yourself. There are many components available which will be much more robust and reliable than the one you build. There is a .NET .licx-based licensing method and a number of 3rd party methods that you can use. Which one is most appropriate depends on your scenario: how flexible you want the license and what other options you need. Most importantly, find something reliable - any time your customers spend fixing problems caused by licensing is non-productive for them and will reflect poorly on the application.
The important thing to keep in mind is that no system is fool proof. If your application is valuable, someone is going to figure out how to steal it. But at the corporate level and with custom software it's more likely the licensing will be used to remind people to pay rather than stop wholesale piracy.
I'm about to get finished developing a windows application which I want to release as shareware. It was developed in C# and will be running on .Net 3.5+ machines.
To use it the user will have to be online.
My intent is to let the user try it for 30 days and then limit its functionality until a registration is purchased.
The installer will be made available via an msi file.
Could anyone give the general steps on how to implement this?
Here are some more specific questions:
Since I am trying to avoid having to invest a lot upfront in order to establish an e-commerce site, I was thinking of a way to just let the user pay somehow, while supplying his email in which he then receives the unlock key.
I found some solutions out there like listed here:
Registration services
I am still not sure, if they are the way to go.
One of my main concerns is to prevent the reuse if a given serial, e.g. if two users run the program with the same serial at the same time, this serial should disabled or some other measure be taken.
Another point is, that my software could potentially be just copied from one computer to the other without using an installer, so to just protect the installer itself will not be sufficient.
Maybe someone who already went though this process can give me some pointers, like the general steps involved (like 1. Get domain, 2. Get certain kind of webhost ....) and address some of the issues I mentioned above.
I'm thankful for any help people can give me.
I don't have a useful answer for you, but I did have a couple observations I wanted to share that were too large to fit in a comment. Hopefully someone else with more technical expertise can fill in the details.
One of my main concerns is to prevent the reuse if a given serial, e.g. if two users run the program with the same serial at the same time, this serial should disabled or some other measure be taken.
To ensure that two people aren't using the same serial number, your program will have to "phone home." A lot of software does this at installation time, by transmitting the serial number back to you during the installation process. If you want to do it in real time, your application will have to periodically connect to your server and say "this serial number is in use."
This is not terribly user friendly. Any time that the serial number check is performed, the user must be connected to the Internet, and must have their firewall configured to allow it. It also means that you must commit to maintaining the server side of things (domain name, server architecture) unchanged forever. If your server goes down, or you lose the domain, your software will become inoperative.
Of course, if a connection to your service specifically (rather than the Internet in general) is essential to the product's operation, then it becomes a lot easier and more user friendly.
Another point is, that my software could potentially be just copied from one computer to the other without using an installer, so to just protect the installer itself will not be sufficient.
There are two vectors of attack here. One is hiding a piece of information somewhere on the user's system. This is not terribly robust. The other is to check and encode the user's hardware configuration and encode that data somewhere. If the user changes their hardware, force the product to reactivate itself (this is what Windows and SecuROM do).
As you implement this, please remember that it is literally impossible to prevent illegal copying of software. As a (presumably) small software developer, you need to balance the difficulty to crack your software against the negative effects your DRM imposes on your users. I personally would be extremely hesitant to use software with the checks that you've described in place. Some people are more forgiving than I am. Some people are less so.
The energy and effort to prevent hacks from breaking your code is very time consuming. You'd be better served by focusing on distribution and sales.
My first entry into shareware was 1990. Back then the phrase was S=R which stood for Shareware equals Registered. A lot has changed since then. The web is full of static and you have to figure out how to get heard above the static.
Here's somethings I've learned
Don't fall in love with your software. Someone will always think it should work differently. Don't try and convert them to your way of thinking instead listen and build a list of enhancements for the next release.
Learn how to sell or pay someone to help you sell your stuff
Digital River owns most of the registration companies out there
Create free loss leaders that direct traffic back to you
Find a niche that is has gone unmet and fill it
Prevent copying: base the key on the customer's NIC MAC. Most users will not go to the trouble of modifying their NIC MAC. Your app will have a dialog to create and send the key request, including their MAC.
The open issue is that many apps get cracked and posted to warez sites. Make this less likely by hiding the key validation code in multiple places in your app. Take care to treat honest users with respect, and be sure your key validation does not annoy them in any way.
Make it clear that the key they are buying is node locked.
And worry about market penetration. Get a larger installed base by providing a base product that has no strings attached.
cheers -- Rick