Script Package Security
Forum rules
DO NOT POST LICENSE NUMBERS, ACTIVATION KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.
Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
DO NOT POST LICENSE NUMBERS, ACTIVATION KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.
Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
Script Package Security
Hello
once again.1.I have
a question in regards to the Script Packagers ability to use different
credentials. For instance if you use RunAs user and supply credentials to the
compiled .exe
Check
the box: Encode scripts with the Microsoft Script Encoder, and you digitally
sign the package itself. Is it possible for the .exe to be decompiled in such a
way that the account credentials can be recovered in plain text, thus causing a
compromise of the account?
2. If
it is possible to decompile the .exe in such a way that you can recover the
credentials do you feel this extremely difficult to do so, or would rate it
more at a medium level?
The
question is aimed, because I would like to make use of the feature, but I need
to know exactly what I am getting myself into before doing so. I am always very
wary about having credentials stored anywhere, least of all when I do not know
all the security measures deployed.
Thanks! (Sorry if this has been asked before I did a search, but didn't see any specific post around this topic)
jefcrawf2012-03-18 20:14:02
- Alexander Riedel
- Posts: 8479
- Last visit: Thu Mar 28, 2024 9:29 am
- Been upvoted: 37 times
Script Package Security
This blog post should answer most of your questions:
http://www.sapien.com/blog/2010/01/19/h ... -packages/
No encryption is unbreakable, but as it stands, your code and credentials inside a SAPIEN Script package are safer than if coded inside a .NET application or C++ application without special treatment.
The script encoder is not effective for anything but VBScripts or JScripts that use temporary files. It is also easily circumvented with utilities found online. So in my opinion you might just not bother. There is no switch to disable the built-in encryption in case you are wondering.
http://www.sapien.com/blog/2010/01/19/h ... -packages/
No encryption is unbreakable, but as it stands, your code and credentials inside a SAPIEN Script package are safer than if coded inside a .NET application or C++ application without special treatment.
The script encoder is not effective for anything but VBScripts or JScripts that use temporary files. It is also easily circumvented with utilities found online. So in my opinion you might just not bother. There is no switch to disable the built-in encryption in case you are wondering.
Alexander Riedel
SAPIEN Technologies, Inc.
SAPIEN Technologies, Inc.
Script Package Security
Alexander, That would do it. I guess the only question that would remain is that has the encryption level changed to a higher standard in 2011, or are you still using the same level as you did in 2009? Thanks!
- Alexander Riedel
- Posts: 8479
- Last visit: Thu Mar 28, 2024 9:29 am
- Been upvoted: 37 times
Script Package Security
No, it remains unchanged. We had no reason so far to change it.
Alexander Riedel
SAPIEN Technologies, Inc.
SAPIEN Technologies, Inc.