views:

91

answers:

3

I am about to start on a project that will be running as a windows service listening for incoming connections and doing some things locally then sending a reply message. I understand the basic concepts with sockets and communicating over the network, however the things the service are doing could very easily abused. I would like to authenticate the person connecting, preferably against the windows local users on the machine the service is running, to see if they have windows administrative/power user rights.

I know how to do it check the rights once I have their information but I know sending the user name and password to the application over the network in the clear is a no no. I was thinking of just encrypting the password with some secret key but I know "trying to be clever" is the worst possible thing you can do in cryptography so I wanted to know what is the "correct" way to handle this situation.

A: 

I may as well post what I was thinking of doing, if it is the right thing to do say so in the comments.

Both the client and server will have a PSK at run-time the server will send a random number to the client. the client will encrypt the credentials with the PSK and the random number as the IV. It will send back the encrypted blob plus whatever commands it needs done.

I am not concerned about replay or mitm attacks. I just want to authenticate the user and not have peoples passwords blasted all over the network.

Scott Chamberlain
rather than posting "answers" that expand your question/explanation, use the "edit" option and clarify or expand your question. StackOverflow etiquette is different from traditional bulletin-boards, peruse the FAQ for a feel of it
STW
A: 

Scott,

this may be a bit overkill and a bit off topic, but have you considered using a web service interface to serve your clients (instead of using raw sockets)?

ASP .Net web service interfaces are easy to implement, and in the end, you'll end up with a very well defined interface. They also have support for authentication and secure communication.

Miguel Sevilla
+1  A: 

My second idea was just create a shared self signed certificate between the client and the server and just use TLS for the entire connection.

Scott Chamberlain