November 7, 2001 at 12:52 pm
Hello Everybody,
I have been approached by a client to develop an ASP+SQL application.
The terms of the contract are a bit weird. I will get ZERO development fees. But they have promised me 25% of the revenues. The product is a pay-per-registration kind of product.
I was wondering how the client can get away by not paying me and how can I avoid that.
1) Convert ASP application into a DLL so that my source code remains safe(Helps performance too)
2) Do all access to the Database through Stored Procedures ( Helps Performance too)
But with Encryption.
3) In my my Add_Registration module, I will send a mail to myself. This will assure me that lesser number of registrations than actual number are not reported.
The user says I can trust him and He will give me access to the database. I can check it anytime. But only issue is what is my hegde against him going against his word.
My question to the group is
a) Is this security good enough? Are there any more means to ensure I do not get the raw end of the deal ?
b) Also How badly if at all will the storing the Stored Procedures in encrypted form affect the performance?
Regards,
TIA,
RB
November 7, 2001 at 1:21 pm
Yikes!!!!
this is scary to even contemplate as a developer unless the client is someone your trust.
Some thoughts:
1) Convert ASP application into a DLL so that my source code remains safe(Helps performance too)
This is your best protection. Not sure easy this is to disassemble, but I know it can be done. Most likely they will appreciate the performance, but you must provide stability. This is also probably your best bet for protecting property. NOTE that they can still trace the calls, so your SQL is not safe, but you can at least keep your biz logic here.
2) Do all access to the Database through Stored Procedures ( Helps Performance too)
But with Encryption.
A quick search a couple months ago on google found 3 decrpytion algorithms. The v6.5 one is well known, but there are 2 different sprocs that will decrpyt v7/2000 items. I tested and they work. I'd use stored procedures, but only for the retrival and update ops you want. Don't put biz logic here, just selects and insert/update/delete.
3. Sending an email is good, but what i they block port 25? what if the email does not work? Not saying don't do it, but be aware of the problems. Email is non-guarenteed delivery. If you do this, be sure you have some backups. You can keep a counter ,write a text file, include another SQL statement and audit operations to some table that only has insert rights, etc. Nothing is fullproof here, but perhaps a couple items can help protect you. Another option that I'd suggest is to include an http call to an app you control. chances are they will not block http and you can "record" the hits on your side. For that matter, you could say that you will not allow registrations unless the "hit" is recorded on your side. You could implemetn some basic logic in a page on your side to return a good value and the DLL would only "register" the person if the hit occurred. Of course, you need to ensure you are not the issue with non-registers.
No security is perfect. Perhaps just a daily summary from SQL that sends you information that you verify somehow every week or so.
Be wary, and have a few ways to protect yourself.
Good luck
Steve Jones
November 7, 2001 at 7:38 pm
I agree with Steve. A couple suggestions:
Use a registry entry to hold a count of registrations. Most people don't have a clue what registry entries are for which application. This could be used if you face a lawsuit.
Set a time bomb that requires that the site report to you regularly. If it fails to handshake for some period of time you could start by putting up a nag interface then when that fails, you could completely disable the app.
Thom
November 8, 2001 at 8:45 am
I like the time bomb.
Be sure you disclose some of this in your contract so your client is aware he cannot stop you from accessing the site. Just let him know that you need to communicate with the app.
Steve Jones
November 8, 2001 at 10:56 am
email probably won't work as the client can probably stop emails being sent to you easily.
Zero dev fees and trusting the client to market the site is dubious - do they have any outlay to protect? They could just use the site as a marketing ploy and not care if anyone registers - probably too late to include a minimum nmber of registrations in the contract.
For the Time bomb thing - it could be just something that only you can update (like an encrypted stored proc with a hard coded expiry date so the client is forced to allow you access to the system before the expiry.
Note though that stored proc encryption isn't foolproof - I think you can still download decrytion procedures for every version (could be wrong on that though).
Cursors never.
DTS - only when needed and never to control.
November 8, 2001 at 5:27 pm
Time bomb isnt bad, but depending on how skillfully done is sometimes easy to beat. Registry storage isn't bad, but again, it's easy to profile registry access and see where info is being written. If your "client" isn't a super geek, a combination of this and the dll should work. Certainly doesnt hurt to include the email. You could also try a web service, where something on your end would log the transaction.
I hope you're not planning to put a lot of time into this - it's my experience that if it was REALLY likely to work, they'd rather pay you up front than give away 25%. Good luck if you do!
Andy
Andy
November 15, 2001 at 7:21 am
Please forgive the commercial message, but may I suggest you check out Encryptionizer for SQL Server (www.netlib.com)?
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply