Time bomb needed in ASP.NET application

Question

We've developed a bespoke ASP.NET application for use on our customer's intranet. It appears they're unlikely to pay for it, so our boss would like us to introduce a time bomb.

[Edit:] Technical responses only please! Whether this is a good (or legal) idea is a question for CEOoverflow.com ;-)

All pages in the application inherit from a class called ApplicationBasePage and have consistent error handling, so I'm thinking that throwing an exception early in the lifecycle of ApplicationBasePage will be an easy way to make the application unusable. I'm open to other ideas you may have though.

My question is: how and where should we store the date on which the application will expire?

Some points to note:

• The application is installed on a single server in the customer's offices.
• Application data is held in a SQL Server 2005 database held on the same server. The database was designed by us and is not used for anything else.
• The application is only accessible on their intranet: there is no access to the application over the Internet.
• We currently have remote desktop access to their server, but would expect to lose that if things turn nasty.
• The application is written in .NET 2.0.
• Security is handled by FormsAuthentication.
• We need to be able to turn the timebomb off or change the its trigger date easily (assume we still have remote desktop access to do this).
• The server can normally access the Internet, but it would be best not to rely on this.
• The timebomb will only lock users out: it won't destroy any data.
• Unless it triggers, the customer must never be aware of the time bomb's existence.
• Their IT guy will happily go poking around in the web.config or in the database. He's not a programmer but he's not afraid to change things "just to see what happens". Decompiling or reverse engineering the application would be beyond his capabilities.

For extra credit, how much do you think it's OK to rely on security through obscurity in this case?

[Edit:]

• The application does a lot of business-critical date-dependent stuff, so we can be sure they won't change the clock on their server as this would make the application worse than useless.

Answer 1

Does their web server have access to the internet? You may wish to utilise a web service to trigger the time bomb in addition to other methods, since the wily sysadmin may be willing to set the clock on the server back a few years.

Answer 2

Well here are some things I can think of

1. Put a logic bomb that depends on one of your people logging on - so within a certain number of days of the last login application shuts down.
2. To use a date based lockout and store the date in a table in SQL server. But encrypt the value stored using a standard algorithm that uses a salt buried in your code. This way you avoid exposing the date to the sys-admin.
3. Using the method above store a large integer value from which you countdown as soon as the application loads into IIS - once it reaches zero delete the value in the db and lock down the application - you would have to reset the value using your encryption for it to work again.
4. Security by obscurity is fine if this application but if you want to market this as a product then you would need some kind of encryption.

None of these are foolproof though...
Disclaimer: I am not any sort of legal expert - I answered this from a technical viewpoint alone. I personally would not do this since I think it's morally ambiguous.

Answer 3

Couple of points to consider:

Is this even legal? Assuming you aren't planning on disclosing this Easter Egg, "Unless it triggers, the customer must never be aware of the time bomb's existence", you might be in for some legal trouble...

If the customer has access to the source then I can't imagine how you could include anything that they couldn't hire a developer to remove. Even if the IT guy isn't a developer it's not beyond their ability to hire another developer to reverse engineer the code.

Lastly, bad karma... If you are really working with a customer whom you don't think you trust to actually pay, then why work with them at all? I would expect that you would want to put everything on the table and get a full commitment from the customer before performing the work. If the customer balks at committing to pay then I would walk..

Answer 4

I really don't see any scenarios where this would end well. If you're worried about being paid (and they're presumably worried about paying for an app before it's delivered), what about setting up some kind of escrow? They put the payment into escrow with mutually-agreed provisions for releasing the money, and you then continue work knowing that the money has been set aside until you finish.

Answer 5

If you want the date to be on the server itself and not on the internet, it seems security through obscurity is your only bet. This is sensible though - you wouldn't want the application to check on the internet each time it starts for the date and die when there is a bad internet connection.

The easiest method is saving the date in the assembly itself as a variable. If you're afraid of simple decompiling encrypt it and store the key in the assembly too. If you think you would like to change the date in the future store it in the DB/web.config (encrypted of course). For encryption you can use anything from base64 to public key cryptography. Obviously that won't hamper serious decompiling of your code... but it is good for starters.

On a side-note, does 'logic bomb' reminds you Swordfish too?

