server/client design issue

Discussion in 'C++' started by Nadina, Apr 25, 2005.

  1. Nadina

    Nadina Guest


    I am coding a server/client. My server takes a certain action based on
    the type of message it receives.

    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? Is a
    string message exchange (HS1: "hello from the client", HS2:"hello from
    the server") robust enough?

    Is handshaking the only solution?

    Thank you in advance!
    Nadina, Apr 25, 2005
    1. Advertisements

  2. Nadina

    Kanenas Guest

    On 24 Apr 2005 18:59:55 -0700, "Nadina" <> wrote:

    >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

    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:

    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:
    or perhaps the* hierarchy of newsgroups. There's a
    wikibook on cryptography, but the section on protocols isn't written:

    >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.

    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

    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.

    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):
    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, Apr 25, 2005
    1. Advertisements

  3. Nadina

    Nadina Guest

    Thank you. I know I was off the topic :(
    Nadina, Apr 25, 2005
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Junpei
    Jim Gibson
    May 27, 2004
  2. -
    Alan Krueger
    Jul 29, 2005
  3. xfan
  4. puzzlecracker
    Thomas Hawtin
    Sep 21, 2006
  5. TonyM

    client/server design and advice

    TonyM, Dec 1, 2006, in forum: Python
    Peter Decker
    Dec 1, 2006
  6. bruce
    Irmen de Jong
    Dec 2, 2006
  7. brieuc
    Esmond Pitt
    Mar 20, 2007
  8. Design Issue (Employee and Client)

    , Feb 20, 2006, in forum: ASP .Net Security