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

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

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

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 4

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 5

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 6

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.