CODEWITHSUNDEEP
c#securityauthenticationencryptionhash
SammyG
SammyG

Reputation: 299

Best approach to this authentication/encryption scenario

My scenario (dumbed down):

Added for clarity: App1 is a HTML page with a CUSTOM URI. App2 is a C# console based program

I have a application that will launch another application.

So we have App1 and App2.

App2 cannot communicate back to App1 and App1 can only launch App2 with a piped command.

I would like to send some sort of authentication string or hash from App1 to App2 which App2 checks and agrees is correct, if it is correct it will continue to launch itself.

My current method in my mind is as follows:

Have a GUID type sting e.g. {25892e17-80f6-415f-9c65-7395632f0223} which is know by both programs. It is hashed in sha256 and sent. App2 checks the hash. and decides what to do based on the outcome.

From what I have read, SHA256 would only be cracked in a timely manner if they had a rainbow table (made from a dictionary) and checked it on that. However I surely a GUID type string like above wouldn't be in said dictionary so would make it secure enough?

What would be the bets approach to this scenario ?

Upvotes: 0

Views: 52

Answers (2)

SilverlightFox
SilverlightFox

Reputation: 33538

The best approach for this is to secure the machine itself.

Run the server for the sole purpose of running these application. If the server is not multi-user, there is no threat that App2 can be maliciously launched. You can even set ACLs so that only the user account that App1 runs as has permission to execute and read App2.

If you're trying to guard against an attacker that has gained remote code execution to this server, then you should concentrate your efforts in harding the system and App1 so that any vulnerabilities are found and fixed prior to deployment.

Upvotes: 0

VoidStar
VoidStar

Reputation: 5421

Since you mentioned that that your application can launch the child application, you should communicate via an inherited handle to minimize the risks associated with more open types of IPC. Makes sure to use an unnamed object; a locally created pipe should be fine. You can use DuplicateHandle (which you have to pInvoke from C#) to create an inheritable handle. You can pass the handle value to the child by any means necessary-- even the command line to launch the child, and it would still be secure, because the handle value is meaningless to all other processes.

The only remaining problem is making sure they binaries themselves are what you expect. You should sign your binaries with a strong name. You should be able to read back the key from any assembly with

Assembly App2 =...
App2.GetName().GetPublicKey();

However, it is somewhat difficult to set up both to authenticate each other in this manner. Is it really necessary to ensure the parent app is unmodified? If an attacker has modified the parent app, they can likely do anything they want to your program anyway. You could try strong named assemblies... they make modification of either App1 or App2 difficult, but it's a beatable scheme because an attacker can basically resign the whole assembly. But if you have an attacker who can replace your main app, you're probably already lost so it might not even be worth pursuing.

You should carefully consider if an attacker even has a realistic way to replace your binaries. If you're stuff is ACL'd to require administrator privileges (e.g. by an installer), then you should probably consider them to be secure. There is no way to secure yourself against an administrator, your only hope is obfuscation at that point.

Once you feel reasonably assured that your binaries are unmodified, I don't think you need to encrypt to send between them as long as you have a secure enough channel like an unnamed object local to those processes. I think a properly unnamed pipe is already secure enough not to require encryption, as long as the endpoints are legit. Would be worth a second opinion though. (If you really do need to encrypt for some reason you should do a real key exchange like Diffie-Hellman)

EDIT: after finding out App1 is an html page... In general, there is no way for App2 to secure itself against App1 if App2 cannot communicate with App1. An attacker can duplicate the launch command used by App1. You're reduced to obfuscation and hoping, which isn't really security. If you're handling sensitive data, this probably warrants a redesign. I'm not an expert on HTML, but two-way communication might actually be possible. Also, consider a third-party agent which manages the session remotely.

Upvotes: 1

Related Questions