How to protect password in script

[Tralveller]

Hello at all,

I wrote a script and would like to add a password to it.

Compiling to an application is a "possibility to protect" the password against simple checks, but may there's a way to protect the password "more secure".

So I checked online some options and found during my seach the Crypt.au3 including _Crypt_DeriveKey, _Crypt_EncryptData, _Crypt_DecryptData, but also after the whole day I did not understand how to use this functions

The only thing I could understand is that it would be possible:
- To fix something like the hash of secret password into script, which would be protected by an encryption key
- The encryption key is generated by another password as a Hash
- The encryption key is generated by another password of it's hash
- Only if the other password was correctly given as an argument while command line start, the hash of secret password can be decrypted back to plaintext and used

But I didn't understand until now:
How to create the first script which creates the hash of secret password (protected by encryption key generated by another password as a Hash), which I can export e.g. to an .ini file
How to create the second script which takes the given argument to decrypt secret password which from .ini file back to plaintext

I read a lot about "there is no maximum secret way to protect passwords in scripts". I could understand the reason so far, so I prefer to do not start a discussion about that here

Do someone have an simple example for that?
Or may there's another way to "protect the secret password" more efficient, cause may I'm on completely wrong way?

Thanks a lot for any help
Kind regards
Tralveller

[kaisies]

There are others on this board who could be much better experts - but I did a fair amount of research on protecting/password protecting a script a while back when I completed a project that took triple digit hours to complete.

The short answer is, there isn't.  Here is the best & easiest solution I found:

Store a MD5 Hash of the expected PW.  You can add a Salt to it, but it has to be the same every time, to the PW before Hash.  For me, I had a unique 3 digit # at every computer (500+) that I sent it to, so I pre-compiled all 500 Hashes and salt (each salt was unique!, yay for rainbow table protection!) and store them in the script.  I had the luxury of being the Admin on all machines as well, this wasn't a "public" script, but something that I did want to protect, and protect non-IT users from using.

Prompt for a password on program open (or cmd line run).  Hash+Salt that, then compare to your Pre-compiled value.  If they match, program continues.  If they don't it fails.

It is TRIVIAL, and I mean 100% cakewalk to remove any solution to protecting your program through some means of authentication prior to use.  NO METHOD will prevent this from someone that wants to use your program & is semi-competent.  The best you can do, is protect your passwords (or in my case, licenses keys) from being stolen, and a hash+salt can do this.  UNLESS a rainbow table exists for it, which is why a random salt (8 char or so + symbols) is used.

 

If you'd like my auth code, I can post it this weekend perhaps, if you don't get anywhere.

[RTFC]

CodeCrypter with keyID=1 provides password-based encryption, although a combination with target machine-specific features would be more secure. Please consult the FAQ and remarks in source headers for more info.

[Tralveller]

@RTFC: Thanks for your feedback.

That seems to be a really greate tool.

After a lot of time to check how to use this and a few attempts I was not able to use the encrypted script.
By selecting KeyID=1 I get the error message "Error: $CCkey[1] and $decryption_key are BOTH empty, providing nothing to encrypt with." Adding in Tab "Encrypt" => Decryptor twice the number "1" the script makes variables unreadable.

Also trying different other option/combinations I wasn't able to create a running encrypted script.

Kind regards
Tralveller

Edited November 30, 2018 by Tralveller

[Nine]

you may want to look at the UDF Crypt Management found in autoit help file...

[Tralveller]

On 30.11.2018 at 9:38 AM, RTFC said:

CodeCrypter with keyID=1 provides password-based encryption, although a combination with target machine-specific features would be more secure. Please consult the FAQ and remarks in source headers for more info.

I checked options for usage.

The most simple way is to use CodeCrypter tool on command line like:
START /WAIT /MIN "" "codecrypter.exe" /i"My_Script.au3" /e /q

With this I can encrypt mostly the password. Sometimes the password was still visible in plaintext, but for this case I repeat the codecrypter command.

I also checked ohter command line options, stored in codecrypter.au3 and tried to use /e /o.
After that during Code check for compiling was failed with "Syntax error".

So I check the CodeCrypter.ini and available options and changed:
MCF_OBFUSCATE_VARS=True => After perform codecrypter during Code check for compiling was failed with "Syntax error".
MCF_TRANSLATE_VARS=True => After perform codecrypter during Code check for compiling was failed with "Syntax error".

Following line was already added to autoIt script:
#include <MCFinclude.au3>

Is it possible to encrypt, confuse or other way:
- variable names like $Password=_MCFCC("0xE499FF42C70127F2FB",3)
- string from commands like "ConsoleWrite("This is a Text in command line output" & @LF)"

Kind regards
Tralveller

Edited December 1, 2018 by Tralveller

[RTFC]

Okay, first off, I would strongly suggest you use the CodeCrypter user interface to get acquainted with the tool's capabilities; command line options are only there to enable automation once you've figured out exactly which settings you wish to use, and thoroughly tested that the resulting encrypted source performs normally. So run Codecrypter from Scite, and without cmdline arguments.

Secondly, password-based encryption (keyID=1) requires you to tell Codecrypter what the expected password is to be before your plaintext source is encrypted. So under the "Encrypt" Tab, immediately below the "Single Key" ID definition box (where you specified "1" for key ID=1), there's a button called "Decryptor". Press it, and you'll get an input screen stating the current password = "[nothing]. password to be queried". You have to replace that with your chosen password, which you enter twice (in the boxes "Enter new expected return" and "Please confirm by retyping"). Click Ok, goto Main Tab, tick "Encrypt" and press "Run". (This assumes you've added MCFinclude.aur at the top of your source, ran CodeScanner successfully to generate the MCF subdirectory, and created the MCF0 file.) More generally, this is how you define any expected response other than produced through a direct call in your encryption environment, for example, a hardware ID for the target machine if it's different from the one you're working on now).

Thirdly, Codecrypter cannot encrypt variables, but it CAN obfuscate them so they cannot be identified easily by human readers. Just tick the "Obfuscate" box above "Encrypt" on the Main Tab, and tick the "Variables" box under the "Content" Tab. Function names can also be obfuscated (likewise optional).

Regarding string encryption, this is controlled through the "Encrypt content" boxes under the "Encrypt" Tab. "Phrases" = source code (function calls, evaluations, etc), whereas "Strings" = all text in quotes. Each of these can be switched on/off individually.

To get the hang of this tool, maybe try it first on a simple script like "Hello world," switching various Codecrypter options on and off one at a time, and studying the resulting output.

[Tralveller]

Thanks for your feedback.

Ok, your description makes me happy once in so far, cause I have already done it correctly before, perfect

But still:
As soon as I enable in "Main" tab "Obfuscate" after CodeCrypter is finished I can't compile the au3 file.

When I disable "Obfuscate" and "Run" again only with encryption settings it works.

What I doing wrong?

Sorry and many thanks
Tralveller

[RTFC]

Looks like you're running into CodeCrypter's limitations in supporting objects. From your screenshot it seems to me that the object variable itself gets obfuscated, but the object-method calls are not. The easiest fix would be to find $oProperty in the variablesUsed.txt list (in the source's CS_DATA subdir), and restore it in the variablesNew.txt list (same line nr). This would of course leave this variable in plaintext. There's no easy solution for this, I'm afraid.

Technically, object methods are considered calls, i.e. encryptable phrases. So in this case I would skip obfuscation and ensure both strings and phrases are encrypted; in that case both the content of the initial WMI query and the methods called thereafter to retrieve data should be secure.

Edited December 1, 2018 by RTFC