I want to add a feature to my trial version of the application. After first activation, I want to make it limited to 90 days. But I am concerned about user's changing the date of system hence deceiving my application.
Is there any possibility to make it fool proof in a way that even if user takes the calender back, application expires after 90 days of first activation? First activation date has been saved in the database.
Thank you very much.
Furqan
In short, no, unless your application can run 24/7 and only allows itself to be started once. Even then, there'd be ways to subvert it.
#SB.101's answer is a way of checking for very simple date fiddling. It won't catch sophisticated cheats who know you're doing that and just keep setting the date to something sneaky that fools your checks. It will also annoy the odd few users who change the date on their system legitimately.
Pinging a server of yours over the internet to get the date would help, but is still able to be spoofed, and now annoys your users by forcing them to be connected to the internet (unless your application already needs that).
There is no sure-fire way of doing this. It is theoretically impossible. Remember that no matter how clever you are at checking whether the trial period has elapsed, a user can always modify or delete the recording of when the trial started!
I would advise you to just do something quick and simple, and rely on the fact that the small percentage of people who are both able to subvert your trial limitation and willing to bother doing so are unlikely to purchase the full version of your application anyway.
You can also save last run date in DB and can compare that to system date if that is newer that system date then you are deceived!
or
If you can use HTTP then can query time servers for current date time
Related
The system my company sells is software for a multi-machine solution. In some cases, there is a UI on one of the machines and a backend/API on another. These systems communicate and both use their own clocks for various operations and storage values.
When the UI's system clock gets ahead of the backend by 30 seconds or more, the queries start to misbehave due to the UI's timestamp being sent over as key information to the REST request. There is a "what has been updated by me" query that happens every 30 seconds and the desync will cause the updated data to be missed since they are outside the timing window.
Since I do not have any control over the systems that my software is installed on, I need a solution on my code's side. I can't force customers to keep their clocks in sync.
Possible solutions I have considered:
The UI can query the backend for it's system time and cache that.
The backend/API can reach back further in time when looking for updates. This will give the clocks some room to slip around, but will cause a much heavier query load on systems with large sets of data.
Any ideas?
Your best bet is to restructure your API somewhat.
First, even though NTP is a good idea, you can't actually guarantee it's in use. Additionally, even when it is enabled, OSs (Windows at least) may reject packets that are too far out of sync, to prevent certain attacks (on the order of minutes, though).
When dealing with distributed services like this, the mantra is "do not trust the client". This applies even when you actually control the client, too, and doesn't necessarily mean the client is attempting anything malicious - it just means that the client isn't the authoritative source.
This should include timestamps.
Consider; the timestamps are a problem here because you're trying to use the client's time to query the server - except, we shouldn't trust the client. Instead, what we should do is have the server return a timestamp of when the request was processed, or the update stamp for the latest entry of the database, that can be used in subsequent queries to retrieve new updates (how far back you go on initial query is up to you).
Dealing with concurrent updates safely is a little harder, and depends on what is supposed to happen on collision. There's nothing really different here from most of the questions and answers dealing with database-centric versions of the problem, I'm just mentioning it to note you may need to add extra fields to your API to correctly handle or detect the situation, if you haven't already.
As a software tester I came to an incident regarding testing on platforms with time travel. (the time can be set manually to past/future according to requirements of tests)
So the application time doesn't have to be same as my local time .... or should it be the same?
I found a bug that was caused by inconsistency between my local time and app time. Simple description: There are two validations. Validation #1 validates user input on client side (and is using local date for validation) and validation #2 validates user input on server side (and is using server date). Both validations are according to business rules that are specified in project specification. (it does not specify whether it should run locally or on server side) When there is inconsistency between those dates, it produces unexpected results.
However the bug was rejected by development that my test was wrong and that it's client's responsibility to synchronize those two dates.
Honestly I don't see reason what my local time has to do with application behaviour. There is lot of functionality and rules and for all of those is used server time as reference point. But because of that client side validation which is done by javascript the reference point is local time (because it's default behaviour, it's not intentional).
So I am just asking about your opinion. Do you think it's a bug or it's my bad understanding of importance of local time? How are you used to handle this things in your projects (as tester or developer)? This is not just issue of testing and server time travelling, but what about client "time travelling"? (eg. different time zones). Do you put any kind of efford to handle this things or just believe, that "bad local time = client problem" and that's not problem of development?
In general it is going to really depend on your application, what it does, and what is required. However, as a best practice, "application time" is always UTC. As another best practice, never trust client times. There are a ton of reasons an end-user's computer's time could be completely off or out of sync.
In almost every application I've worked with, we set the application server to UTC. For end-users we have them set their timezone, which we use to determine the timezone offset. So for example if an end-user selects "Eastern Timezone" we'd store that setting along with a -5 hour offset (ignoring daylight savings time for brevity). If you aren't storing user settings to a database you can still get their timezone via a client-side preference screen or automatically via javascript. But the key factor is ignoring their time, and just get their timezone/offset. Then you send that timezone over to the server so you can TRANSLATE the time using the server's accurate time. This way you always have the accurate server time, but then a reference to the user's local time that you can use for either reporting, logic, or display values.
So to answer your question: a bad local time in most cases needs to be accounted for, and is going to be YOUR problem. End-users aren't going to be checking their clocks to make sure they are accurate, they expect your application to work without having an IT person fix their side.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I created an activation system that works quite well. I come straight to the point. I insert the expiration date of the program within the registry through a system of encryption, and every time I check when the software if the date of PC corresponds to the record. The system only works if the user sends back the date of the PC obtains day trial unlimited.
This obviously hurts the entire system.
You can prevent this? Maybe saving the date of the PC in the program and check if the user has tampered? I rely on the solutions of you experts for this sensitive topic.
Thanks and sorry for my bad English.
There is a reason that Office and Photoshop are migrating to the cloud and lots of new games are requiring the user to always be online to play it. There really isn't a foolproof way to prevent a user from bypassing any sort of client-side protection you might implement. Even if you have your application dial home, a sufficiently motivated user could re-route this traffic to their own computer and falsify a successful authorization, or patch your code to not attempt the authorization in the first place.
You're entering an arms race here in trying to create an activation system. You need to decide how far you are willing to go to prevent unauthorized usage of your application. The more complicated you make it, the more likely it is to break, and the more likely it is for your application to incorrectly prevent usage by a legitimate user.
The best I have come up with is to have a second registry setting that holds the local computer datetime. I update this when the app starts and closes.
Then when you check your registry setting for the expiration date, you also check this other date to make sure it is older than the current computer date. If not, they are tampering with the time and I shut them out.
If they are smart and know what you are doing (unlikely), they can extend the trial period by moving the time on their computer back to after the last time they closed it. This will work for a little while but eventually they will run out of time.
PROs: Reduces the chance of tampering, does not require an internet connection
CONS: Doesn't work with virtual machines that have UNDO disks, the user can extent the trial period but not for long, Requires writing to the registry.
NOTES: Make sure you always save the UTC time in case daylight savings makes the time go backwards.
You should make sure the initial registry setting is created in your install package. This way if the registry setting is NOT there you can assume they tried removing it to tamper with the trial period - lock them out. After all, if you make the initial registry setting in you application, how do you know if this is the first time it ran or the thousandth and they just keep deleting the registry entries?
I am developing a VB.Net application. That application might be working on a LAN. MS Access as a back end will be used. I have developed many single user applications, but don't know of multi user , LAN, manage DB etc. How do I make the program as Multi user on LAN. Data will be accessed at the same time. How to manage such things.
Please give me some help and Guidance.
Thanks
Your VB application does not care how many people run it.
Your database, with MS Access, has some serious issues with multiple users. Get away from it if you can. SQL Server has a free version called SQL Express. If you only plan on 2 people, you might be OK with Access for a while but be prepared to support it more.
That was all the easy stuff, now you have to think about how you are going to handle multiple users trying to access and update the same data (concurrency).
Imagine this, you are a user looking at employee record 1 and so is someone else. You change the birthday and save. The the other user changes thier suppervisor and saves. How do you know something changed? What do you do if something changed? These are questions I cannot answer for you, you must decide based on your situation.
There are 2 main types of concurrency, optimistic and pessimistic. See this link for a great explaination and discussion on them: optimistic-vs-pessimistic-locking
You can look at this on a table-by-table basis.
If a table is never updated, you dont have to worry about concurrency
If a table is rarely updated, like a table of states, you can decide if it is worth the extra effort to add concurrency.
Everything else, pretty much should have some type of concurrency.
Now, the million dollar question, how?
You will find as many ways to handle concurrency as you will find colors in the rainbow. Here are some of the ones I like:
Simple number that you increment with each save. Small and easy.
DateTime stamp - As long as you dont expect to ever have 2 people save the same record during the same second, this is easy. (I personally dont like it by it's self)
User Name - Pretty simple gives a little bit of an audit by knowing who last inserted/edited the record but doesn't handle an issue I have seen to often. Imagine the same senerio as above but you had 2 instances of record 1. Now you change the data again, maybe supervisor, and when you save, you overwrite the changes from your first save with those of the second save.
Guid - VB can create a guid, SQL Server can create a guid and so can Access. It is nice an unique and most important, you can create it on the client so you dont have to requery the database after you save the record to get a refreshed record.
Combination of these. I like 2 and 3 myself. Gives a mini audit and is unique to the user.
If you use a DataAdapter, by default, MS will assume concurrency checking means to compare EVERY field to make sure it did not change. This works, but is completely un-scaleable and should not be done.
All of this depends on the size of your application and how you see it being used. Definately do some more research before you settle on a decision.
There are a number of solutions here.
If I may suggest a drastic alternative, have you considered pairing the client running on the user's computer with a server component (through a web service)? A simpler alternative would be for the client to talk directly to a SQL Server (or other database) instance through the network?*
*I'm not a fan of having client side apps talk directly to the database. It will mean maintenance headaches in the future, but I
included it to give you options
.
I found this random example via Google so YMMV.
I'm developing a Flash game in ActionScript 2, and the issue if that this game has to count the time securely.
It can't count the time from the Date class because the Flash Player takes the time from the local computer, and the user can change the local time so the time reported would be fake.
I haven't considerend to take the time from the server because there's a 3WH (3 way handshake) time and it would not be practical.
What do you sugest me??
You cannot perform secure computations on the user's system. They can manipulate it.
If that is a problem, your only real choice is to do it on the server. Of course, they could sandbox your app and fake a server conversation, so that's not entirely secure from within the client, but in most cases that won't cause a big problem since it should just affect that user (unless the data from the manipulated/forged server connection is then sent somewhere to affect other users).
When you are developing games that run on a system that you do not control there is basically no solution, you can make it hard for people but you can never be certain unless you basically modify your game to run on the server for all important parts. Even if you would make the game call the server for the time only people can insert a proxy and fake the response...
So is you really want to be sure no one messes with the game you have to make it run on the server (I know, lots of the time this is unwanted and/or impossible). In all other cases you can make it hard (obfuscate game code, encrypt communication) but never impossible - see google for lots of suggestions on making it hard, or see here and here.
The best way of solving the issue is to remove the incentive for players to cheat, so they simply won't try it at all -- of course lots of the time this is really hard.
See also: Cheat Engine, in case you didn't know about that one.