Answer 6

I agree with the comment about calling it a trial version and letting it expire. In one of our products, a web publishing system, we have a common page class that will check the users license key and if it isn't valid we will print out a message at the top of all pages. The message is very visible but it does not affect the way the program works.

To do the check we store a "registration key" in the web.config file. We compare this with a key that we calculate, and the algorithm for calculating it is stored in a separate assembly. If the keys match we assume that the product is licensed.

For our use we only supply a customer name to the registration key calulcation algorithm, but you might want to add a version number or some other date. The registration key is then generated by calculating an MD5 hash of the supplied name combined with a secred code (some random bytes in an array).

This is by no means fool proof or very solid, but it is simple and has been enough for our use.

Answer 7

Move some logic to a webservice on your own servers. Let the customer application be dependent on that webservice. Have a good reason to move that logic, like "Its our core-business so we need to control that", make that change as a part of a "new version" of the program.

Renew the contract with the customer with a new section that tells that if they dont pay, your webservice will be disconnected.

If they dont want to sign the contract they dont want to do business with you and you can disconnect the webservice for them, if they sign, they agree to the new terms.

This is really the only way to do it if you want to be sure they cant use it if not payed. Else you have to relay on suing them or threats like that.

Answer 8

Knowingly introducing a "time-bomb" like that is certainly illegal. Your boss isn't the first one to consider it and won't be the last. His best bet is to halt production implementation until a payment is made.

Answer 9

Like many others here , I would say don't do it. I don't know if it is illegal but it just doesn't feel right. Business must be based on trust and open discussion must take precedence over such schemes.

Talk about your concerns and freeze development, if necessary - I assume they want the product after all!

Answer 10

"They're looking unlikely to pay for it, so our boss would like us to introduce a time bomb."

You're being asked by an incompetent businessman to implement a technical solution to a business problem. If your client is not going to pay, your Boss should be dealing with the situation like an Adult and not screwing around with logic bombs like a highschool hacker.

It's unethical, probably illegal, but mostly it's just stupid.

Answer 11

Technical problems are handled by programmers, business problems are handled by lawyers. Your boss needs to use the right tool for the job.

Answer 12

This sounds like a job for a lawyer.

Apart from that I would use a simple configuration file that contains the expiration date. Then store an RSA encrypted hash of that date in the configuration file, too. If you update the expiration date then you just update the encrypted hash, too. The application reads the date on a regular basis and decrypts the hash with the public RSA key and then checks the hash. If they tinker with the date, encrypted hash or public key then the application stops working.

Answer 13

If the customer has all pieces of the software, you cannot fully prevent it.

The only proper way is to make the application depending on some component that you own, for example it could require an activation after some time, or a ping to your web server.

This could be achieved by taking the installation date and using it as some sort of salt/cryptographic key and encrypting all data with it. You could then compare against that installation date. If the customer screws with it (setting the clock back), you will notice it since you have the original installation date. If they change the date, that will also change the cryptographic key and thus the data can not be decrypted anymore.

There is still a way around it, but with any time based solution you somehow do need to keep the installation date as a base to compare against, and you need to make this tinker-safe, hence the idea of using in some sort of encryption to protect all data with it.

Answer 14

Don't put you name around anything you do and remove all existing comments that have your name in them. If it does go to legal and your name is on the program your boss could easily throw you under the bus and say he had nothing to do it with it. I would seriously re-consider on following this direction. I know it's managements decision but if your doing the work that could easily come back to bite you.

Answer 15

This is fairly underhanded, but you could just write a scheduled task that executes a program which salts all the passwords. It doesn't ruin any data, and as long as you have access you can disable the schedule task. Also, if something happens where you want to give them the information back, it would be as easy as unsalting... desalting... the passwords.

As with many others, I would have reservations about actually implementing this.

Answer 16

Setting the ethical issues aside, if you're worried about your serial number implementation being hacked why not use an X509 certificate? If, for example, you have a Windows box with certificate server installed it can exposed a certificate revocation list on the internet.

Issue each client with a client identification certificate (bonus if you are supplying update checking to a central server - now you can use client/server HTTPS without worrying about passwords).

If the client doesn't pay then revoke the certificate. In your application startup simply load the certificate and check it's validity ...

