| Stevie |
| (Starting to like KiXtart) |
| 2002-05-31 05:35 PM |
Is there a need for an ActiveX crypto Kix object?
|
Hi all,
Just wanted to get a general sense if there was a need for an ActiveX crypto wrapper for KiX so that passwords etc. could be safely included in a kix script?
The functions I was thinking of writing would be encrypt/decrypt functions and a hash generator.
However, if Shawn or someone else has already written something that provides this functionality it would be a waste of time to pursue.
Otherwise, I could probably bang something out fairly quickly. Let me know what you all think.
Regards,
Steve Behrns
Shawn
|
| (KiX Supporter) |
| 2002-05-31 05:46 PM |
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Steve,
LOL, I had the very same thought as you. No - I haven't written one and im not aware of one. But when I was doing some thinking on this, I was trying to decide wether an ActiveX control or a simple commandline util would be more usefull. Specifically, the nuisance of having to download and register the control on every machine (not to mention any NT security issues with registering using normal domain user accounts).
Was thinking that a commandline util that would prompt for a password, then spit out some kind of ASCII encrypted key would be kinda neat. But the problem with commandline utils is that its pretty darn tough (risky) to get the password back into your script (ie, through file or registry).
So yeah - maybe the ActiveX control is the easiest and most secure way to go. I think most folks would find this usefull, yeah ?
-Shawn
| Stevie |
| (Starting to like KiXtart) |
| 2002-05-31 06:13 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Now that you mention it, a command-line tool would be a lot easier to use. But you're right in that the tricky part is getting the return value from the command-line. There's really no "safe" place to put it.
So assuming the ActiveX object is the safest thing to go with, can you think of any other methods or properties that should be put in there besides the ones previously mentioned?
| Les |
| (KiX Master) |
| 2002-05-31 06:23 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
What's wrong with encrypting the entire script (KiXCrypt)? Seems to me that's the easiest route.
ELSE
What about existing DLLs or OCXs that may already exist. Do they have published APIs?
|
Shawn
|
| (KiX Supporter) |
| 2002-05-31 06:24 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
I think you pretty much nailed it Steve, key in, password out ? But I was hoping that a couple of other members might offerup some feedback, specifically Richard Howarth he wrote that KiXCrypt utility.
ps. How will you implement the encryption algorithm (if you do proceed) ? Home-grown ? Crypto-API ? Was your thought to have some kind of ASCII encrypted key ?
-Shawn
|
Shawn
|
| (KiX Supporter) |
| 2002-05-31 06:28 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Les - I think Steve has a valid idea - not everyone wants to bundle-up their scripts into an executable. I know that concept wouldn't fly too well around here - our scripts run long enough as it is - let alone unbundling the scripts, running, then deleting them again ... the question really becomes - would a crypto-activex control be usefull ? Got any idea ?
-Shawn
[ 31 May 2002, 18:29: Message edited by: Shawn ]
| BrianTX |
| (Korg Regular) |
| 2002-05-31 06:30 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
It sounds like a great idea to me! I'm not sure about the implementation, though..
Brian
| Stevie |
| (Starting to like KiXtart) |
| 2002-05-31 07:55 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
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
| BrianTX |
| (Korg Regular) |
| 2002-05-31 08:28 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
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
|
Shawn
|
| (KiX Supporter) |
| 2002-05-31 08:42 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Steve,Brian,Les to your collective knowledge, are there any platform dependencies that may be an issue here ? eg, Windows 95 only supports older type of encryption vs NT5 supports newer version ? Imagine you would want to account for that if hardcoded a particular level, say, set it to a common denominator ?
[ 31 May 2002, 20:48: Message edited by: Shawn ]
|
Shawn
|
| (KiX Supporter) |
| 2002-05-31 08:47 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Brian, good points ! This wouldn't stop somebody from grabbing the key and using crypto-api themselves. I wonder how Richard Howarth manages this (potentially same problem there ?) ... is it feasible to run KiXcrypt and "steal" the decrypted script out of %temp% ?
Would a crypto-activex control be "easier" to crack than KiXcrypt ?
-Shawn
|
Shawn
|
| (KiX Supporter) |
| 2002-05-31 08:56 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
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 ?
![[Wink]](images/icons/wink.gif){kind=icon}
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 ]
| BrianTX |
| (Korg Regular) |
| 2002-05-31 09:22 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
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 ]
| Stevie |
| (Starting to like KiXtart) |
| 2002-05-31 10:26 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
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?
| BrianTX |
| (Korg Regular) |
| 2002-05-31 10:47 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
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 ]
| **DONOTDELETE** |
| (Lurker) |
| 2002-06-01 03:59 AM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
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
| Stevie |
| (Starting to like KiXtart) |
| 2002-06-01 05:36 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
After some preliminary research I'm at a total loss in figuring out how to programmatically determine if the code is being run during logon or afterwards.
I'd love to find out how Ruud is using the @LOGONMODE macro.
Anyone have any ideas?
|
Shawn
|
| (KiX Supporter) |
| 2002-06-01 05:49 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Well. hopefully Ruud may read this message, else we may be able to flag him down in the Beta or Suggestions forum, else I would just simply send him an email and politely ask how he did it. He's very helpfull and totally approachable on matters such as this (imho).
-Shawn
| Stevie |
| (Starting to like KiXtart) |
| 2002-06-03 06:43 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Since I don't have his email address and I'm not sure he would want it plastered on the messageboard, if someone could ask him about this we can get the ball rolling.
|
Shawn
|
| (KiX Supporter) |
| 2002-06-03 07:45 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Your right - would never plaster Ruud email on the web, I'll send him off a kindly request.
-Shawn
|
Shawn
|
| (KiX Supporter) |
| 2002-06-03 07:56 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
ok - done !
| Stevie |
| (Starting to like KiXtart) |
| 2002-06-03 08:00 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
You da man!
| jtokach |
| (Seasoned Scripter) |
| 2002-06-05 08:49 PM |
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Steve, checking to see whether the user is in the admin or domain admin group is invalid, b/c a normal user would not be allowed to run the admin script your trying to run thereby foregoing the effort.
It seems as though this process has been moved to running the script from a DC. If that is the case, then rather than checking the process, would it not be feasible to place the decryption algorithm in a folder and assign the everyone(G) execute rights only? This would eliminate the need for a dll or ocx, however, I guess this method may be suspect to eavesdropping as mentioned above...
| Stevie |
| (Starting to like KiXtart) |
| 2002-06-06 07:48 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
The admin check is just to allow admins to run a script outside of the logon process. Since a user doesn't normally run a script outside of the logon process it won't matter to them.
The user will only be able to run the decrypt function while logging on. That's to prevent them from just writing their own script to decrypt it later.
|
Richard H.
|
| (KiX Supporter) |
| 2002-06-07 10:52 AM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
At Shawns behest I'll throw my tuppence in...
KiXcrypt is not an absolutely cracker proof mechanism, as at some point in the processing the script file is exposed. It is a very short period, but it is there.
The password problem is solved with KiXcrypt by passing the password as a command line parameter, something like:
code:The password never appears in the script, only the variable name. If someone did manage to rip the script, they still wouldn't have the password.kix32.exe logon.kix $Password=secret
Back to the topic...
There are a couple of solutions I can think of, depending on what you want to do. File timestamps are easily faked - a copy of touch.exe ported from Unix will do the job nicely.
You could write the entire command that needs the password into the object, then you would never need to expose it back to the script. Something like:
code:If you need the password in the script, the securest method of ensuring it isn't hijacked is to use the MD5 hash of the script to peturb or salt the algorithm used to encrypt/decrypt the password. Of course the decryption routine will need to be able to securely identify the script that it is called from to be able to read it and generate the hash.$Crypto=CreateObject("KixFunctions.Crypto")
$Crypto.Password="lshdf872lads"
$ret=$Crypto.Use("S:","\\SERVER\SHARE","Administrator")
The encrypt/decrypt routine will ignore line 1 when generating the hash, as that is where you'll set the password.
One other thing to say of course is that if you use the password to execute another program (su.exe for example) you are asking for trouble unless you take precautions.
A cracker will simply replace the su.exe with a trojan which records command line parameters and environment variables then calls the real su.exe. Chuck in a copy of postie or blat to send the info to a Hotmail account and some code to copy itself to administrative shares on other machines in the domain. This can run silently capturing passwords for as long as he wants, and if he's lucky will spread itself through your entire company without being detected.
|
Shawn
|
| (KiX Supporter) |
| 2002-06-07 02:36 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
ah, ok, so this is getting interesting ... this line here:
code:Where would that normally be kept ? Hardcoded in user manager for domains, or tucked away in a bat file somewhere ? Because, to be honest, I can imagine a couple of ways for a domain user to snoop around that, no ?kix32.exe logon.kix $Password=secret
-Shawn
|
Richard H.
|
| (KiX Supporter) |
| 2002-06-07 02:48 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
In the case of KiXcrypt you define it when you create the crypted version of the script. The command line is encrypted within the executable, and is used to start the interpreter - it is never actually written out anywhere.
A full example of a command line to encrypt a script with a password passed via the command line is:
code:This creates an executable which when run will extract and execute the logon.kix script, passing the password "mypassword" in as the variable $Password.kixcrypt logon.kix kix32.exe %s $Password=mypassword
You can do a similar thing with batch files. To pass a password to an encrypted batch file:
code:Now, the password "mypassword" is available in the batch file as positional parameter "%1".kixcrypt -k logon.bat %s mypassword
The "-k" switch stops KiXcrypt adding the KiXtart commands to delete the file, which if course would cause an error in a batch file.
The drawback is that if you change the password you need to recreate the encrypted script.
|
Shawn
|
| (KiX Supporter) |
| 2002-06-07 02:55 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
wow - ok - I'm on the same page as you now. Very clever ... so the only time your ever really exposed is during that brief period of de-compression, and then again, the password is never really exposed in the script anyways (its a $var) ... wow ...
|
Richard H.
|
| (KiX Supporter) |
| 2002-06-07 03:16 PM |
Re: Is there a need for an ActiveX crypto Kix object?
|
You can obfuscate it further if you like.
How about:
code:You can then EXECUTE($SecretCode) in your script, an no-one will know what it was, heh.kixcrypt logon.kix kix32.exe %s $SecretCode="USE S: \\server\share /user:secretuser /password:mypassword"
However we're drifting away from the original topic, which was far more interesting.
[ 07 June 2002, 15:17: Message edited by: Richard Howarth ]
| BrianTX |
| (Korg Regular) |
| 2002-06-07 05:10 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Hmm. you make good points, Richard.
I like the idea of never passing the password back to the script. However, in this case there would be limited functionality as to what the Crytpo object could be used for. I can think of a few methods that might be handy.
Starting with:
$Crypto=CreateObject("KixFunctions.Crypto")
$Crypto.Password="lshdf872lads"
1. mapping shares
$ret=$Crypto.Use("S:","\\SERVER\SHARE","Administrator")
2. running a program that requires different permissions
$ret = $Crypto.Run("file.bat","domain1\Administrator")
3. Accessing an object that might otherwise not be able to be accessed
$ret = $Crypto.GetObject("....{whatever}....")
The only problem I see with doing it this way is that it is only secure if it can only be run in the context of a logon script. Otherwise, what would prevent someone from simply writing their own script and copying in the encoded password to do whatever it is they wanted to do with full admin rights? Also, it may be helpful if the info was domain-specific...
Brian
| Stevie |
| (Starting to like KiXtart) |
| 2002-06-10 05:24 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
On the topic of someone replacing an executable with a Trojan Horse, since this is not airtight anyway, it is incumbent upon network administrators to place these apps in NETLOGON or a subdir with read only access for the users. If that is done, they won't have the permissions to replace the files in question.
Still, though, I keep coming back to a method of encryption that doesn't rely on packaging the script into an executable. Certainly not as a replacement but as another option for admins out there.
The big sticking point seems to be how to stop the users from decrypting the passwords themselves.
I currently have an object working on my testbed
that I think satisfies this. I'm sure you'll all let me know how reasonable (or unreasonable) this sounds.
As mentioned earlier, encryption can only be done if you are a member of the Domain Admins group.
Decryption only works if:
-You are a member of Domain Admins
-You are currently logging on (via logon script) to the domain (I finally cracked the nut on this one)
Further, the key to create the encryption is based in part upon the SID of the domain itself. Therefore, someone couldn't create their own "dummy" domain, and as a domain admin, decrypt the password. Since the decryption is based off information tied directly to the original domain. (I'm using more than just the domain SID so spoofing the SID will not work).
Having said all that, how would this be circumvented? Of course there are probably a dozen ways to do it but what would the easiest exploits be? Or have we decided that there is no way to safely implement this?
Steve B
| BrianTX |
| (Korg Regular) |
| 2002-06-10 05:42 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
My thought on how to prevent spoofing of the domain SID (and your other information), would be to have a server-side service running that would be able to send a unique code to the .dll assuming that .dll was called from the logon script. It could be seeded by a number chosen randomly when installed, or by one chosen by the person installing the service.
Brian
|
Shawn
|
| (KiX Supporter) |
| 2002-06-10 05:57 PM |
|
|
|
Re: Is there a need for an ActiveX crypto Kix object?
|
I like where this heading Steve, but there is one common scenario we forgot to mention - when a domain admin writes an admin script to hand-off to say, a help desk, the help desk folk wouldn't have domain admin access (maybe) - but like Howard Bullock might remind me - probably just splitting hairs here.
-Shawn
oops - someone has a long line ... but since I begged Richard to comment - what the hell eh ?
[ 10 June 2002, 17:59: Message edited by: Shawn ]
| Stevie |
| (Starting to like KiXtart) |
| 2002-06-10 06:37 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Brian's idea is more secure since you're putting custom data into the domain information. Which begs the question: does it provide enough additional security to justify the administrative overhead associated with adding an additional service onto the domain controllers? vs. using existing SID info? Thoughts?
Shawn, I thought about whole local vs. domain admin thing. If it decrypts for someone with local admin rights then anyone with admin access to their own machine (which would have to be a member of the domain in question) could decrypt the data. IMO, it's better to require domain admin access. It's a lot harder to come by. The security benefits outweigh the cost of not being able to give domain maintenance scripts to local admins.
| BrianTX |
| (Korg Regular) |
| 2002-06-10 08:19 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
You could possibly have multiple modes of use. One mode may allow anyone to use it generically, yet another mode may require domain admin privilege and/or server service and/or logon script privileges. These can be determined by passing a second parameter.. so you can customize just how secure you want it to be.
Brian
|
Richard H.
|
| (KiX Supporter) |
| 2002-06-11 10:09 AM |
Re: Is there a need for an ActiveX crypto Kix object?
|
If you are going to use the service/SID method then there is little point in passing encrypted data.
The scheme isn't portable, so you can make the process much more simple and lightweight by just asking for the data you require. The local (login) part of the connection will provide the security credentials and the service will simply return the data asked for.
You would use is like:
code:or even:$sPassword=$oSecureLink.getPassword("ADOMAIN\SecureUser")
Use S: \\SERVER\SHARE /user:ADOMAIN\SecureUser /password:$sPassword
code:The data repositry is of course not visible to anything except the server service.Execute($oSecureLink.getFile("Secret.kix"))
For simple password encryption I'd favour using the MD5 hash of the calling script as the salt or seed. The hash will ensure that the script has not been tampered with, so no-one can hack the script or create their own to decrypt the password.
You would use it like this:
1) Create a script called login.kix
code:2) Generate the encrypted password using the script as the seed/salt:use s: \\server\share /password:$oSecure.decrypt("$sPassword")
code:This outputs "HIhdohs78721lksdf1nc0as765"passwordgen login.kix mypassword
3) Execute the script:
kix32 login.kix $sPassword=HIhdohs78721lksdf1nc0as765
The decrypt routine will read in the script file to generate the hash to use in the decryption routine. If someone changes a single character of the script file the hash will change and the password returned will be garbage.
The only tricky bit is securely identifying the script file so that you can read it in the decrypt routine.
The major benefit is that you don't require the server or even access to the domain - you can run the script anywhere including stand-alone so long as you have access to the decrypt object. That means you can access local password protected objects like ODBC databases or whatever.
| BrianTX |
| (Korg Regular) |
| 2002-06-11 09:21 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
Am I misunderstanding you, Richard?
Is this much different than having a service that simply gives different credentials to a program or command being run in KiXtart? Kind of like a "hidden" SU?
$Object.Execute("kixtart command line","domain\administrator")
Basically specifying the permissions you want to use to execute a KiXtart command. (How to implement something like this sounds tricky, though.)
Brian
|
Richard H.
|
| (KiX Supporter) |
| 2002-06-12 10:11 AM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
quote:Maybe. Maybe not.
Am I misunderstanding you, Richard?
quote:It is more like a secure data server
Is this much different than having a service that simply gives different credentials to a program or command being run in KiXtart? Kind of like a "hidden" SU?
The point that I was making was that if you are going to tie the solution to running on a specific domain during login, passing the data to a service to decrypt it is redundant and actually lessens security as the encrypted data is visible.
The data *might* be a domain password, but it could be anything you don't want people to see.
| BrianTX |
| (Korg Regular) |
| 2002-06-12 10:32 PM |
|
Re: Is there a need for an ActiveX crypto Kix object?
|
I think I see your point... (emphasis on I think! lol).
We can have a service running by which the kixtart script can pull info from provided the script has been "validated" by the service. Is that basically it?
Brian