SDSU CS 580 Client-Server Programming
Fall Semester, 2000
Previous    Lecture Notes Index    Next    
© 2000, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 27-Nov-00

Contents of Doc 24, Security

NIH Security Web Site

SSL in Java

Applied Cryptography Second Edition, Bruce Schneier, John Wiley & Sons, 1996

Red Team versus the Agents, Scientific American, December 2000, pp. 20, 24.

Doc 24, Security Slide # 2


Some common issues

Client (server) should be able to ascertain the origin of the message
Intruder should not be able to masquerade as someone else
Messages should not be modified in transit

Sender should not be able to falsely deny sending a message later
Intruders should not be able to learn sensitive data from a message

Users should be able to perform requests that they are authorized to perform

Doc 24, Security Slide # 3
Some Bad Ideas

Doc 24, Security Slide # 4
Security through Obscurity

Security relies on encryption/authentication methods are not obvious.

Some examples:

Doc 24, Security Slide # 5
Security in the Wrong Place

Always think about what you're trying to accomplish with a security system.


Client performs authentication locally

Doc 24, Security Slide # 6
Authentication without Checking

A server that has an authentication and authorization should precede actions that require authentication.


POP server without the different states

Doc 24, Security Slide # 7
Back doors

Programmers have the tendency to add debug code to their servers to make testing easier.

This debug code may circumvent any security features of the server.


Wizard command gave full root privileges to the user
The default distribution had this command enabled
The "Internet worm" used this to attack machines throughout the Internet.

Agent software based on Lisp
Agents could perform any Lisp string
Agents could request other agents to perform tasks
Intruders could masquerade as an agent

Doc 24, Security Slide # 8

General Security Issues

Points to keep in mind when dealing with security:

Some existing tools to look at:

Doc 24, Security Slide # 9
Network Authentication

Network packets can travel through many routers and computers.

The added risks

Some issues:

Doc 24, Security Slide # 10
Authentication methods: Basic

Username and password

Protocols we have seen that use this:


POP clients check for new mail periodically

Each check requires sending name/password

HTTP requests are made every time a page is requested.

Username and password get embedding in html pages

The more frequent the authentication information is sent over a network, the higher the chance that it will be sniffed.

Doc 24, Security Slide # 11

One-Way Hash Functions

Let M be a message (sequence of bytes)

A one-way hash function f() such that:

Common One-way Hash Functions

MD5 - Message Digest 5
SHA - Secure Hash Algorithm

Doc 24, Security Slide # 12
One-Way Hash and Logins

Let f() be a one-way hash function

Client has password and userName

Client with IP XXX connects to server

Client sends userName and f(password + XXX)

Server knows the client's IP address XXX from the connection

Server computes f(password + XXX) to validate password

Sniffer can only see f(password + XXX)

f(password + XXX) only works from the machine with IP XXX

Doc 24, Security Slide # 13
Using MD5 & SHA in Java

public class SampleCode 
   public static void main(String args[]) 
      throws NoSuchAlgorithmException
      MessageDigest sha = MessageDigest.getInstance("SHA");
      sha.update("Hi mom".getBytes());
      byte[] shaHash = sha.digest();
      System.out.println(new String(shaHash));
      MessageDigest md5 = MessageDigest.getInstance("MD5");
      md5.update("Hi mom".getBytes());
      byte[] md5Hash = md5.digest();
      System.out.println(new String(md5Hash));

Doc 24, Security Slide # 14
Using security tokens, tickets, or cookies

Applications using stateless protocols (http) need to authenticate every request

Server gives a security token to a client

The token identifies the client to the server

The client only authenticates once and thereafter uses the cookie

The authentication may involve "expensive" encryption

Some requirements for security tokens:

Doc 24, Security Slide # 15
Practical security token issues

How can a server identify a client with a token?

Rely on a piece of information that is hard to change: IP address of the client

The server must correlate the token with the address when the client uses it.

How can this be done?

A random string which identifies the client
A one-way scrambled string with client information

Doc 24, Security Slide # 16


After a client has been authenticated, the traffic on a network can still be sniffed.

A solution is encryption of all traffic.

This can be done at any layer of the protocol stack

Two basic types of encryption:

One key both encrypts and decrypts

One key encrypts, another decrypts

Doc 24, Security Slide # 17
Public/Private Key Encryption

A public key is something that is well known, i.e. published.

A client can send authentication information by encrypting the info with the server's public key.

The server will then use its own private key to decrypt the information.


Doc 24, Security Slide # 18
Digital Signatures

The same encryption method can be used to authenticate a message:

A client encrypts information with its own private key.

The server will lookup the client's public key and decrypt the information.


The information can only be decrypted with the client's public key.

If the public key distribution center can be trusted, the information is guaranteed to come from the client.

A combination of the previous two methods allows for mutual authentication.

Copyright ©, All rights reserved.
2000 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
OpenContent license defines the copyright on this document.

Previous    visitors since 27-Nov-00    Next