Sign in to follow this  
Followers 0
ss3vegeta

security and password handling

22 posts in this topic

Using the example:

; Fill in the username and password appropriate for your system.
Local $sUserName = "Username"
Local $sPassword = "Password"

; Run a command prompt as the other user.
Local $pid = RunAsWait($sUserName, @ComputerName, $sPassword, 0, @ComSpec, @SystemDir)
...

The question is; how safe is this? If it's a compiled exe can someone get the password? Is there a way to encrypt the password and still make it work? I'm looking for some sound advice on the best way to handle passwords securely. I don't want to inadvertantly compromise the security of every computer...

Thanks.

Share this post


Link to post
Share on other sites



An unencrypted Id/Passwort is not safe because a compiled AutoIt script is not safe.

Search the forum for encryption and you will find a few threads.


My UDFs and Tutorials:

Spoiler

UDFs:
Active Directory (NEW 2017-04-18 - Version 1.4.8.0) - Download - General Help & Support - Example Scripts - Wiki
OutlookEX (NEW 2017-02-27 - Version 1.3.1.0) - Download - General Help & Support - Example Scripts - Wiki
ExcelChart (2015-04-01 - Version 0.4.0.0) - Download - General Help & Support - Example Scripts
Excel - Example Scripts - Wiki
Word - Wiki
PowerPoint (2015-06-06 - Version 0.0.5.0) - Download - General Help & Support

Tutorials:
ADO - Wiki

 

Share this post


Link to post
Share on other sites

Let's look at the scenario. From there you can figure out if additional security measures are necessary.

Give some insight on the work environment.

  • How many users are you building this for?
  • All on lan?
  • Any remote users?
  • Do other users have access to the same machine?
  • Do you think your son is the better super saiyan?
  • Are the machines open to the public?
  • For what purpose do you want to allow a user to runas a command prompt as another user?

Spoiler

“Hello, ladies, look at your man, now back to me, now back at your man, now back to me. Sadly, he isn’t me, but if he stopped using ladies scented body wash and switched to Old Spice, he could smell like he’s me. Look down, back up, where are you? You’re on a boat with the man your man could smell like. What’s in your hand, back at me. I have it, it’s an oyster with two tickets to that thing you love. Look again, the tickets are now diamonds. Anything is possible when your man smells like Old Spice and not a lady. I’m on a horse.”

 

Share this post


Link to post
Share on other sites

Using the example:

; Fill in the username and password appropriate for your system.
Local $sUserName = "Username"
Local $sPassword = "Password"

; Run a command prompt as the other user.
Local $pid = RunAsWait($sUserName, @ComputerName, $sPassword, 0, @ComSpec, @SystemDir)
...

The question is; how safe is this? If it's a compiled exe can someone get the password? Is there a way to encrypt the password and still make it work? I'm looking for some sound advice on the best way to handle passwords securely. I don't want to inadvertantly compromise the security of every computer...

Thanks.

The compiled exe will only prevent someone from passively seeing/finding the credentials. To get your coded values, a nefarious person could decompile your script. While this is technically a license violation to decompile the exe, that's never stopped the bad guys before. You can use the obfuscate option to try and scramble your code, but it's not completely impossible for someone to reverse engineer it and still get the data.

The question you really want to ask, assuming you're using local or domain credentials, is this....

Is it easier for someone to hack the password hash stored on the computer with a rainbow table, or decompile your program. If it's easier for someone to hack the hash, you're good. If not, then rethink your process :)

Hope this helps.

Share this post


Link to post
Share on other sites

The question is; how safe is this?

In short: not much. Like said before, the bad guys can still decompile your binary to get this data. Obfuscation adds very little in terms of real security but it's better than nothing. Encryption will be better but only really works if you can effectively hide the key used to en/decrypt.

Best is to separate the two. Use a file to store the password encrypted and then encrypt the file as well with a different key. Bad guys will only see a binary sequence and won't be able to tell what crypt algo was used. They'd still have to decompile your binary for that info, whch means extra work. If you name the file something innocent and place it amongst a few other binary files, they'll have a good goose hunt on their hands.

