Jump to content

Encrypt embedded password


Ebola57
 Share

Recommended Posts

Hi communnity

I need to crypt or simply obfuscate a password embedded in my AutoIT script

Local $MyLogin = "login"
Local $MyPassword = "password" <- I need to obfuscate / crypt this

The app. is going to be used on any computer of my firm an need a high level of protection (AES 256 ?)  to preverse it from reverse engenering.

I can't write on user's computer (do this with .ini allready). Also i would like the user not to enter any password on its computer. Something "ready to use"

May you help me how to proceed ?

I allready read topics on that, but didn't really find the way of doing

Regards

Edited by Ebola57
Link to comment
Share on other sites

Did you have a look at the _Crypt* functions that come with AutoIt?

My UDFs and Tutorials:

Spoiler

UDFs:
Active Directory (NEW 2022-02-19 - Version 1.6.1.0) - Download - General Help & Support - Example Scripts - Wiki
ExcelChart (2017-07-21 - Version 0.4.0.1) - Download - General Help & Support - Example Scripts
OutlookEX (2021-11-16 - Version 1.7.0.0) - Download - General Help & Support - Example Scripts - Wiki
OutlookEX_GUI (2021-04-13 - Version 1.4.0.0) - Download
Outlook Tools (2019-07-22 - Version 0.6.0.0) - Download - General Help & Support - Wiki
PowerPoint (2021-08-31 - Version 1.5.0.0) - Download - General Help & Support - Example Scripts - Wiki
Task Scheduler (NEW 2022-07-28 - Version 1.6.0.1) - Download - General Help & Support - Wiki

Standard UDFs:
Excel - Example Scripts - Wiki
Word - Wiki

Tutorials:
ADO - Wiki
WebDriver - Wiki

 

Link to comment
Share on other sites

Yes I did, but feel not skilled enough to turn it into the way I need.
Currenlty running some sample found here, but I don't really understand what I am doing 😕

Meaning, I don't want to do something that taste "safe" but isn't at all 

Edited by Ebola57
Link to comment
Share on other sites

  • Developers

Whatever you do to encrypt, i assume it needs to be decrypted at run time so is always insecure!

Edited by Jos

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

  • Developers

So did you answer the question I raised in my answer for yourself and is the answer Yes?
If so that means that the script has the logic to decrypt the password and thus can be retrieved by reverse engineering the script.

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Link to comment
Share on other sites

@Ebola57, what you are asking is both logically and technically impossible.

but when there's a will, there's a way...

storing the password in your compiled script is prone to reverse engineering, that much is true. storing the password in any form that is available for the script, makes it available for the user as well. if you insist the user must not enter any password, then the "hacker" (whom you want to secure the access from) does not need to, either. this pretty much cripples your security efforts.

the official way of doing this is managing and auditing the permissions on the resource level, not on the client level, same way you do with any network share or print queue in your network. so it isn't your script responsibility anymore to handle the connection, it is the user that is allowed or denied access.

there are however ways to store credentials, that may be acceptable by your security authority (to which i assume you need to adhere). for example, using the Windows built-in credential manager; to my experience, that typically raises no concerns. 3rd-party credential manager app may be acceptable, especially if you have an enterprise-class one already installed. any SSO (single-sign-on) means is probably fine, too. that's on the formality side.

on the practical side, consider this: is reverse engineering really a considerable threat? what is the interest for a hacker to hack your password, and how much time and effort will he invest in doing so? if he does, then - how easy would it be for you to identify illegitimate access and mitigate it? assuming you expect only your script to access the resource, and you know what your script is supposed to do, then identifying access by someone or something that is not your script should not be that difficult.

my advice - have some coffee with your security guy, explain and discuss the issue. he may come up with a completely different approach... i'm certain you'll figure this out together.

P.S. lots of words, no code. sorry 🙂 but that's not a coding issue you have here.

Signature - my forum contributions:

Spoiler

UDF:

LFN - support for long file names (over 260 characters)

InputImpose - impose valid characters in an input control

TimeConvert - convert UTC to/from local time and/or reformat the string representation

AMF - accept multiple files from Windows Explorer context menu

DateDuration -  literal description of the difference between given dates

Apps:

Touch - set the "modified" timestamp of a file to current time

Show For Files - tray menu to show/hide files extensions, hidden & system files, and selection checkboxes

SPDiff - Single-Pane Text Diff

 

Link to comment
Share on other sites

  • 3 weeks later...

@orbs I absolutely agree that managing access on the resource level is the right approach.

 

but I do not agree, that the Windows build-in credential manager is accepteble, as retrieving passwords is not impossible.

Pls have a look at this article: https://sites.utexas.edu/glenmark/2019/10/21/using-passwordvault-with-powershell/

To clean up credential manager I wrote this PowerShell script: (comments / dialoges in German...)

# Step 1: Load the Credentials and PasswordVault assemblies
[Windows.Security.Credentials.PasswordVault,Windows.Security.Credentials,ContentType=WindowsRuntime] | out-null

# Step 2: Password Vault Object erstellen
$vault = New-Object Windows.Security.Credentials.PasswordVault

# Step 3: Was drin? 

if ($($vault.retrieveall()|measure).count -gt 0) { 
	#Dann anzeigen, was alles enthalten ist: (nicht notwendiger Weise alles mit aktiv gespeichertem Password)
	write-host "Windows Password Vault Content:"
	$vault.RetrieveAll() | ft
	write-host " .............................."
	# Step 4: Alles rauslöschen
	$title    = 'Windows User Password Vault komplett leeren'
	$question = 'Alles entfernen?'
	$choices  = '&Ja', '&Nein'

	$decision = $Host.UI.PromptForChoice($title, $question, $choices, 1)
	if ($decision -eq 0) {
		# credential Object erstellen
		$cred = New-Object Windows.Security.Credentials.PasswordCredential
		$vault.RetrieveAll() | %{
			$cred.username=$_.username
			$Cred.resource=$_.resource
			$vault.remove($cred)
		}
		
		# Step 5: Ergebnis kontrollieren:
		$vault = New-Object Windows.Security.Credentials.PasswordVault
		if ($($vault.retrieveall()|measure).count -eq 0) {
			write-host "Windows Password Vault wurde erfolgreich geleert"
		} else {
			write-host "Es gibt noch mindestens einen Eintrag im Windows Password Vault:"
			$vault.RetrieveAll()
		}
	} else {
		Write-Host 'Abgebrochen'
	}
} else {
	write-host "Der Windows Password Vault des angemeldeten Users ist ohne Inhalt"
}

 

Earth is flat, pigs can fly, and Nuclear Power is SAFE!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...