quote:

---

Since the entire script is read into local memory, it can then be perused with a memory reading utility. Still not secure.

---

By an extension of that logic then, obviously there is no program that can't be reverse engineered, hacked, hi-jacked, etc. I hope that was your point.

Since nothing is hack-proof the question really becomes, "How much effort do we put into script protection?" If you're in an office full of secretaries, what passes for secure for you will be different than someone working in an IT shop or a government facility, etc. It's different not only because of the people involved, but also of what you're protecting.

If protecting your IP (intellectual property, not address ) or your passwords or sensitive data is of critical importance, I would argue that any scripting language will ultimately leave you less satisfied than a fully compiled solution.

Having said that, most of the problems that people seem to have with kix and security is that they're trying to run scripts in the user's logon session with an administrative-level security context (via SU for example).

As has been pointed out on this board, oh about 10,000 times, the best way to deal with this is not to run those scripts in the user's logon session, but rather use the Task Scheduler, or a custom service, etc.

So the answer to the original question is that it depends on your enviroment, the level of saavy of your users, what you're trying to protect, the likelihood of malicious intent, etc. etc. etc.

Ultimately, whether packaging an EXE will provide enough protection depends on the answers to the previous questions. Even here there is an issue of degrees. The KiXscripts Editor EXE packager was never designed as a mechanism to allow users to run scripts with elevated privileges. It's only designed for simplicity and convenience in a scripting environment. Being able to pack all necessary files together is just a convenience tool.

KiXcrypt on the other hand provides that same level of convenience but also takes an eye toward security. Is it hacker-proof? No, but it does provide a higher level of security that will be sufficient for certain environments.

So, basically, I have no answer to the question.

• Don't allow anyone who can read the file to have access to any tool which can be used to crack it.
• Don't allow anyone who can read the file to have any mechanism by which they can transporta copy of the file (floppy, email, http post, ftp etc)
• Don't allow any backup containing the file to leave secured areas

Not surprisingly this is very hard to do, which is why the better solution is to rely on security tokens and hand-shaking. Still not an absolutley secure environment, but damned hard to get anything useful from in time for it to still be of use.
Back in the real world, you normally have two "audiences" for your efforts to secure password.

The first are your users. If you are unlucky enough to have staff who view security as an interesting challenge, you have to pitch your security high enough that it is beyond their competence or persistance. If the prize is not interesting enough it won't be chased.

The second are the people you answer to - in my case this will be internal security auditors. You have to pitch your security high enough that you can convince them that a breach is unlikely. There is usually a cost / benefit balance you need to find.


In summary, security is what you make it.

You don't need the latest, greatest corneal/fingerprint recognition hardware backed up with lethal force counter-measures to protect your data.

You do need to understand what security is available and what the limitations and weaknesses are in your own security. If you think you haven't got any, you've missed something