If the concern is obfuscating passwords used in logon scripts, wouldn't passing them as command line parameters in the logon script definition hide them better? Then they are never in the script itself and the only people who can see them are people with access to the user database.

As for hiding the working of your script, an option to compile to pseudo-code, or byte-code would be interesting. It would hide the workings from a casual browser, and speed up the run-time enormously. Of course on the downside a de-compiler for byte-code is very simple to write.

my 1,5 cents

Unfortunately, users' login scripts are considered "public" information by NT. Despite the fact that this information is stored with the user's account in the domain SAM, ANYONE could view the password argument.

Check it out from the command line:
net user <username> /domain

This procedure would be useful, say, to provide an admin password to use with su.exe. However, any password made visible to the user's security context would be visible to the user, regardless of whether that password were passed as a command line argument, or if it were contained in a file. Again, strong encryption is the only possible solution. Decryption should be handled inside the script, so that it executes in the client's memory space & not transmitted clear text over the network.

NET USE [devicename | *] [\\computername\sharename[\volume] [password | *]]

I put this in a script

NET USE X: \\server\share /user:fred /domainname

and "/domainname" was actually the password. Looking at it, you would just think of it as another switch. Often you don't see what is in front of you.

I wouldn't recommend this type of security in the workplace though, but it give you an idea..

cj

RUUD,,,, what about something built in with an update, KiXtart 2001a ?

I could see knocking off something that compiles to psuedo-code in the timeframe of 2001, but expect that strong encryption would run us into 2002.

So just like there is a console-less version (wkix32.exe), there could be secure version (maybe wkix32s.exe).

I have a question?

Shut up and finish your test!

Yeah, I'm sure it is not an easy task, but having something built-in I think is probably about the only real solution... or a Service Pack that would support all Windows clients with this type of support.

In all I can't think of a secure solution that doesn't require that the decrypting is done on the fly within the interpreter.

2) it won't allow to "extract" files to change some things within, but only execute them.

3) A "builder" must me created, as it will be needed to create the exe with the specified file, and the command the exe will run

4) find someone to create a such thing

Advantage of this one is that it would be completly independant of any scripts language

That was my € 4 cents
A last thing : before thinking about the size, it should be interesting to see what size it show after an UPX (exe compressor, with an incredible rate. 2 Mb => 150 kb)

[ 13 September 2001: Message edited by: Popovk ]

If you have a robust operating system which will allow a process to allocate a private area of memory and place security controls on it so that no other process can read it even if the process is spawned by the same user, then you are safe from memory scanning. Unless your smart user forces a crash and preserves a swap file with the information in it of course.

If your operating system won't allow this then the memory (including RAM drives) can be read, and possibly changed.

The other problem is, if I can read the program I can take a copy to another computer which I have complete control over and fiddle to my heart's content.

A quick search at www.download.com gave me WinHack and MemoryBrowser, both of which will allow you to browse your local PC memory and RamDump which will dump the contents so you can play with it off-line.

Of course you need to be quite a sophisticated user to think about cracking the encryption that way, or using a debugger to step through the code and interrogate internal buffers.

You need to decide whether you simply want to deter accidental disclosure of passwords and the script code, or if you need a highly secure solution.

While safeguards could be put in place to test whether KIX is running from logon, whether the speed of execution is reduced by an external debugger, etc., these too could be overridden by a good hacker. I think what is needed is a server-side service that the client-side service sends security requests to.

We use a term called "due diligence" which means we need to take all reasonable effort to secure our environment. FE, I use SSL on my intranet to secure confidential HR and Payroll information. Maybe nobody sniffs packets on my network to pick up clear text, but I would be remiss to use "security by ignorance".

I think Ruud knows by now that we are all looking for something that would be handle our needs.

Have a Nice Day...

Like you, I enjoy playing the Devil's advocate. I am simply echoing the sentiments I see on this board. I also don't like to see security by ignorance. By that I mean the user's ignorance. Mind you, my / our ignorance is the greater sin.

Aside from conveying our needs / thoughts, I believe this thread has helped to raise awareness of different perceptions of "security".

In the end, Ruud will decide if / and / or what level of security and encryption to implement. This decision, we eagerly anticipate.

[ 14 September 2001: Message edited by: LLigetfa ]

-Shawn

[ 14 September 2001: Message edited by: Shawn ]

Richard, I was toying with this idea, but never got around to implementing it. When you say small.. what have you found? I had an idea to use the EXECUTE() function with an entire script inside, but I found a size issue there too.

Shawn, LTNH, how's tricks. I was thinking of the VBsecure thing too.

cj