Hello,
I am coding a server/client. My server takes a certain action based on
the type of message it receives.
Your questions are off-topic, but keep reading for
suggestions/responses. Yours is an issue of authorization, which can
usually be addressed with authentication. Read the short Wikipedia
articles on authorization and authentication for differences between
them:
http://en.wikipedia.org/wiki/Authorization
http://en.wikipedia.org/wiki/Authentication
Authentication protocols and authorization aren't covered by this
newsgroup, which solely addresses issues regarding the C++ language
and standard library; see section 5 of the C++ FAQ:
http://www.parashift.com/c++-faq-lite/
If you have further questions, try a book which covers authentication
protocols, such as "Practical Cryptography" by Niels Ferguson and
Bruce Schneier, "Applied Cryptography" by Bruce Schneier or "The
Handbook of Applied Cryptography" (especially chapters 10 and 11),
available online at:
http://www.cacr.math.uwaterloo.ca/hac/
or perhaps the comp.security.* hierarchy of newsgroups. There's a
wikibook on cryptography, but the section on protocols isn't written:
http://en.wikibooks.org/wiki/Cryptography
How can I filter out messages that my server may receive from processes
that are not part of my application? I was thinking handshake. In this
case, what kind of info would I want to exchange in the handshake?
If you want one entity to authentify another, you could use public key
cryptography, which basically uses digital signatures, or symmetric
key cryptography.
http://en.wikipedia.org/wiki/Digital_signature
http://en.wikipedia.org/wiki/Symmetric_key_algorithm
http://en.wikipedia.org/wiki/Public_key_cryptography
The entity which needs to perform the authentication is the
"challenger" and the entity which wants to be authentified is the
"challenged". The next two paragraphs give brief outlines of two
protocols.
For public key cryptography, the challenger sends plaintext to the
challenged, who encrypts the plaintext and sends the result (the
"ciphertext"). The challenger decrypts the ciphertext and compares it
to the original plaintext; if equal, the challenger has the right key
and is considered authenticated.
For symmetric key cryptography, the challenger encrypts data and sends
that to the challenged. The challenged decrypts the ciphertext,
alters it in some pre-defined way (e.g. increments it), encrypts the
result and sends it back. The challenger decrypts this and compares
it to the alteration of the original data; if equal, the challenger
has the right key and is considered authenticated.
If you want the server and client to authenticate each other, each
needs to follow the authentication steps (i.e. each is, in turn, the
challenger and challenged).
You need a secure way of sharing keys, otherwise your system is
vulnerable to man-in-the-middle attacks.
http://en.wikipedia.org/wiki/Man-in-the-middle_attack
You have to be careful your protocol isn't weak against chosen
plaintext/adaptive chosen plaintext attacks from the challenger (an
evil challenger can send plaintext which, along with the ciphertest,
makes it easy to guess the secret key):
http://en.wikipedia.org/wiki/Chosen_plaintext_attack
For example, the public key protocol described above but using
symmetric keys is weak against chosen plaintext attacks.
After (or even before) authentication, you'll need to encrypt the
connection otherwise it's vulnerable to a man-in-the-middle attack.
Is a
string message exchange (HS1: "hello from the client", HS2:"hello from
the server") robust enough?
Short answer: probably not.
Slightly longer: depends on how important security is.
"Robust enough" always depends on the security requirements for the
problem you're trying to address. How long do secrets need to be kept
secret? How bad would it be if someone broke through the security?
Weigh the effort it would take to break security against the rewards
of doing so.
The weakness of many naive cryptographic systems aren't always the
algorithms but the protocols surrounding handling of secret data. A
secret password is secure as long as it can be kept secret, which
often won't be long if the password is stored in a form which can be
unencrypted without input from a user. Encrypted and unencrypted data
stored on digital media can be retrieved, whether in the source code,
binaries or a data file, by an attacker. Encrypted data which doesn't
need user input can then be unencrypted with the unencrypted keys
using either a separate implementation of the decryption algorithm or
by letting the client decrypt the data (with a debugger or calling the
decryption routines from another program) and grabbing the result.
Keeping the algorithm secret is no guarantee of safety. The password
could also be read off the network if transmitted as plaintext or
intercepted before it's encrypted. Thus the only reliably secure way
of using passwords is to have the user choose and remember the
password and have the client/server encrypt their communication. And
that's only secure as long as the user doesn't do something stupid
like storing unencrypted passwords on their computer.
Is handshaking the only solution?
You can also allow filter connections based on their attributes, such
as source address or source port (assuming a network connection which
supports such concepts) or user id (assuming a local client on a
system which supports the concept of "user id"). This mostly provides
a quick way of denying some connections rather than being a
full-fledged authentication method.
Using something like ident (RFC 1413) may seem an option, but offers
nothing as it's trivial to spoof and user ids are not (in general)
transferable across systems.
You can also build on some pre-existing authentication/authorization
system, such as Active Directory (if you're developing for Win32
platforms) or Kerberos.
Kanenas
