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

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!).

Answer 2

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 3

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 4

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 5

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.