	CS 580 Client-Server Programming Fall Semester, 2000 Security
	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

References NIH Security Web Site http://www.alw.nih.gov/Security/security.html

SSL in Java http://java.sun.com/products/jsse/

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

Security

Some common issues

Authentication


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

Integrity


Messages should not be modified in transit

Nonrepudiation

Sender should not be able to falsely deny sending a message later

Confidentiality


Intruders should not be able to learn sensitive data from a message

Restricted Access

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


Doc 24, Security Slide # 3

Some Bad Ideas

Security by Obscurity
Security in the wrong place
Authentication without checking
Back doors


Doc 24, Security Slide # 4

Security through Obscurity
Security relies on encryption/authentication methods are not obvious.

Some examples:

Reverse the byte order of a message
Swap bytes in some "secret" way
Add garbage to data
Use some "secret" algorithm


Doc 24, Security Slide # 5

Security in the Wrong Place
Always think about what you're trying to accomplish with a security system.

Examples:

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.

Example:

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.

Example

sendmail "WIZARD"

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.

Sandia National Labs Security Agents Software

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:

The security system is only as strong as its weakest link
A flawed security system is worse than no security at all
US government considers encryption algorithms munitions

Several security systems together are better than only one
Security by obscurity really doesn't work

Some existing tools to look at:

PGP (Pretty Good Privacy)
RCA
Kerberos
SSL (Secure Socket Layer)


Doc 24, Security Slide # 9

Network Authentication

Network packets can travel through many routers and computers.

The added risks

Network sniffing
Traffic logging
Etc.

Some issues:

Passwords can be "sniffed" from the network
Traffic patterns can be analyzed


Doc 24, Security Slide # 10

Authentication methods: Basic
Username and password

Protocols we have seen that use this:

POP
HTTP

Problems
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:

f maps arrays of bytes to arrays of bytes
f(M) is always the same length
Given an M it is easy to compute f(M)
Given f(M) it is hard to compute M
Given M it is hard to find N such that f(M) = f(N)

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

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
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:

Cannot be faked
Need to expire after some time


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

Encryption

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:

Shared key encryption


One key both encrypts and decrypts

Public/Private key encryption

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.

Advantages:

The information the client sends to the server cannot be decrypted by anyone except the server


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.

Advantages:

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