Re: [little OT] Licensing/Implementing in Cocoa/Obj-C
Re: [little OT] Licensing/Implementing in Cocoa/Obj-C
- Subject: Re: [little OT] Licensing/Implementing in Cocoa/Obj-C
- From: Greg Hurrell <email@hidden>
- Date: Tue, 20 Apr 2004 12:02:29 +0200
El 20/04/2004, a las 3:49, Stefan Pantke escribis:
Do you build a lib or do you code for your own (single) application?
It's a Cocoa framework which contains Objective-C methods, standard C
functions, and macros, and can therefore be used in any app. In
practice the methods and functions only get compiled in debug builds,
and in shipping apps the macros are used to inline the code directly.
Copy protection is only one small part of the what the framework
provides. The cryptography functionality is provided by linking against
Apple's Security (CDSA) framework. In my previous apps I used MD5 and
SHA1 hashing functions that I had coded directly into my app; but with
public key cryptography (which to me seems considerably more
complicated) I decided to leverage Apple's existing and proven
implementation. This should be fine because the security lies in the
secrecy of the private key and not in the methods that are used to do
the encryption.
The other challenge is to make sure that the security mechanism doesn't
have a single point of failure which can be attacked, but that the
mechanism is intimately wedded to the program and the checks are not
only repeated at different points, but different checks are applied
throughout. There have already been quite a few suggestions in this
thread and elsewhere on how to do this, thus making the apps harder to
crack. (Admittedly only harder, but never impossible).
The trick is to invest a sensible amount of time on this, and not too
much, because perfect security is impossible. If you can spend five
minutes making your app three times harder to crack, then do it. But if
you have to spend two weeks of concerted development making it 10%
harder to crack then you're wasting your time and you would have been
better of spending those two weeks adding more features.
Conventional serial numbers are easy to email around,
I think, bigger license files are as easy to mail as standard license
numbers.
The only potential pitfall I see there is that some users can't receive
attachments, and some ISPs are getting more and more draconian all the
time when it comes to scanning emails for attachments and blocking
them.
Conversely, it's harder for users to share (or mass distribute) license
files than it is for them to share and mass distribute mere serial
numbers.
Best wishes,
Greg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.