As for the keys, well how about using a for that?

#include <resources.au3>
#AutoIt3Wrapper_Res_File_Add=hellokitty.gif, 10, HELLOKITTY
; ...
; Get the key from the resource.
Local $sKey = _ResourceGetAsBytes('HELLOKITTY')
; Use (part of) the bytes as a key for en/decrypting.

They can pull resources from your binary but if you'd use an image as a source for key bytes, then it's not very obvious what you're doing and they'd still have to analyze your code.

Best is it to ask the user for credentials and use this simple stuff as the key to en/decrypt the real ones. Added bonuses are that users can make up their own password and use this and that you don't need to store these passwords. Just pass them directly into the _Crypt_* functions and if the function fails, the password they provided was wrong.

Hope this helps.


[center]Spiderskank Spiderskank[/center]GetOpt Parse command line options UDF | AU3Text Program internationalization UDF | Identicon visual hash UDF

Share this post


Link to post
Share on other sites

In short: not much. Like said before, the bad guys can still decompile your binary to get this data. Obfuscation adds very little in terms of real security but it's better than nothing. Encryption will be better but only really works if you can effectively hide the key used to en/decrypt.

Best is to separate the two. Use a file to store the password encrypted and then encrypt the file as well with a different key. Bad guys will only see a binary sequence and won't be able to tell what crypt algo was used. They'd still have to decompile your binary for that info, whch means extra work. If you name the file something innocent and place it amongst a few other binary files, they'll have a good goose hunt on their hands.

As for the keys, well how about using a for that?

#include <resources.au3>
#AutoIt3Wrapper_Res_File_Add=hellokitty.gif, 10, HELLOKITTY
; ...
; Get the key from the resource.
Local $sKey = _ResourceGetAsBytes('HELLOKITTY')
; Use (part of) the bytes as a key for en/decrypting.

They can pull resources from your binary but if you'd use an image as a source for key bytes, then it's not very obvious what you're doing and they'd still have to analyze your code.

Best is it to ask the user for credentials and use this simple stuff as the key to en/decrypt the real ones. Added bonuses are that users can make up their own password and use this and that you don't need to store these passwords. Just pass them directly into the _Crypt_* functions and if the function fails, the password they provided was wrong.

Hope this helps.

nice :D

but if they see where is the encryption function, they also see the variable which lead to the resource, it just adds another step to decrypt the password


Heroes, there is no such thing

One day I'll discover what IE.au3 has of special for so many users using it.
C'mon there's InetRead and WinHTTP, way better
happy.png

Share this post


Link to post
Share on other sites

Moral of the story? Don't hardcode sensitive data ;)


Spoiler

“Hello, ladies, look at your man, now back to me, now back at your man, now back to me. Sadly, he isn’t me, but if he stopped using ladies scented body wash and switched to Old Spice, he could smell like he’s me. Look down, back up, where are you? You’re on a boat with the man your man could smell like. What’s in your hand, back at me. I have it, it’s an oyster with two tickets to that thing you love. Look again, the tickets are now diamonds. Anything is possible when your man smells like Old Spice and not a lady. I’m on a horse.”

 

Share this post


Link to post
Share on other sites

@DiOgO: Yep, it's all more obfuscation and not true security. Like I said, best would be to prompt the user for a throw-away password.

mechaflash213 is right. Try to avoid it in any scenario.


[center]Spiderskank Spiderskank[/center]GetOpt Parse command line options UDF | AU3Text Program internationalization UDF | Identicon visual hash UDF

Share this post


Link to post
Share on other sites

@DiOgO: Yep, it's all more obfuscation and not true security. Like I said, best would be to prompt the user for a throw-away password.

and if we want protect program data from user alteration? chunked data in chinese? lol

Heroes, there is no such thing

One day I'll discover what IE.au3 has of special for so many users using it.
C'mon there's InetRead and WinHTTP, way better
happy.png