Answer 17

I am not a lawyer, but heres my perspective: If they are claiming the program does not work and it is unusable, then they cannot later argue that it 'works less' and hold you responsible for damages unless they already made partial payments for what does work.

I would get their complaint in writing before you try any of the suggestions here. (I would add that the 'free trial' route seems safest)

Answer 18

Two thoughts:

1) I would host the application for them off-site until they pay, or until they put the money in escrow. If they say it doesn't work and won't pay then they won't mind if you turn off access whilst the agreement is sorted out, will they?!

2) We've done similar to this before. We spent far more time considering how any possible "time bomb" would be 100% bullet-proof so that it could not go off by accident either before the cutoff date, or at some time accidentally after having been "de-fused". For example, it may be better to actually remove the code rather than to just change a flag from "Trial" to "Unlimited use"

Answer 19

I would implement some kind of method in a compiled dll that you store in the bin directory. Call it something other than timebomb.dll.

You should then have a method in this dll that returns true or false:

public bool hasTimeExpired() {
  //Pseudocode
  DateTime expires = new DateTime(Janurary 10, 2009);
  return ( DateTime.Now() >= expires );
}

Just check the hasTimeExpired() method on Application Startup (global.ascx??) or on certain code pages, depending on how you want to handle the expiration message.

The dll in the bin directory would be easy to replace with a new compiled version when you wanted to turn off the timebomb or to extend the time. It would have to be decomplied to figure out the expiration date and would be easy to circumvent if they find out how it works, but as you said, the admin in question probably wouldn't do this.

Other than this, you really need to be working with a Lawyer, but sometimes a lock on a piece of borrowed software like this is more effective and cheaper than a Lawyer.

Answer 20

You might want to warn your boss that if his customer suffers any monetary loss (including loss of customers), your company is going to be liable for that loss and probably penalties, too, plus your company's legal fees. And, if the company doesn't survive the lawsuit and settlement, you'll be out of a job.

I'd think twice before just going along with this if I were you.

Answer 21

I can't speak to the legal issues.

Technically, I supposed you could do this. Make a key pair, and use the private key to encrypt a file with an expiration date. Your app will use a public key to decrypt the file with the expiration date. Every time the program runs, prominently display something like "57 days left until the license expires. yada, yada." That way, they have a continuous warning that the app will stop working.

As far as then corrupting any data after the expiration, I wouldn't do it. I think I'd encrypt some key items in the data that require the app to decrypt.

It's hard to get around a sysadmin that will set back the clock, though. But, if it has a net connection, you could have it "phone home" in order to get the key, and not work at all if it can't get it.

Answer 22

Do the Anti-Virus route, make an external call for "Updates". If you don't get the updates the application stops working if they don't pay, stop giving them updates.

I think it's the wrong solution to the problem, but I understand that your job is to do what you are told.

Answer 23

Thanks for all your responses!

We didn't quite do what any one person suggested, but used ideas from several of you.

Firstly, we stopped calling it a time bomb, and called it a licence instead. As the software is (arguably) incomplete at present, and as the customer hasn't paid for it, we can call it a test version that expires. This (probably) gets us past most of a legal minefield, and (as zsharp pointed out) if they claim the product is substandard, they can't really complain if they can't use it.

Anyway, the technical implementation goes like this:

We wanted the expiry date to be hidden where it wouldn't be stumbled across, and if it were noticed, be in a form that wouldn't be readily modifiable. It also had to be somewhere we could be sure wouldn't be affected inadvertently, even though it's on a server we don't have all that much control over.

So, we encrypted the expiry date and put it in an Extended Property on the database that the application uses, giving it a suitably misleading name.

The application checks the key on startup, setting a static boolean flag to true if the application hasn't expired. Every page in the site checks this flag and bounces the user to the error page if the flag is false.

We're happy with this solution for the following reasons:

• It's easy for us to change the expiry date of the application.
• There's no reliance on the internet being accessible, nor anything else beyond their server.
• The protection will survive backups and restores, or the application being moved to another box.

When the arguments have stopped, they've paid us and we're all friends again, the next upgrade to their application won't have the check in it at all, ensuring this forgotten piece of code won't be accidentally triggered at some point years down the line (thanks, Kristen!).