I have made a desktop software in C# and i am going to make a 30 day free trail of the software ,now i will check the date and time from some server to check the date ... My question is, can the hacker hack this and produce somekind of key or steps to make it full version or produce some crack of it in the market for everyone(I know that a hacker can hack any product )???
Actually, a hacker can figure out what you are checking a date by REST API, by the monitoring of http traffic, then change the DNS name of your API to local host locally and provide you fake REST API response.
Sure, any software running on the desktop can be decompiled or reverse engineered. Then a patch can be created to disable any security features you've build into the application.
But this requires a lot of work. Not many applications are valuable enough for some hacker to spend so much time on it.
As others have already replied, it's trivially easy to intercept http(s) requests made to a server. Why don't you just use the date/time from the machine/device itself? Not many people will be willing to live with a date set back on their machine just to run your software illegally.
The real problem is where do you store that date. The first time the user legitimately installs your trail, that date won't be present. What is to prevent users from deleting that date and starting the trail period over?
To protect yourself from all this, run (parts of) your software in the cloud. But in that case, you'll need an authentication mechanism for your users.
Related
In case the point-of-sale card reader stops working, a backup card entry method is required by the card-processing vendor. The processor's suggested method is that the application hosts a WebBrowser control to the vendor's own site in which the credit card info is entered at checkout, and to watch for the URL to change to know when the transaction is complete and receive the verification token.
This struck me as a potential PCI minefield:
The keypresses are going into the same process as the rest of the point-of-sale application and the WebBrowser also provides in-process DOM hooks
I'm not sure what this means for HTTPS certificate validation in case of MitM from a separate machine
There are probably other things I don't know about that are just as important. (Deprecated protocols and algorithms?)
To be sure, a standalone web browser could have some of these same issues but at least it wouldn't be the responsibility of the application codebase. I wouldn't want a PCI audit to have problems with something unrelated in the codebase just because it shares a codebase with payment entry.
Am I overthinking this since it's only a backup method to be used if the card reader is down? What is the standard way of handling this?
If you were being audited, an auditor would look for the following basic things:
How frequently is the embedded browser updated by the manufacturer? How does it receive updates? Will it receive/deploy automatic updates? Or, will you have to redeploy the application whenever a critical security flaw is discovered/patched? How do you manage these updates? If the updates are automatic, how do you QA them after they're in prod? If you have to redeploy the application, how will you roll it out to users? How will you be certain that all users update from insecure versions to secure versions? How frequently are they pushed? Do you have a good set of processes to manage between updating so frequently that your users never have a clue what they're going to open up and updating so rarely that you are running extremely vulnerable software?
In practice (particularly if you're subject to a post-breach audit), is the embedded browser fully updated to protect against patched security threats?
Does the embedded browser protect against browser based threats like drive by downloads? Will your anti-virus solution still work with an embedded browser? Are you sure? How have you tested that?
If you were, say, running a virtual terminal inside of a browser, you'd want to be able to answer those same questions, only about the regular browser. So, using an embedded browser doesn't change the letter of PCI-DSS. However, the security processes around the embedded browser will be different.
For things like MITM attacks, I'm not entirely sure that I understand your question. An embedded browser would be as vulnerable as a regular browser to MITM, though some regular browsers have more enhanced protection against man in the middle attacks. For example, if your embedded browser was an updated version of Google Chrome, I'd feel a heck of a lot more secure than if your embedded browser was a version of IE 6 that hasn't seen an update this decade.
The important thing to remember is that if your cardholder data environment (CDE) is within a secure network that receives regular vulnerability scans (and if you have a good, written process governing how you perform vulnerability scans), you should be fine in the event of a breach. The kicker though is that you need to document both the process and how you follow the process.
Say, for example, that your process is to:
a.) Have an expert on your team do vulnerability scan every second Friday.
b.) Hire an outside firm to do a full vulnerability scan once per quarter.
You'd need to have records of:
a.) Who is your expert? How was she trained? Is she qualified to do vulnerability scans? If she finds a vulnerability how is it escalated? What dates did she perform the scans? Does she have any print-outs of the results? Does she fill out a form with her findings? Do you have all of the forms? Can I see the results of the vulnerability scan she performed on December 18, 2015?
b.) When you have professional scans done, who performs them? How do you vet that the firm is qualified? How do you vet that the person who did them is qualified? What happens if they find vulnerabilities? What happens if they find vulnerabilities that your in-house expert doesn't find? Can I see their last report? Can I see the report from three quarters ago?
In brief, we have a website built in asp.net c# that we're adding a login area to for people to see some paid for content. There will be different levels of account, one which when logged in can download say 10 documents a day, another that can download 20 etc....
What the client has also now asked for is can they sell unlimited access to this facility to a customer, where that customer will only be able to get this unlimited access when using some specific computers.
Really don't know if there is an elegant solution to this? I'm thinking MAC addresses must be the key, but as far as I know the c# code doesn't have direct access to that? Have read that JavaSript will be too unreliable in it's getting of the MAC adddress...and that writing a Java applet may be the only way.
Does anyone else have a better suggestion than this?
Any help would be greatly appreciated.
You are looking for the idea of Device Fingerprinting. Since this is a web application, you need the sub-field of Device Fingerprinting known as Browser Fingerprinting.
It is pretty easy to get browser fingerprinting right 80% of the time, and quite hard to get it right 100% of the time.
Have a look at Panopticlick (from the EFF) to get an idea of how it works.
There are several commercial software providers that provide solid Browser Fingerprinting as a service.
Although the general case is not easy, your specific case may be easier. For example, if you sell access to a company that is large enough to route all traffic through one or a few well-known IP addresses, you could just use that IP to authenticate users.
Alternatively, or specifically if you need to allow only certain computers within a facility, you could create a browser plugin that checks hardware (like the MAC address) and makes that information available to your authentication code.
Getting this kind of code right (in that it shows neither false positives nor false negatives, and is tolerant to changes in hardware such as a NIC upgrade) is very hard. It may be worthwhile to use a commercial browser fingerprinting company.
Is there a way that you can rely on static IP addresses? I know that, depending on the site these can change, but so can network cards (though this is less common).
Another question: Do you wish to restrict to individual machines, or simply make sure that only "N" licenses on that address are used? If this is the case, you can keep track of N license records on your side, with a corresponding cookie on the machine (perhaps a concatenation / hash of the IP address and license key signed with your private key) which expires after a week or what-have-you.
You have your own database / list of IP address, license key, and expiration date, and so if a computer logs on with an invalid cookie (IP address doesn't match what its license is associated with in your DB, to prevent copying cookies across), if a license is available in your DB (due to one pairing expired / never being used), give them the new license (and the benefit of a doubt). If it isn't available, give a polite "no more licenses are available, here's our sales number" message. This means that the IP address in your database is more of a reference thing, but it will also slow down "computer hopping", as these records will not expire until "a week or what-have-you" has passed. If a computer logs on with a "Valid IP" (in your DB) but no cookie / invalid cookie, re-issue that cookie with the same license as before with a new expiration date. Maybe. Maybe the same expiration date.
If IP addresses change slowly at the customer's site, this should work. If they change more than once per computer per timeframe, this could pose problems.
The initial distribution of these licenses could be "first come, first serve", and rely on a network address range and logins.
There are sexier answers already provided. Would good old/boring digital certificates suffice?
We've built a two-factor authentication process for our web application. We've built a small standalone app that generates an 8 digit security code every minute. When a user logs in they are prompted for the security code. When submitted the web app, generates the security code on it's end and compares it to the security code entered. If the two are equal then the user is allowed into the application. This is used like an RSA token.
However, I am using atomic clock servers to make sure the security code generation is the same for both the USB app and the web app as time zone and clock syncing poses an issue. This is a pain not only because the servers can sometimes be unreliable, but we also have to add in firewall rules to allow us to hit the specific atomic clocks. Is there a secure way to do this without using a remote atomic clock?
You don't need precise clock, but rather the same value. So expose some sort of "current time" service from the same web app (i.e. basic HTTP get "/currenttime" with JSON response) and query it from the USP app . In this case you only will need to synchronize time between servers serving the app (if you have more than one).
If your application does not have to be fully RSA token secure, you could modify the web application to accept the last 2 or 3 security codes. That way, you're not so dependent on time consistency.
If you have to have time synchronization, you can run your own time server that can be accessed by the web application and the USB application. The time has to be consistent, not necessarily correct.
Relying on external time is a bad idea, because if the time source can be manipulated (by, say, a man-in-the-middle attack, malicious upstream DNS changes, etc), then one can remotely query the device to collect future values.
You should really evaluate your security requirements before rolling your own crypto. It's very easy to fall victim to a number of mistakes, like accidentally using a PRG which is not cryptographically secure, side-channel timing attacks, or similar.
If you must do this for production make sure you open up your implementation so that it can reviewed.
I typically have not worried at all about piracy or copy protection with software however I currently find myself in a unique situation. I develop an application for repairing computers for a specific computer repair company. Recently an employee has decided to quit the company after only working there for one month, and took my toolset with her. She then started a computer repair company out of her home and is using my toolset to fix computers. I am not particularly concerned with this person as our lawyers are already in hot pursuit. My concern is with future instances of this where I may not find out about them.
What I would like are some ideas for ways to protect and or phone home without being too over-bearing. I hate software that is too protected and becomes annoying or worse yet, worthless. This application is never to leave the walls of the computer repair company as they do not do on-site repair and I think I can use this to my advantage.
I do have a couple of ideas about how to go about restricting usage to within the company but I would like to hear how others have dealt with situations like this. Currently I keep going back to checking the network for specific servers or ip ranges but does anyone else have any other ideas?
First i think you have to decide what you are protecting against, as game developers have learned over the years you cannot stop ppl from copying your app/game.
Assuming what you want to protect yourself against the above senario again, i can think of 2 ok solutions.And your app has access to the network "always" or normaly duing normal use.
Phone home:
Have the application phone home to some server software, either on the company network or via internet. Have the application send some information to the server, and have it respond with either OK or die command.
To prevent someone from stealing the server, hardcode the server application ( If its installed at the company) to accept 1 physical server ( IE requires the machines has X mac, Y CPU serial, L mainboard serial).
AppServer sending verification
Since you where thinking about sniffing the network from trafic thats posible, but might be better to have a server part that sends out a verficiation code ( IE some public,private key encrypted message with a timestamp?) at periodic intervals.
Depending on X server sends some network trafic every now and then does not seem logical, and could create issues ( IE that server gets removed, but nobody knows you app depends on it to respond to ping).
Also spending on being able to ping XXX.XXX.XXX.XXX and som MAC address in the network is fairly simple to fake.
I've been looking recently at using the open source Rhino Licensing solution http://hibernatingrhinos.com/open-source/rhino-licensing - this seems like quite a sophisticated solution and the source includes an example application which you could alter for your individual needs - e.g. you don't have to lock the user out if you don't want to.
The desktop application is being developed with a demo version that is supposed to run for a few minutes and after that would request the user to restart the application to run again (the user has to input their login and password to access it), since I dont know much in this field the way I can think of doing this without the user bypassing it would be having a realtime communication between both or something of the sorts.
After X minutes the server sends a
message to the client to close/disable
the client requiring the user to
restart it, it also limits the daily
usage on the demo for the same user.
As I am very inexperienced in this type or communication I would like to consult you guys with what options I have here ?
The desktop application is developed in c# to run mainly on windows OS as for the server we only have linux available and as to what sort of service, if it is possible to make a webapi or session in php or perl to work with it that would be reliable enough would be nice but if that is not possible we are open to hear other options.
PS: If I have'nt given enough information or am missing anything important here please drop me a comment i will update as soon as possible.
I'd give a go to HTTPS with mutual certificate-based authentication as the safest option. The desktop app can poll the server (=ask periodically) and quit in case of no response / no connection / negative reponse.
However, based on the type of app you are developing and the target audience, you can expect an important amount of users to have connectivity problems or have no connectivity at all.
Because of this, at the end of the day, you can come up with a lot simpler solution, like measuring run-time locally without any server involved, and gain pretty much the same effect.
I don't think you need to involve a server to do this.
Just have the desktop application save the date and time when it started. Periodically on a timer you can check the current time, and see if too much time has elapsed for the demo version, and tell the user they have to quit.
It is very unlikely many users will try to get around this. They are more likely to dump your trial software in favour of something that treats them decently!
Checking DateTime.Now could work as Ben stated, but you'd be better off with System.Timers.Timer. Set interval to be your desired interval between auth calls in milliseconds. Attach a handler to the elapsed event that asks for auth info. System.Timers.Timer works in a separate thread so you can take advantage of some parallelism here. Changing the system time shouldn't have any effect on System.Timers.Timer but I am not positive on that point.