And this what I meant when I said I understood what he meant. Now, to understand what I meant about by what I found specious about it, I will give an example. Lets say you encrypt a file with the latest and greatest method. A property of such methods is that you can publish the algorithm, but it will still be quite secure (axiom: everything has its limits). However, you can't also publish the encryption key. This is the "security through obscurity" of such a method.jwes wrote:The problem with "security through obscurity" is that it keeps people from taking more effective security measures. No one is saying to make them public, just to assume they will become public and try somehow to make it secure anyway.rjgibert wrote:I understand what you mean, but I have always found the concept a bit specious. It seems to argue for making our secret passwords public and that programmers may as well publish the source code for the applications they write. Good luck with that. Maintaining security without keeping at least some secrets is problematic.Michel wrote:Google for security through obscurity!1. They don't know it is there. Why advertise that you've protected yourself against cloners?
2. Even if they think to look for it, they won't know where to look, because it does not require any special code i.e. it can be melded together with ordinary useful code, so it will not give itself away.
In the case, of cloning, you can't prevent cloners from decompiling your program so that it can be examined. This makes it tough. If you have a solution that's bullet proof, I'd like to hear it.
Nobody in their right mind would argue that bad "security through obscurity" is not bad. But this catch phrase and its associated meanings hides the fact that good "security through obscurity" is good. Obvious as it is when stated plainly, this it what people nevertheless manage to miss. The point is that it is silly to disparage a security method as being "security through obscurity," since even good methods rely on this even though people tend to not think of that.
Now I already stated that what I have in mind is not bullet proof. I made no claims that it meets a high standard. Instead, the security rests on the fact that trying to break it is not a freeroll.
For example, you enounter a combination lock, you guess the combination, you try it, it fails and there is no adverse consequence.
With program cloning this is not true. You fail to find all of an indeterminate number of traps, you miss one, if you sell the clone, you can get caught red handed.
You can think of this as the FUD defense against cloning, the cloner might find all the traps, but doesn't know if there is one more and is pulling his hair out trying to find it and of course never does. This would be particularly effective if all the traps are dissimilar in method.
It rests on psychology, so obviously it is hardly bullet proof, but the predicament you can create for the cloner is an amusing one.