ShellExecute and passing of password

[Mark Williams 14]

I would like to shellexecute one app from another. Both apps require username and password. I would like to be able to pass the password securely from one app to the other.

 

Obviously, command-line parameters are out and I would imaging a memory mapped file will also not be secure.

 

Is there any relatively simple and secure way of achieving this.

[David Heffernan 2345]

You probably need to decide what you want to be secure from. As it stands it's probably impossible to give you specific advice. 

[Fr0sT.Brutal 900]

Consider using pipes, I believe they're a bit harder to sniff than command-line params. Of course you'll need full-featured CreateProcess for this. Or you may encrypt your data and send it via any channel. You can even implement full TLS handshake.

[aehimself 396]

Afaik ShellExecute returns nothing, it does not even confirm if the command line was executed or not. By sticking to it you have no other options but command line parameters, best case scenario is to encrypt the password and decrypt it from the second app. You can check the running processes after ShellExecute and grab it's handle for data transfer but this introduces a lot of unnecessary checks, like timeout (don't wait for the second process until you can find it, what if it did not even launch), did it already initialize and ready to accept data?

 

If you use CreateProcess and map the stdin and stdout, you can make your first application to "type in" the user name and password to the second one and read back the output to verify if authentication was successful.

 

However if both applications are written and managed by you, move the worker method to a .DLL and make the first and the second application to load and use it. You also have to validate the legitimacy of the library, though. Or to a helper unit, and do not even include a secondary file.

 

However, external files will always pose a major security risk, especially if they need to share sensitive information. It's really easy to put a malicious .EXE file in place of yours (even if it's running) just to steal the credentials.

[Mark Williams 14]

Thanks to all. I probably need to rethink my approach.

[timfrost 78]

An encrypted password on the command line, decrypted by the second app, may not help security very much; if an attacker sees it in the command-line of the second process, they can send the same password later to the second process.  Seeding the encryption and decryption with for example the current process ID makes this exploit harder, but not impossible.  Everything suggested here has to be interpreted in the light of how secure you actually need all this to be, which we do not know.

[Fr0sT.Brutal 900]

Sure, every security measures should be estimated from the point of what you want to achieve and what skill level of a hacker you want to withstand. In general, every local solution is hackable by design; and not every solution with remote server is non-hackable.

Edited November 5, 2019 by Fr0sT.Brutal

[Attila Kovacs 629]

If you can alter both apps I would create an encrypted file and pass it to the other as parameter.

 

[Mark Williams 14]

Thanks again. I have decided to go down a different route altoghether and instead of having separate apps, house them all within the same app.

[Turan Can 3]

I assume it's on the same computer.
1- And if you want to do the same user.
The easy way. Encrypt the password and sendmassage (..); you send it with.

2- If you are going to communicate between programs in different users, you should use namepipe.

[lisichkin_alexander 0]

It’s not clear what you want to do, I can suggest using Windows API function

CreateProcessWithLogonW =
    function(const lpUsername: PWideChar;
    const lpDomain: PWideChar; const lpPassword: PWideChar;
    dwLogonFlags: DWORD; const lpApplicationName: PWideChar;
    lpCommandLine: PWideChar; dwCreationFlags: DWORD;
    lpEnvironment: Pointer; const lpCurrentDirectory: PWideChar;
    lpStartupInfo: PStartupInfo;
    lpProcessInfo: PProcessInformation): Boolean; stdcall

[Remy Lebeau 1397]

On 11/4/2019 at 10:40 AM, Mark Williams said:

I would like to shellexecute one app from another. Both apps require username and password. I would like to be able to pass the password securely from one app to the other.

Then DON'T pass the password on the command-line, use an IPC mechanism instead, such as a pipe, or even anonymous shared memory (coupled with this), or if you really want to be sneaky, there is an undocumented way to pass arbitrary data (up to 65531 bytes) to a child process via CreateProcess() (be careful though, it doesn't work under WOW64).

 

[Fr0sT.Brutal 900]

Anyway if a user has admin rights in your system, he is able to dump process memory or even debug it. If he hasn't, encrypt your data and transfer it in any manner.

[aehimself 396]

On 2/27/2020 at 8:53 AM, Fr0sT.Brutal said:

Anyway if a user has admin rights in your system, he is able to dump process memory or even debug it.

For way too long this is haunting my coding experience. A simple Hello World is becoming thousands of lines due to encryption, obfuscation and filler NoOps. At the end of the day you are only making the life of the attacker harder. Never impossible.

On 2/27/2020 at 8:53 AM, Fr0sT.Brutal said:

If he hasn't, encrypt your data and transfer it in any manner.

True and not true. If password is sent as a parameter and the application is stored in %APPDATA% for example, you can replace the secondary .EXE to just dump the password. Command line passwords are a really bad idea from this perspective.

[Fr0sT.Brutal 900]

2 hours ago, aehimself said:

True and not true. If password is sent as a parameter and the application is stored in %APPDATA% for example, you can replace the secondary .EXE to just dump the password. Command line passwords are a really bad idea from this perspective. 

Like anything in protection field: one has to estimate how much efforts he is ready to put into protection and how much efforts an attacker will have to make to crack the protection and will it ever worth it. Of course, estimation must include app environment as well. We know nothing about the conditions topicstarter has so it's useless to just guess. Probably xor-ing credentials with a key contained inside the app binary will suffice his needs.

[Lars Fosdal 1792]

If you have Azure AD, using PowerShell and storing credentials in Azure Vault is a good alternative to passing credentials on the command line.