#85824 - 2002-05-31 06:30 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
It sounds like a great idea to me! I'm not sure about the implementation, though..
Brian
|
Top
|
|
|
|
#85825 - 2002-05-31 07:55 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
Stevie
Starting to like KiXtart
Registered: 2002-01-09
Posts: 199
|
As far as existing Crypto wrappers--Microsoft never bothered to create one for the CryptoAPI. That's kind of odd, but nevertheless...
Here's my thoughts on implementation:
An ActiveX control (DLL) that exclusively uses the CryptoAPI instead of something homegrown. One benefit of that would be to allow the scripter to select the type of encryption they would want, i.e. RC4, RSA, etc.
Or, for simplicity's sake, just hard-code one solution so it's easier to use.
Then when you have a password you want encrypted, for example, generate the encrypted string with a "dummy" script like:
Dim $Crypto $Crypto = CreateObject("KixFunctions.Crypto") $x = $Crypto.Encrypt("password")
? $x (let's pretend this returns "4rI92Hrk22pkl")
Then take the encrypted return and place that into the actual "protected" script wherever you need the password, for example:
USE E: "\\SERVER\PUBLIC" /user:Yogi /password:$Crypto.Decrypt("4rI92Hrk22pkl")
That seems to me the best way to go. At least that's what I have in my head. Any suggestions for a different implementation is more than welcome. Once we come up with a final plan, I'll go ahead and do it.
Quick question: Would allowing different encryption algorithms be a good idea? I'm thinking not since if you encrypt a string with one scheme and decrypt with another then you won't get a valid match. There's more chance for error.
Anyway, any thoughts?
Steve
_________________________
Stevie
|
Top
|
|
|
|
#85826 - 2002-05-31 08:28 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
Hmmm.
The only problem I see with doing this is that if you have someone read your script then run with KiXtart:
$password = $Crypto.Decrypt("4rI92Hrk22pkl")
It's just a hair better than putting in a plain text password. If someone figures out how to read the file from the netlogon share, they may also figure out how to use KiXtart to get the password?
A way around this hmmm? How about: When Encrypting the password, add the expected modify date and name of the script file: [code] ;logonscript.kix ;date 2002/5/31 $encryptedpassword = $Crypto.Encrypt("password")
would encrypt based on the current date and the name of the file. So, after the script's first day in operation, the password would be secure.
Is this feasible?
Brian
|
Top
|
|
|
|
#85829 - 2002-05-31 08:56 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
Steve, this is an idea that Bryce raised before, and that was only discussed briefly, but is there a way to validate the "context" of the process requesting the de-cryption. That is to say, in the ActiveX control, either validate some kind of security token, or somehow ensure that the process making the request is "the login process", know what I mean ? Think that that might be tough for even a non-casual hacker to spoof (don't know) ...
-Shawn
Maybe you/we could ask Ruud how he implemented the @LOGONMODE macro ? Oh yeah, and I guess a potential problem with this idea is that your crypto-activex could only be used in a login script, not in an admin script (which is what I would have used it for) ... would also make it a nuisance to test (eg, has to be in logonmode to work), but that might be a good thing ! [ 31 May 2002, 21:04: Message edited by: Shawn ]
|
Top
|
|
|
|
#85830 - 2002-05-31 09:22 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
Hmm... the whole security problem is why I haven't used encryption before. Sure, it's not a problem for most users, but if the idea is to be really secure, then I would figure you'd want some way to validate in a fairly secure manner.
The reason I proposed using the date is that it would allow some measure of security. Someone could look in a file and figure out how to make a script that decrypts a kixtart encryption.. but if you go off the script creation date and name then they would have to know that the date and name of their file must match, and although it can be done, it's pretty difficult to spoof a modify date.
Lemme think... hmmmm
I have another idea..
Perhaps when encrypting you could have options:
$rc = $crypto.Encrypt($password,$option)
$option could be: 1 - encrypt including modified date of file which would effectively do: $encpass = $crypto.Encrypt($password + @date) and $crypto.Decrypt($password,1) would check the modified date of the .kix file being run and effectively do $password = $crypto.Decrypt($encpass + $dateofkixfile)
2 - decrypt to run only from a script found on a domain controller in the domain the script is run from.
Decryption would only work if the script existed in a netlogon share on a domain controller in the given domain. This could be tested pretty easily.
3 - decrypt to run only from a script found on the given @wksta
4 - decrypt to run only from a script started via a logon process.
Brian [ 31 May 2002, 21:31: Message edited by: BrianTX ]
|
Top
|
|
|
|
#85831 - 2002-05-31 10:26 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
Stevie
Starting to like KiXtart
Registered: 2002-01-09
Posts: 199
|
Excellent points all!
As far as OS compatibility issues, CryptoAPI is all contained within advapi32.dll
Every OS should be fine except 95 but that would have to be double-checked. Maybe Win98 would have some issues as well. Don't know at this point. 4.0 or better would be fine.
Regarding securing the decryption, the problem with using the modified date is that every time you modified the script you would have to update the encryption string.
How about using Created date? That won't change if you modify the script and is harder to spoof than the modified date. The problem with that is it requires an NTFS partition, since FAT doesn't track created date, please correct me if I'm wrong on that.
Just had an idea...
What about if it first checks the "context" of the request, to see if the user is logging on. And if so, go ahead and decrypt. If not, it checks to see if the user is in the Domain Admins group of the current logon domain, or a local workstation admin.
That way, users can only run it while logging on but at the same time admins can use it to run admin scripts, per Shawn's request.
What do you think?
_________________________
Stevie
|
Top
|
|
|
|
#85832 - 2002-05-31 10:47 PM
Re: Is there a need for an ActiveX crypto Kix object?
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
The more that I think about it, the more I don't like the date idea... (even though I came up with it.) Someone could simply change the date on their computer...
Checking the logon process for decryption to work isn't a bad idea, however there is still the (minor) security problem with someone writing their own script (non-kix) to decrypt. The idea of checking if the script is running from the netlogon share on a DC seems workable. You could embed DOMAIN-SPECIFIC information into the encrypted string. (perhaps some sort of unique (not obvious) info that everyone can read but not change on the PDC.) Someone would have to completely hack your activex wrapper to even see what that info was and how it was included.
Brian [ 31 May 2002, 22:48: Message edited by: BrianTX ]
|
Top
|
|
|
|
#85833 - 2002-06-01 03:59 AM
Re: Is there a need for an ActiveX crypto Kix object?
|
Anonymous
Anonymous
Unregistered
|
FYI - Ruud stated to me a while back that tokenizing scripts is high on the ToDo list. I would suspect that it will be part of the next point release, since it ovbiously did not make it into 4.10.
Of course, whatever Ruud does should not be considered high encryption, so perhaps this thread still has purpose...
-Brian
|
Top
|
|
|
|
Moderator: Shawn, ShaneEP, Ruud van Velsen, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Mart
|
2 registered
(morganw, mole)
and 414 anonymous users online.
|
|
|