ss3vegeta Posted September 14, 2012 Share Posted September 14, 2012 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. Link to comment Share on other sites More sharing options...
water Posted September 14, 2012 Share Posted September 14, 2012 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 2022-02-19 - Version 1.6.1.0) - Download - General Help & Support - Example Scripts - WikiExcelChart (2017-07-21 - Version 0.4.0.1) - Download - General Help & Support - Example ScriptsOutlookEX (2021-11-16 - Version 1.7.0.0) - Download - General Help & Support - Example Scripts - WikiOutlookEX_GUI (2021-04-13 - Version 1.4.0.0) - DownloadOutlook Tools (2019-07-22 - Version 0.6.0.0) - Download - General Help & Support - WikiPowerPoint (2021-08-31 - Version 1.5.0.0) - Download - General Help & Support - Example Scripts - WikiTask Scheduler (NEW 2022-07-28 - Version 1.6.0.1) - Download - General Help & Support - Wiki Standard UDFs:Excel - Example Scripts - WikiWord - Wiki Tutorials:ADO - WikiWebDriver - Wiki Link to comment Share on other sites More sharing options...
Mechaflash Posted September 14, 2012 Share Posted September 14, 2012 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.” Link to comment Share on other sites More sharing options...
Colyn1337 Posted September 14, 2012 Share Posted September 14, 2012 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. Link to comment Share on other sites More sharing options...
dany Posted September 14, 2012 Share Posted September 14, 2012 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 Link to comment Share on other sites More sharing options...
Kyan Posted September 14, 2012 Share Posted September 14, 2012 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 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 Link to comment Share on other sites More sharing options...
Mechaflash Posted September 14, 2012 Share Posted September 14, 2012 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.” Link to comment Share on other sites More sharing options...
dany Posted September 14, 2012 Share Posted September 14, 2012 @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 Link to comment Share on other sites More sharing options...
Kyan Posted September 14, 2012 Share Posted September 14, 2012 @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 Link to comment Share on other sites More sharing options...
Reg2Post Posted September 14, 2012 Share Posted September 14, 2012 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? Link to comment Share on other sites More sharing options...
Kyan Posted September 14, 2012 Share Posted September 14, 2012 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 Link to comment Share on other sites More sharing options...
Reg2Post Posted September 14, 2012 Share Posted September 14, 2012 http://support.kaspersky.com/kis2013/control?qid=208286049Kaspersky 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. Link to comment Share on other sites More sharing options...
dany Posted September 14, 2012 Share Posted September 14, 2012 and if we want protect program data from user alteration? chunked data in chinese? lolThe 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 Link to comment Share on other sites More sharing options...
Kyan Posted September 14, 2012 Share Posted September 14, 2012 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 Link to comment Share on other sites More sharing options...
JohnOne Posted September 14, 2012 Share Posted September 14, 2012 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. Link to comment Share on other sites More sharing options...
ss3vegeta Posted September 14, 2012 Author Share Posted September 14, 2012 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? Link to comment Share on other sites More sharing options...
JohnOne Posted September 15, 2012 Share Posted September 15, 2012 Will be fine just used as an input, it will not be stored anywhere after the program exits. AutoIt Absolute Beginners Require a serial Pause Script Video Tutorials by Morthawt ipify Monkey's are, like, natures humans. Link to comment Share on other sites More sharing options...
ss3vegeta Posted September 15, 2012 Author Share Posted September 15, 2012 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. Link to comment Share on other sites More sharing options...
JohnOne Posted September 15, 2012 Share Posted September 15, 2012 Or if the techs are competent, you could have the input from gui written to a file and they delete the file after use. AutoIt Absolute Beginners Require a serial Pause Script Video Tutorials by Morthawt ipify Monkey's are, like, natures humans. Link to comment Share on other sites More sharing options...
Mechaflash Posted September 17, 2012 Share Posted September 17, 2012 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.” Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now