Share this post


Link to post
Share on other sites

If an unauthorized user can get a hold of your exe and decompile it what is stopping them from putting a keylogger on the system if you have to type in credentials?

Share this post


Link to post
Share on other sites

If an unauthorized user can get a hold of your exe and decompile it what is stopping them from putting a keylogger on the system if you have to type in credentials?

http://support.kaspersky.com/kis2013/control?qid=208286049

Heroes, there is no such thing

One day I'll discover what IE.au3 has of special for so many users using it.
C'mon there's InetRead and WinHTTP, way better
happy.png

Share this post


Link to post
Share on other sites

and if we want protect program data from user alteration? chunked data in chinese? lol

The throw-away password is used to en/decrypt the password from an external file. Nothing is 'stored' in the program itself. The only thing decompiling will give you is the used cryptographic algorithm. Somewhat useless info without a key and if your key has sufficient bit-entropy, no one will brute-force your encrypted data within reasonable time (i.e while they're still alive).

[center]Spiderskank Spiderskank[/center]GetOpt Parse command line options UDF | AU3Text Program internationalization UDF | Identicon visual hash UDF

Share this post


Link to post
Share on other sites

The throw-away password is used to en/decrypt the password from an external file. Nothing is 'stored' in the program itself. The only thing decompiling will give you is the used cryptographic algorithm. Somewhat useless info without a key and if your key has sufficient bit-entropy, no one will brute-force your encrypted data within reasonable time (i.e while they're still alive).

I need to store the encrypt password, since I'll need to decrypt it later, the one I use is away longer than 8chars, and ti represents more than 83½ Days using the RC5-64 (I think they have other things to do instead of cracking my passwords....)

here's the time/speed list: http://www.lockdown.co.uk/?pg=combi


Heroes, there is no such thing

One day I'll discover what IE.au3 has of special for so many users using it.
C'mon there's InetRead and WinHTTP, way better
happy.png

Share this post


Link to post
Share on other sites

Kaspersky Safe Money? I seem to be missing the point.

If someone can get a hold of a compiled script that you are trying to protect and decompiles it, the user credentials should be the least of your worries.

Yes you are, you are missing the big massive obvious point of the OP wanting to distribute the script he makes.

I never seen them say he wanted to give open access to his hard disk.


AutoIt Absolute Beginners    Require a serial    Pause Script    Video Tutorials by Morthawt   ipify 

Monkey's are, like, natures humans.

Share this post


Link to post
Share on other sites

Wow, this has given me a lot to think about. Thank you for all the advice. This will be used to install software on thousands of computers, but hopefully used by just a handful of techs. All these techs already have the admin username and password, but I'm trying to simplify the deployment... Would it be better to temporarily store the credentials while the program is running by prompting a user for the username and password once? I would assume the answer is yes, but am not sure if there are other potential issues with storing the password temporarily but never writing it to a file. Should it still be encrypted?

Share this post


Link to post
Share on other sites

So just use the standard GUI text box and I'll be fine? It's not a perfect solution, but it's better than introducing a possible security issue. It will cut down n possible entries to just 1, so it should still save a considerable amount of time.

Thanks for the advice, I really appreciate it.

Share this post


Link to post
Share on other sites

If it's on an internal network, you can encrypt the username and pass into a file on the network share. Read it, decrypt it, use as input.

Or if you have access to a MySQL Database, you can store it there encrypted and do the same process.


Spoiler

“Hello, ladies, look at your man, now back to me, now back at your man, now back to me. Sadly, he isn’t me, but if he stopped using ladies scented body wash and switched to Old Spice, he could smell like he’s me. Look down, back up, where are you? You’re on a boat with the man your man could smell like. What’s in your hand, back at me. I have it, it’s an oyster with two tickets to that thing you love. Look again, the tickets are now diamonds. Anything is possible when your man smells like Old Spice and not a lady. I’m on a horse.”

 

Share this post


Link to post
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
Sign in to follow this  
Followers 0