Two-Key_Exchange

A Practical Password based Two Server Authentication and Key Exchange System

1. ABSTRACT

Most password-based user authentication systems place total trust on the

authentication server where clear text passwords or easily derived password verification

data are stored in a central database. Such systems are, thus, by no means resilient against

offline dictionary attacks initiated at the server side. Compromise of the authentication

server by either outsiders or insiders subjects all user passwords to exposure and may

have serious legal and financial repercussions to an organization. Recently, several

multiserver password systems were proposed to circumvent the single point of

vulnerability inherent in the single-server architecture. However, these multiserver

systems are difficult to deploy and operate in practice since either a user has to

communicate simultaneously with multiple servers or the protocols are quite expensive.

In this project, a practical password-based user authentication and key exchange system

employing novel two-server architecture is proposed. This system has a number of

appealing features, only a front-end service server engages directly with users while a

control server stays behind the scene; therefore, it can be directly applied to strengthen

existing single-server password systems. In addition, the system is secure against offline

dictionary attacks mounted by either of the two servers.

1


2. SCOPE OF THE PROJECT

A Practical Password-based Two-Server Authentication and Key Exchange System

comprises of two servers by which only a front-end service server appears and deals with

the users where as the second server(control server) stays behind the scene strengthen

existing single-server password systems. In this system the password chosen by the users

has been stored in two servers but appears to be the experience of a single server. The

public server acts as a service server that provides application services, while the back-

end server is a control server whose sole purpose is to assist the service server in user

authentication.

2


3. INTRODUCTION

3.1 INTRODUCTION TO PROJECT:

Password Authentication is the most widely used method. Password based

encrypted key exchange protocols are designed to provide users to communicate over an

unreliable channel with a secure session key. These systems are easy to use and are low

cost. Password authentication requires no dedicated devices like smart cards. Password

based user authentication systems total trust is based on the authentication server, which

performs password verification data (PVD) derived from central database. With the

password the client authenticates himself to the server. The user can simply send the

password to the server, which validates the received password. For security reasons, the

password should be encrypted before it is transferred. Passwords are easy to remember

but inherently weak because most passwords are selected from dictionary, so it allows for

brute-force attacks called dictionary attacks.

The attackers try with possible password from dictionary. Dictionary attacks are

classified as offline and online attacks. In case of online attack, attackers attempt to log in

to the server by trying all passwords from dictionary, but in case of offline attack;

attackers store all past successful login session between a user and a server and then

check the passwords in the dictionary against the login transcript. In the most rigorous

password-only security models, there is no requirement for the user of the method to

remember any secret or public data other than the password.

Most password-based authentication systems employ a Secure Socket Layer

(SSL) connection is established first between the client and the server and then a

password is sent to the server via SSL connection for client-side authentication. Since

each SSL session establishes a random session key by which the password is encrypted, if

an attacker eavesdrops the encrypted password, attacker will not be able to replay it. The

two server systems that are available for password authentication exposes one server to

users and the other is hidden from public. In the proposed system the hidden server is

made public there by the number of users are increased by two way authentication and

also by efficiently using the control server.

3


3.2 PROBLEM SPECIFICATION:

Problem Statement:

Most password-based user authentication systems place total trust on the

authentication server where clear text passwords or easily derived password verification

data are stored in a central database. Such systems are, thus, by no means resilient against

offline dictionary attacks initiated at the server side. Compromise of the authentication

server by either outsiders or insiders subjects all user passwords to exposure and may

have serious legal and financial repercussions to an organization.

Description of Organization:

Passwords are the most common method of authentication used to control

access to digital resources. They are also the easiest way to gain unauthorized access to

these resources. Armed with password cracking software, an intruder can discover a

dictionary word password, or simple variation, in a matter of seconds. When you consider

how much information is protected solely by passwords, it quickly becomes clear that

good passwords are vital to preserving confidentiality.

Passwords must be protected against unauthorized disclosure, modification, & removal.

There are two ways of attacking passwords:

1. Password guessing

2. Password cracking

1. Password Guessing:

Password guessing is guessing the password when a valid user ID is known. It can be

done either manually or automatically, submitting the password of a particular user. For

example, if the user ID is John attacker tries Jack and some other password until finds one

or locked out. In any case, complex passwords provide protection against this type of

attack.

4


2. Password Cracking:

Password cracking is done using a copy of the system file that stores account

passwords in encrypted form. All current operating systems store passwords in an

encrypted form by running the passwords through a one way hash. The hash is then

stored, not the clear text password.

There are three types of cracking attacks:

1. Dictionary attacks

2. Brute force attacks

3. Hybrid attacks

1. Dictionary attacks:

If dictionary words are used as passwords, they can be readily broken, even when

encrypted. That's because software has been created that gives the intruder the ability to

take an entire dictionary's worth of words, run it through various encryption algorithms,

and compare the results with the encrypted password file. If a match is found to the

password hash, the cracker works backswords to discover what the password is. Simply

put, dictionary words offer no protection at all as passwords. If you are thinking of using

foreign words, forget it.

2. Brute force attacks:

A brute force attack tries every possible combination of letter, number, and

punctuation value and format. A brute force attack will always succeed in cracking a

password hash. However, depending on the strength of the password, the hashing

formula, and the speed of the computer, it could take many years to crack some

passwords. In our proposed system the Bit length of |h|, |n| and |p| are minimum of 64 bits

length so the intruders could take a years to crack them.

5


3. Hybrid attacks:

Hybrid attacks build on dictionary attacks by adding or substituting other

characters or numbers for certain letters in dictionary words. Many people perform a

simple substitution, or propend or append a character to a dictionary word to create a

password (e.g., Kris123). The number of messages between the servers and client are

higher than basic and improved protocol there by the intruders has to trap are messages

and has to calculate are the exponentiation which higher than 64 bits. Each time the user

authentication is done by selecting a random number from the Quadratic residue set

which is in turn form from random number that is chosen at each time of login. Therefore,

the intruder reaches different values each time which may take a long time for him to

reach the value.

3.3 COMPANY PROFILE:

In this world of increasing globalization, Our Company moves forward to meet the

challenges of the future through the development of R & D projects in various domains. R

& D project sector attracts the most prominent thinkers and practitioners in a range of

fields that impinge on development. The global presence and reach attained by us are not

only substantiated by its presence, but also in terms of the training students in R & D

project development.

Over the decade, provides a wide range of R & D project development training. Our

uniqueness lies in the exclusive R & D project development. Accordingly, we created a

setting that is enabling, dynamic and inspiring for the increase of solutions to global

problems by R & D project development. Developing appropriate, responsible, innovative

and practical solutions to students, by assisting in R & D project development. All our

research is stranded in the need to provide an industry based training for students.

About team

Our team consists of enthusiastic experts, drawn from a range of disciplines and

experience, supported by infrastructure and facilities, which are world class and

distinctively state-of-the-art.

6


The strength of the organization lies in not only identifying and articulating

intellectual challenges across a number of disciplines of knowledge but also in mounting

research, training and demonstration projects leading to development of specific problem-

based advanced technologies. The organization growth has been evolutionary, driven by a

vision of the future and ingrained in challenges frightening today. The organization

continues to grow in size, spread and intensity of work undertaken. Our experts are

involved in a wide range of R & D project development training to student wishing to

undertake professional development, or just wanting to learn about a new subject or area

of study.

About R & D

Research and development Training makes students to understand new concepts,

understand the strength and far reaching potential of your conception. It helps student to

understand and prepare for the future of your technology.

Vision

Our vision doesn't begin and end with the execution of R & D projects. The main

intension is to provide world-class training to the students in R & D project development

by sharing our knowledge and expertise to create value is our ultimate goal.

7


4. SYSTEM ANALYSIS

4.1 EXISTING SYSTEM:

Single Server Model:

Fig: 4.1.1 Single Server Model

In Single server system, the user communicates with one server where the server validates

against the password available in the central database and allows the user. But, this

system has higher chance of attacks from intruders. The user authentication is done only

by a single server which less secure than two server.

Multi-Server Model:

Fig: 4.1.2 Multi-server model

In the Multi server systems user communicate with servers in parallel by establishing the

connection with all the servers. The users have to communicate with all the servers for

authentication simultaneously so there is demand on communication bandwidth and the

need for synchronization.

8


Gateway Multi-Server Model:

Fig: 4.1.3 Gateway multi-server model

In the Gateway augmented multi server model, the gateway server is positioned between

user and the multiple servers. The users have to communicate only with the gateway so it

removes the demand of simultaneous communications by user with multiple servers.

There is an additional layer “gateway” in the architecture where gateway acts as rely

messages between user and servers. It does similar to that of multi server.

DISADVANTAGES:

The single server results in a single point of vulnerability in terms of offline

dictionary attacks against the user password database.

The main problem with the plain multiserver model is the demand on

communication bandwidth and the need for synchronization at the user side since

a user has to engage in simultaneous communications with multiple servers. From

security perspective, more components generally imply more points of

vulnerabilities.

9


4.2 PROPOSED SYSTEM:

Two Server Model:

In serial communication, the user establishes the connection with the server in

series. It includes Two Server Systems

.

Fig: 4.2.1 Two Server Model

In Two server systems, the user is allowed to communicate with single system, public

server where as the other system is the back-end server or the control server used for

authentication only. The important difference between the two server and the multi server

models:

A user ends up establishing a session key only with the public server where in multi

server model a user establishes a session key with each of the servers.

ADVANTAGES:

It is clear that the two-server model has successfully eliminated drawbacks in the

plain multiserver model (i.e., simultaneous communications between a user and

multiple servers) and the gateway augmented multiserver model (i.e., redundancy)

while allowing us to distribute user passwords and the authentication functionality

to two servers in order to eliminate a single point of vulnerability in the single-

server model.

In the Proposed System, the public server acts as a service server that provides

application services, while the back-end server is a control server whose sole

purpose is to assist the service server in user authentication (the service server, of

course, also participates in user authentication). This enforces clear separation of

duty in our system.

10


5. FEASIBILITY STUDY

Many feasibility studies are disillusioning for both users and analysts. First, the

study often presupposes that when feasibility document is being prepared, the analyst is in

a position to evaluate solutions. Second, most studies tend to overlook the confusion

inherent in the system development – the constraints and the assumed attitudes. If the

feasibility study is to serve as a decision document for a project, it must answer 3 key

questions:

Three key considerations involved in the feasibility analysis:

1. Economical Feasibility

2. Technical Feasibility

3. Behavioral Feasibility

5.1 ECONOMIC FEASIBILITY:

This application on the client side has been developed using J2EE, which is open

source software. The hardware required are two servers, which is not expensive. Hence

the application is economically feasible.

5.2 TECHNICAL FEASIBILITY:

As the application has been developed using J2EE and the back end as MS-

Access, which utilize minimum resources of the Personal computer, this project is

technically feasible.

5.3 BEHAVIORAL FEASIBILITY:

This project has been implemented by J2EE and it satisfies all the conditions and

norms of the organization and the users.

11


5.4 TECHNICAL ANALYSIS:

Technical analysis involves the evaluation of the technical merits of the system,

which should envelope, the following aspects:

Short term implementation consideration

Long term implementation consideration

Technical analysis begins with the assessment of the technical viability of the

technologies, the methods, employed and the risk involved in their development. The

proposed system employees advanced technology such as J2EE and other technical

resources, which are time tested and available. The technologies plain and simple on the

development side and are profound and robust on the implementation side that is worth

employing. The above discussion vaporizes any doubts expressed regarding viability of

the system.

12


6. SOFTWARE REQUIREMENT SPECIFICATIONS

Software requirements specification is the starting point of software development

activity. It is the most difficult and error prone task. The SRS is the means of translating

the ideas in the minds of clients (the input), into a formal document (the output of the

requirement phase).

6.1 INTRODUCTION:

Purpose:

The SRS document purpose is to describe the nominal and other

requirements of the system that validates the employee (user) and allow him to do his

office work.

Scope:

The locality of this application is limited to the user and the server; in this the

user gives his id and password to the server in order to login to the server. It provides the

authentication to the user by making it secure against the offline dictionary attacks.

6.2 USER REQUIREMENTS:

User must possess a valid user id and password for the purpose of authentication.

The user importantly must have a p.c. with a LAN network in order to gain the

authentication from the server.

13


6.3 SOFTWARE REQUIREMENTS:

Client Side:

Front End:

Operating system : Windows XP

Technology : Java

Server Side:

Front End:

Operating system : Windows XP/2000 or higher

Technology : Java using JSP, JDBC.

Back End:

Database : MS-Access

Web Server : Apache Tomcat

6.4 HARDWARE REQUIREMENTS:

Client Side:

Processor : Intel Pentium III or higher

Ram : 256 MB or higher

Hard disk : 40 GB hard disk

Network Connections : LAN

Server Side:

Processor : Intel Pentium IV or higher

Ram : 1GB or higher

Cache : 512 KB

Hard disk : 160 GB hard disk or higher

14


6.5 FUNCTIONAL REQUIREMENTS:

The project mainly contains the following modules

1. User Registration

2. Password Authentication

3. Key Exchange

4. Server Development

1. User Registration:

The user must enter the id and password to register into the database after

registering the user will login into the server using the registered id and password.

2. Password Authentication:

After giving his id and password, the password is send to the service server and

the service server collects the remaining password from the control server and checks

whether the user is valid or not.

3. Key Exchange:

`In this the user sends his password to the service server and the service server

divides the password into two halves , one half is send to the control server and remaining

part is kept with the service server. In this the password is exchanged between the two

servers, if the password is valid the control server gives the authentication report to the

service server and then the service server provides the authentication to the user.

4. Server Development:

In this module we will develop a service server that should interacts with the

clients and we will develop a control server will only have the interaction with service

server but not with the clients.

15


6.6 PERFORMANCE REQUIREMENTS:

Static Requirements:

These are the requirements that are essential for the better performance of the

system before the system gets executed. These include the number of users to be

supported, number of parallel instructions to be processed.

The server side computer should highly configure with a memory capacity to

support the kick off of many parallel instructions.

Dynamic Requirements:

The servers must be configured to support a vast number of users.

6.7 INTRODUCTION TO JAVA

Security:

Every time you download a “normal” program, you are getting risk with a viral

infection. Prior to java, most users did not download executable programs frequently. In

addition, another type of malicious program exists that must be guarded against. This type

of program can gather private information, such as credit card numbers, bank account

balances, and passwords. Java answers both these concerns by providing a “firewall”

between a network application and your computer.

Portability:

For programs to be dynamically downloaded to all the types of platforms

connected to the internet, some means of generating portable executable code is needed.

As you will see, the same mechanism that helps ensure security also helps create

portability. Indeed, java’s solution to these two problems is both elegant and efficient.

16


Platform Independent:

Platform independence, that means the ability of a program to move easily from

one computer system to another. It is one of the most significant advantages that Java has

over other programming languages. Java is platform independent at both the source and

the binary level.

Byte code:

The key that allows the java to solve the security and portability problems is that

the output of java compiler is byte code. Byte code is a highly optimized set of

instructions designed to be executed by the java run – time system, which is called the

java virtual machine (JVM). That is, in its standard form, the JVM is an interpreter for

byte code.

Java Applets:

Applets are a common way of writing Java applications. Integrating web based

sound and graphics into applications is simplified by using methods in Applet class.

Applets are essentially program that run from within a browser.

They appear as part of HTML documents in the same way that pictures are presented. The

major difference is that instead of a static graphics, the Java Applet is a complete running

program. An Applet is just like a widow application, but without a classic window frame.

The ranges of programs that can be written as an APPLET are reduced because of

security limitations imposed by the target browser. Applets run only from with in Java-

Enabled browsers such as NETSCAPE, hotJava, and INTERNET EXPLOSER.

Applet Life Cycle:

There are four methods that give the framework to build the applet

Init ()

Start ()

Stop ()

Destroy ()

17


Init():- Used for initial setup such as defining Layout, passing parameters and other

initializations.

Start():- This is called immediately after init () start () is called each time user return to

the pea or when the page is deconified. Unlike start, init is called only once.

Stop():- This method is called when the user moves off the page on which the Applet sits

or when it is confined. If an applet if not doing time consuming activities like performing

animation, this need not be implemented.

Destroy():- This method is called when the browser shuts down. It is used to re-claim

resources.

Introduction to Swings:

After working your way through this chapter and seeing the huge changes that

have occurred within the AWT (although, if you can remember back that far, Sun claimed

Java was a “stable” language when it first appeared), you might still have the feeling that

it’s not quite done. Sure, there’s now a good event model, and JavaBeans is an excellent

component reuse design. But the GUI components still seem rather minimal, primitive,

and awkward. That’s where Swing comes in. The Swing library appeared after Java 1.1

so you might naturally assume that it’s part of Java 1.2. However, it is designed to work

with Java 1.1 as an add-on. This way, you don’t have to wait for your platform to support

Java 1.2 in order to enjoy a good UI component library. Your users might actually need to

download the Swing library if it isn’t part of their Java 1.1 support, and this could cause a

few snags. But it works Swing contains all the components that you’ve been missing

throughout the rest of this chapter: those you expect to see in a modern UI, everything

from buttons that contain pictures to trees and grids. It’s a big library, but it’s designed to

have appropriate complexity for the task at hand – if something is simple, you don’t have

to write much code but as you try to do more your code becomes increasingly complex.

This means an easy entry point, but you’ve got the power if you need it.

Easy conversion:

If you’ve struggled long and hard to build your UI using Java 1.1, you don’t want

to throw it away to convert to Swing. Fortunately, the library is designed to allow easy

conversion – in many cases you can simply put a ‘J’ in front of the class names of each of

your old AWT components.

18


Tool tips:

Almost all of the classes that you’ll be using to create your user interfaces are

derived from JComponent, which contains a method called setToolTipText(String). So,

for virtually anything you place on your form, all you need to do is say (for an object jc of

any JComponent-derived class):

jc.setToolTipText("My tip");

when the mouse stays over that JComponent for a predetermined period of time, a

tiny box containing your text will pop up next to the mouse.

Borders:

JComponent also contains a method called set Border ( ), which allows you to

place various interesting borders on any visible component. The following example

demonstrates a number of the different borders that are available, using a method called

showBorder( ) that creates a JPanel and puts on the border in each case. Also, it uses

RTTI to find the name of the border that you’re using (stripping off all the path

information), then puts that name in a JLabel in the middle of the panel:

Buttons:

Swing adds a number of different types of buttons, and it also changes the

organization of the selection components: all buttons, checkboxes, radio buttons, and

even menu items are inherited from Abstract Button (which, since menu items are

included, would probably have been better named “AbstractChooser” or something

equally general).

The JButton looks like the AWT button, but there’s more you can do to it (like

add images, as you’ll see later). In com.sun.java.swing.basic, there is a BasicArrowButton

that is convenient, but what to test it on? There are two types of “spinners” that just beg to

be used with arrow buttons: Spinner, which changes an int value, and String Spinner,

which moves through an array of String (even automatically wrapping when it reaches the

end of the array).

19


The Action Listeners attached to the arrow buttons shows how relatively obvious

it is to use these spinners: you just get and set values, using method names you would

expect since they’re Beans. When you run the example, you’ll see that the toggle button

holds its last position, in or out. But the check boxes and radio buttons behave identically

to each other, just clicking on or off (they are inherited from JToggleButton).

Button groups:

If you want radio buttons to behave in an “exclusive or” fashion, you must add

them to a button group, in a similar but less awkward way as the old AWT. But as the

example below demonstrates, any Abstract Button can be added to a Button Group.

To avoid repeating a lot of code, this example uses reflection to generate the

groups of different types of buttons. This is seen in make Panel, which creates a button

group and a JPanel, and for each String in the array that’s the second argument to

makeBPanel( ), it adds an object of the class represented by the first argument.

Icons:

You can use an Icon inside a JLabel or anything that inherits from Abstract Button

(including JButton, JCheckbox, JradioButton, and the different kinds of JMenuItem).

Using Icons with JLabels is quite straightforward (you’ll see an example later). The

following example explores all the additional ways you can use Icons with buttons and

their descendants.

Menus:

Menus are much improved and more flexible in Swing – for example, you can use

them just about anywhere, including panels and applets. The syntax for using them is

much the same as it was in the old AWT, and this preserves the same problem present in

the old AWT: you must hard-code your menus and there isn’t any support for menus as

resources (which, among other things, would make them easier to change for other

languages). In addition, menu code gets long-winded and sometimes messy.

20


The following approach takes a step in the direction of solving this problem by

putting all the information about each menu into a two-dimensional array of Object (that

way you can put anything you want into the array). This array is organized so that the first

row represents the menu name, and the remaining rows represent the menu items and

their characteristics.

Popup Menus:

The implementation of JPopupMenu seems a bit strange: you must call enable

Events( ) and select for mouse events instead of using an event listener. That is, it’s

possible to add a mouse listener but the Mouse Event that comes through doesn’t return

true from

isPopupTrigger( ) – it doesn’t know that it should trigger a popup menu.8 In addition,

when I tried the listener approach it behaved strangely, possibly from recursive click

handling.

List Boxes and Combo Boxes:

List boxes and combo boxes in Swing work much as they do in the old AWT, but

they also have increased functionality if you need it. In addition, some conveniences have

been added. For example, the JList has a constructor that takes an array of Strings to

display (oddly enough this same feature is not available in JComboBox).

Sliders and Progress Bars:

A slider allows the user to input data by moving a point back and forth, which is

intuitive in some situations (volume controls, for example). A progress bar displays data

in a relative fashion from “full” to “empty” so the user gets a perspective.

21


Trees:

Using a JTree can be as simple as saying:

add(new JTree(new Object[] {"this", "that", "other"}));

This displays a primitive tree. The API for trees is vast, however – certainly one

of the largest in Swing. It appears that you can do just about anything with trees, but more

sophisticated tasks might require quite a bit of research and experimentation.

Fortunately, there is a middle ground provided in the library: the “default” tree

components, which generally do what you need. So most of the time you can use these

components, and only in special cases will you need to delve in and understand trees

more deeply.

Tabbed Panes:

Earlier in this chapter you were introduced to the positively medieval Card

Layout, and saw how you had to manage all the switching of the ugly cards yourself.

Someone actually thought this was a good design. Fortunately, Swing remedies this by

providing JTabbedPane, which handles all the tabs, the switching, and everything. The

contrast between Card Layout and JTabbedPane is breathtaking.

22


7. SYSTEM DESIGN

7.1 INTRODUCTION:

Purpose:

System design is the process of application various techniques and principles for

the purpose of definition a system in sufficient detail to permit its physical realization.

Primary design is concerned with the transformation of requirements into data and

software architecture.

Detailed design focuses on refinements to the architectural representations that

lead to detailed data structure and algorithmic representation for software. In the present

project report, only preliminary design is given more emphasis.

7.2 DATA DICTIONARY:

It is a centralized repository of information about data such as meaning,

relationships to other data and the tables representing the data.

Table: 7.2.1

7.3 CLASS DIAGRAM:

A class diagram shoes a set of classes, interfaces, and collaborations and their

relationships. Class diagrams are most common diagrams found in modeling object-

oriented systems. You use class diagrams to illustrate the static design view of the system.

Class diagrams that include active class are used to address the static process view of a

system.

23

uname pass1 pass2

abcde 2.5 6.5

sarat 1.0 5.0

anto 0.5 4.5


Class diagrams are important for not only visualizing, specifying and

documenting structural models, but also for constructing executable systems through

forward and reverse engineering.

Identify Classes:

By filtering out all of the nouns except for the classes, you will have many of the

classes identified from your system. These are termed as ALC (analysis level classes)

from which classes are categorized as good classes and bad classes where good classes

are those relevant to the project.

Another method is looking for the repeating objects to the level of different

sequence diagrams at the analysis level. The repeating objects are the tentative objects at

the design level class diagram.

24


CLASS DIAGRAM:

Fig: 7.3.1 Class diagram

7.4 USE-CASE DIAGRAM:

25

controlserver

authentication()key exchange()

usernamepassword

login()registration()

service server

authentication()key exchange()verification()

registrationnameuser idpassword

login()

database

verify()retrieve()update()


Use-case diagram identify the functionality provided by the system (use-cases),

identifies users who interact with the system (actor) and provides association between

actors and use-cases. It shows dynamic aspects of the system when the user interacts with

it. A use case can have all possible interactions of users with use-case graphically. Thus

use-case diagram models use cases view of system.

Definitions:

A use-case diagram is a set of use cases, actors and relationships between actors,

use-cases.

A use-case diagram contains

1. Use-cases

2. Actors

3. Association relationship between actors, use-cases

Common uses of use-case diagram:

1. Provides high level view of system with respect to users

2. To model context of system

3. Determine human system interaction

The basic components in use-case diagram are

1. Use-case

2. Actor

3. Association

Use case:

It functionally provided by system. Use case is represented graphically as ellipse

with name inside it.

Actor:

An actor is user of system or database in system. These are represented with stick

Figure.

Association:

It links actors to use use-case explains in what and how actor interacts with

system.

26


Identifying the actors:

The team actor represents the role user plays with respect to the system. A user

may play more than one role. However an actor should represent a single user.

Actors can be identified by following questions:

1. Who is utilizing the system or who is affected by the system or which

groups need help from the system to carry out a task.

2. Which external hardware or other system use the system to execute

tasks

3. What problem dies this application solve

Identifying the use-cases:

1. One of the methods used to identify the use cases is actor based.

a. The actors related to a system or organization are identified

b. The process, task, functions initiated or participated, performed by each

actors are identified. The use case should represent a course of events

leading to a clear goal.

2. The second method used to identify use-cases is event based

a. The external events that a system must respond to are identified.

b. Relate the events to actors and use cases

USE CASE DIAGRAM:

27


Fig: 7.4.1 Use case diagram

7.5 SEQUENCE DIAGRAM:

A Sequence Diagram is an interaction diagram that emphasizes the time ordering

of messages .a sequence diagram shows a set of objects and the messages sent and

28


received by those objects .The objects are typically named or anonymous instances of

classes, but may also represent instances of other things ,such as collaborations,

components , and nodes. We use sequence diagram to represent the dynamic view of the

system.

1: login

2: check details3: check the database

4: new user

5: provide new user id &password

6: store the details of new user

7: divide the password

8: send second half to the control server

9: generate a value for second half

10: generate the value for the first half by using value of second half

11: provide authentication

12: logout

service server

user control server

database

29


Fig: 7.5.1 Sequence diagram

7.6 COLLABORATION DIAGRAM:

A Collaboration Diagram is an interaction diagram that emphasizes the structural

organization of the objects that sends and receives messages. a collaboration diagram

shows a set of objects , links among those object and messages sent and received by those

objects. The objects are typically named or anonymous instance of the classes but may

also represent instances of other things, such as collaborations, components and nodes.

We use collaboration diagram to illustrate the dynamic view of the system.

user

database service

server

6: store the details of new user3: check the database

5: provide new user id &password2: check details

8: send second half to the control server

9: generate a value for second half

7: divide the password10: generate the value for the first half by using value of second half

11: provide authentication

1: login4: new user12: logout

control server

Fig: 7.6.1 Collaboration Diagram

30


7.7 ACTIVITY DIAGRAM:

Activity diagram is a variation or special case of state machine. In this, the states

or the activities represent the performance of operations. The transactions are triggered by

the completion of operations. Activity diagram may be used to model an entire business

process. It provides flow of the program. Activity diagram is used to show the internal

state of the object by external events may appear in them.

The activity diagram describes the sequence of activities, with the support for both

conditional and parallel behavior.

31


Fig: 7.7.1 Activity diagram

7.8 DIAGRAMATIC REPRESENTATION OF EACH MODULE:

User registration:

The user must enter the id and password to register into the database. After

registering the user will login into the server using the registered id and password.

32


Fig: 7.8.1 User registration

Password Authentication:

After giving his id and password, the password is send to the service server and

the service server collects the remaining password from the control server and checks

whether the user is valid or not.

Fig: 7.8.2: Password Authentication

Key Exchange:

In this the user sends his password to the service server and the service server

divides the password into two halves, one half is send to the control server and remaining

part is kept with the service server. In this the password is exchanged between the two

33

loginuser Registration

logout


servers, if the password is valid the control server gives the authentication report to the

service server and then the service server provides the authentication to the user.

Fig 7.8.3: Key Exchange

8. SYSTEM MODULES

8.1 MODULAR DESIGN:

34

user

password

authentication

service server control server


Two-Server Password Authentication Protocol Module.

Mutual Authentication Protocol Module.

Basic Password Authentication and Key Exchange Protocol Module.

Proposed Password Authentication and Key Exchange Protocol Module.

Decisional Diffie-Hellmen Assumption Module.

8.2 PROTOCOL MODULES:

Two-Server Password Authentication Protocol Module:

In this section, we elaborate the authentication and key exchange protocols that are

used upon the two server model. We first discuss about the mutual authentication protocol

then the basic two server authentication protocol and its security issues, then the

improved protocol and then the proposed two way authentication and key exchange

protocol in the two server model. For ease of reference, the notations that are used are

tabulated below.

Notation

Table: 8.2.1 showing some basic notations

Mutual Authentication Protocol Module:

35

Large prime numbers such that and

Belongs to where is a quadratic residues of mod p

Random numbers

Random numbers belongs to

User’s password

Hash function


In this section, we present a new protocol, the Mutual Authenticating Protocol

(MAP). Using the specific mechanisms from other protocols MAP was developed to

provide a specified level of network and system security.

The following are basic design goals:

1. Mutual authentication between users or between user and server.

2. Minimal information transferred for mutual authentication.

3. Password storage protection.

4. Password protection during transit over an unsecured network.

5. Intrusion indication for the user or server.

6. A method transportable to various platforms.

7. An easy to use and efficient protocol for secure use over a network.

The mutual authentication between two users Alice and Bob are explained below. The

steps involved in mutual authentication between Alice and Bob are discussed as follows:

Alice calculate the value of f(X) Where

Alice sends H (PW) [f(x)] and H (PW) [x] to Bob. Bob decrypts using the H (PW)

that is stored in the database to obtain f(x) and x. Bob generates value y and prime

number b and calculates

The session key k is generated by Bob

Bob encrypts values x, y using key k as k[x, y] and encrypts values g(x), g(y), g(x, y)

using H (PW) as H (PW) [g(x), g(y), g(x, y)] and sends to Alice.

36


Alice decrypts g(x), g(y), g(x, y) and generates the key k using

and decrypts k[x, y] and verifies for the value of x.

Alice generates the function values:

Alice encrypts y with session key k. Alice sends f(y), f(x, y), f (g(x, y)), and k [y] to Bob.

Bob decrypts k[y] to verify the value y. Bob computes g (f(x), f(y)) and compares with f

(g(x, y)) for authentication and sends g (f(x, y)) to Alice. Alice computes f (g(x), g(y))

and compares the value to g(f(x, y)) to authenticate Bob. Thus, Alice and Bob

authenticated each other through mutual authentication protocol.

BASIC PASSWORD AUTHENTICATION AND KEY EXCHANGE

PROTOCOL MODULE

System Model:

The three entities that are involved in the system are the users , Service server ,

and the control server . The service server is the public server and the control server is

the hidden back end server in the two server model. In this protocol the users can only

communicate with the public server and the control server is away from the users. Users

are not aware about the control server and it is especially used for user authentication.

The user’s long secrets passwords are transformed into two secret Passwords which are

held by public server and the control server. The two server based on the secret passwords

validate the user while login.

User Registration:

37


The user must beforehand register with the servers by establishing a shared

password. The password is divided as and the long random numbers such that

, where q is the prime numbers. The passwords are stored in the two servers

with the user id and the password as ( , ) and ( , ) respectively. registers to

control server through postal mail. To initiate a request for the server, user sends his

identity together with a service request to in .

Basic Password Authentication Protocol:

The mutual authentication and key Exchange enables between user and public

server . We outline the basic password authentication protocol here. The notations and

symbols followed are tabulated in table below.

Fig: 8.2.2 Basic Password Authentication Protocol

The user initiates the request after completing the user registration phase with the

in message .The sends the request to with the user id in . Then

computes the value of by selecting a random number from the set .The selects

38


the random number from the set to compute the value of .We omitted the

modulo p notation for arithmetic operation. The sends the value to in . now

computes and sends to user in .

The selects the random number from the set and computes the following

values and then sends A, to in . The

computes then passes A, and to in . The computes and checks the

value of to authenticate the user and then passes to in . The computes

and , it checks the value of and authenticates the user. The session key is

established between the and . The sends the value of to in . The also

authenticates the by comparing the values of . Thus, the basic protocol works where

both the server and the user authenticate each other and establishes the connection.

PROPOSED PASSWORD AUTHENTICATION AND KEY EXCHANGE

PROTOCOL MODULE:

The three entities that are involved in the system are the users , Service server ,

and the control server . The service server is the public server and the control server is

the hidden back end server in the two server model. In this protocol the users can only

communicate with the public server and the control server is away from the users. Users

are not aware about the control server and it is especially used for user authentication.

The user’s long secrets passwords are transformed into two secret passwords which are

held by public server and the control server. The two server based on the secret passwords

validate the user while login.

User Registration:

The user must beforehand register with the servers by establishing a shared

password. The password is divided as and the long random numbers such that

, where q is the prime numbers. The passwords are stored in the two servers

with the user id and the password as ( , ) and ( , ) respectively.

39


registers to control server through postal mail. To initiate a request for

the server, user sends his identity together with a service request to in .

Proposed Password Authentication Protocol:

The mutual authentication and key Exchange enables between user and servers

and . We outline the proposed password authentication protocol here. The

notations and symbols followed are tabulated in table 8.1. The user initiates the request

after completing the user registration phase with the servers or in message

. If the user request , then computes the value of ,

and . sends to in .

decrypts using the hash that is stored in the database to obtain f(x) and x.

then computes ,, , ,

and . sends the to

in . computes , ,

and . sends

to in . checks the values

to authenticate the . computes

meanwhile computes . sends

to in . computes and validates to authenticate the

and . sends the value to user in .

The user computes , and . The user sends A,

to in . computes and sends the value A, and to

in . computes and authenticates the by checking

the values of . sends the value of to in .

computes

,

, and

40


then passes the value to user in . The also authenticates the by

comparing the values of . Thus, the basic protocol works where both the server and the

user authenticate each other and establishes the connection.

DECISIONAL DIFFIE-HELLMAN ASSUMPTION MODULE:

Let p, q be the prime numbers and g, h of order , for probabilistic polynomial

time algorithm , the following condition is satisfied:

Where , , and is a negligible function. That is computationally intractable

for to distinguish between and .

1. The protocol is robust against offline dictionary attacks by control server as a

passive adversary.

2. When the control server is controlled by a passive adversary, the intruder may

eavesdrop on the communication channels to collect protocol transcript.

The attacks against the password of the user. Control server can obtain

from . The control server cannot know anything of .

3. The protocol is robust against offline dictionary attacks by public server as an

active adversary.

4. The public server is unable to learn on either or from the two pairs. The

values that are coming from user and control server are replaced and passed to

other so it is secured from offline dictionary attacks.

41


9. SYSTEM IMPLEMENTATION

Implementation is most crucial stage in achieving a successful system and giving

the user confidence that the new system in workable and achievable.

9.1 TECHNOLOGIES USED:

9.1.1 INTRODUCTION TO SERVLETS:

Servlets provide a Java based solution used to address the problems currently

associated with doing server-side programming, including inextensible scripting

solutions, platform-specific APIs, and incomplete interfaces. Servlets are objects that

conform to a specific interface that can be plugged into a Java-based server. Servlets are

to the server-side where applets are to the client-side object byte codes that can be

dynamically loaded off the net. They differ from applets in that they are faceless objects

42

WEB SERVER

JVM

SERVLET

CLEINTRequest

Response

Servlet Name + parameters

DATA BASE


(without graphics or a GUI component). They serve as platform-independent,

dynamically-loadable, pluggable helper byte code objects on the server side that can be

used to dynamically extend server-side functionality.

What is a Servlet?

Fig 9.1.1.1 Working of the servlet

Servlets are modules that extend request/response-oriented servers, such as

Java-enabled web servers. For example, a servlet might be responsible for taking data in

an HTML order-entry form and applying the business logic used to update a company's

order database. Servlets are to servers what applets are to browsers. Unlike applets,

however, servlets have no graphical user interface. Servlets can be embedded in many

different servers because the servlet API, which you use to write servlets, assumes

nothing about the server's environment or protocol. Servlets have become most widely

used within HTTP servers; many web servers support the Servlet API.

Architecture of the Servlet Package:

The javax.servlet package provides interfaces and classes for writing servlets. The

architecture of the package is described below.

43


The Servlet Interface:

The central abstraction in the Servlet API is the Servlet interface. All servlets

implement this interface, either directly or, more commonly, by extending a class that

implements it such as HttpServlet.

Fig 9.1.1.2 Servlet Interface

The Servlet interface declares, but does not implement, methods that manage the

servlet and its communications with clients. Servlet writers provide some or all of these

methods when developing a servlet.

Client Interaction:

When a servlet accepts a call from a client, it receives two objects:

1. A Servlet Request, which encapsulates the communication from the client to the

server.

2. A Servlet Response, which encapsulates the communication from the servlet back

to the client.

Servlet Request and Servlet Response are interfaces defined by the javax.servlet package.

The Servlet Request Interface:

The Servlet Request interface allows the servlet access to:

44

INSTANCECLASS

INIT

SERVICE

DESTROY

DOGETDOPOST


1. Information such as the names of the parameters passed in by the client, the

protocol (scheme) being used by the client, and the names of the remote host that

made the request and the server that received it.

2. The input stream, ServletInputStream. Servlets use the input stream to get data

from clients that use application protocols such as the HTTP POST and PUT

methods.

Interfaces that extend ServletRequest interface allow the servlet to retrieve more

protocol-specific data. For example, the HttpServletRequest interface contains methods

for accessing HTTP-specific header information.

The Servlet Response Interface:

The Servlet Response interface gives the servlet methods for replying to the client.

It:

1. Allows the servlet to set the content length and MIME type of the reply.

2. Provides an output stream, ServletOutputStream, and a Writer through which the

servlet can send the reply data.

Interfaces that extend the ServletResponse interface give the servlet more

protocol-specific capabilities. For example, the HttpServletResponse interface contains

methods that allow the servlet to manipulate HTTP-specific header information.

Servlet Lifecycle:

Each servlet has the same life cycle:

1. A server loads and initializes the servlet.

2. The servlet handles zero or more client requests.

3. The server removes the servlet

45


Fig 9.1.1.3 Servlet Life Cycle

Fig 9.1.4 The hierarchy structure to deploy the servlet file in tomcat web server

9.1.1.2 JAVA SERVER PAGES (JSP)

A Java Server page is a simple, yet powerful technology for creating and

maintaining dynamic-content webs pages. Based on the Java programming language,

Java Server Pages offers proven portability, open standards, and a mature re-usable

component model.

The Java Server Pages architecture enables the separation of content generation

from content presentation. This separation not only eases maintenance headaches, it also

46

TOMCAT

Own Folder

WEB-INF

Classes

web.xml

Package folder Class files

Class files


allows web team members to focus on their areas of expertise. Now, webpage designers

can concentrate on layout, and web application designers on programming, with minimal

concern about impacting each other’s work. The rest of this document gives you the

bigger picture:

1. Portability

2. Composition

3. Processing

4. Access Models

1. Portability:

Java Server Pages files can be run on any web server or web-enabled application

server that provides support for them. Debugged the JSP engine, this support involves

recognition, translation, and management of the Java Server Page lifecycle and its

interactions with associated components.

The JSP engine for a particular server might be built-in or might be provided

through a 3rd-party and-on. As long as the server on which you plan to execute the Java

Server Pages supports the same specification level as that to which the file was written,

no changes should be necessary as you move your files from server to server.

Note, however, that instructions for the setup and configuration of the files may

differ between files.

To date, there has been no upwards or backwards-compatibility between Java Server

Pages specifications. A Java Server Pages file written to the 0.92 specification can be run

only on a server supporting Java Server Pages 0.92. The same file could not run on a

server supporting only Java Server Pages 1.0 or Java Server Pages 0.91.

2. Composition:

47


It was mentioned earlier that the Java Server Pages architecture can include

reusable Java components. The architecture also allows for the embedding of a scripting

language directly into the Java Server Pages file.

The components current supported include JavaBeans, and Servlets. Support for

Enterprise Java Beans components will likely be added in a future release. As the default

scripting language, Java Server Pages use the Java programming language. This means

that scripting on the server side can take advantage of the full set of capabilities that the

Java Programming language offers. Support for other scripting languages might become

available in the future.

3. Processing:

A Java Server Pages file is essentially an HTML document with JSP scripting or

tags. It may have associated components in the form of .class, .jar, or .ser files- - or it

may not. The use of components is not required.

The Java Server Pages file has a .jsp extension to identify it to the server as a Java

Server Pages file. Before the page is served, the Java Server Pages syntax is parsed and

processed into a servlet on the server side. The servlet that is generated outputs real

content in straight HTML for responding to the client. Because it is standard HTML, the

dynamically generated response looks no different to the client browser than a static

response.

4. Access Models:

A JavaServer Pages file may be accessed in at least two different ways:

A client request comes directly into a JavaServer Page.

48


Fig 8.1.2.1: JSP access model

In this scenario, suppose the page accesses reusable Java Bean components that

perform particular well-defined computations like accessing a database. The result of the

Bean’s computations, called result sets are stored within the Bean as properties. The page

uses such Beans to generate dynamic content and present it back to the client.

A request comes through a servlet.

Fig:9.1.2.1 : Access Model

The servlet generates the dynamic content. To handle the response to the client,

the servlet creates a Bean and stores the dynamic content (sometimes called the result set)

in the Bean. The servlet then invokes a JavaServer Page that will present the content

along with the Bean containing the generated from the servlet.

49

Browser

Bean

JSP

Request

Response

Servlet

JSP

Database

Browser

Bean

JDBC

Request

Response


There are two APIs to support this model of request processing using JavaServer

Pages. One API facilitates passing context between the invoking servlet and the

JavaServer Page. The other API lets the invoking servlet specify which JavaServer Page

to use.

In both of the above cases, the page could also contain any valid Java code. The

JavaServer Pages architecture encourages separation of content from presentation - - it

does not mandate it.

9.1.3 APACHE TOMCAT:

Apache Tomcat is the servlet container that is used in the official Reference

Implementation for the Java Servlet and Java Server Pages technologies. The Java Servlet

and Java Server Pages specifications are developed by Sun under the Java Community

Process. Apache Tomcat is developed in an open and participatory environment and

released under the Apache Software License. Apache Tomcat is intended to be a

collaboration of the best-of-breed developers from around the world.

Apache Tomcat powers numerous large-scale, mission-critical web applications

across a diverse range of industries and organizations.

Apache lends itself particularly well to projects that are heavily Java based. It

offers superior handling of the Java Database Connectivity (JDBC) application program

interface (a program which allows Java-based service to access information, stored in

SQL-compliant databases).

Apache, like Linux, is a piece of open-source software. It's maintained by a group

of programmers who create the software for the thrill of it - not for any expected financial

gain.

Apache was born in early 1995, as free Web server software based around NCSA

http 1.3, which was the most popular Web server of the day, and a bunch of software

patches. From that it earned it's moniker, which stands for "APACHE server." Since then,

it has been completely re-written, and has become the most popular WWW server on the

Internet.

50


Apache pros:

Open source updates:

It’s constantly being updated and you can add functionality as it becomes

available.

Free:

The software is free. It's hard to beat that price.

Multi-platform support:

Apache can be used on systems that have 80x86-series (i.e. Intel) processors

running either Linux or NT as an OS, or on other computers running a Unix-type OS on a

different processor.

Popular:

Apache is the most-used Web server software package in the world. As such, it's

unlikely that further development of the software will ever cease.

Apache cons:

No Support:

Apache's developers do not provide any type of support for their product. There

are third-party companies that provide Apache support, but you have to pay for it.

9.2 HASH ALGORITHM:

A keyed-hash message authentication code, or HMAC, is a type of message

authentication code (MAC) calculated using a cryptographic hash function in

combination with a secret key. As with any MAC, it may be used to simultaneously

verify both the data integrity and the authenticity of a message. Any iterative

cryptographic hash function, such as MD5 or SHA-1, may be used in the calculation of an

51

http://en.wikipedia.org/wiki/SHA-1

http://en.wikipedia.org/wiki/MD5

http://en.wikipedia.org/wiki/Message

http://en.wikipedia.org/wiki/Data_integrity

http://en.wikipedia.org/wiki/Cryptographic_key

http://en.wikipedia.org/wiki/Cryptographic_hash_function

http://en.wikipedia.org/wiki/Message_authentication_code

http://en.wikipedia.org/wiki/Message_authentication_code


HMAC, the resulting MAC algorithm is termed HMAC-MD5 or HMAC-SHA-1

accordingly. The cryptographic strength of the HMAC depends upon the cryptographic

strength of the underlying hash function and on the size and quality of the key. An

iterative hash function breaks up a message into blocks of a fixed size and iterates over

them with a compression function. For example, MD5 and SHA-1 operate on 512-bit

blocks. The size of the output of HMAC is the same as that of the underlying hash

function (128 or 160 bits in the case of MD5 and SHA-1), although it can be truncated if

desired.

HMAC is defined as

Where h is an iterated hash function, K is a secret key padded with extra zeros to the

block size of the hash function

m is the message to be authenticated, denotes concatenation, denotes exclusive

or, and the outer padding and inner padding

are two one-block–long hexadecimal constants.

9.3 CONTRIBUTION:

Fig 9.3.1 Proposed two server model

The work is continued by exposing the hidden control server to users so that user

can login to any one system at a time. The other server automatically acts as the control

52

http://en.wikipedia.org/wiki/Hexadecimal

http://en.wikipedia.org/wiki/Exclusive_or

http://en.wikipedia.org/wiki/Exclusive_or

http://en.wikipedia.org/wiki/Concatenation


server. In this proposed system the number users will be increased than basic system and

the control server can be used efficiently. The servers are made public so there may be

higher chances for attacks in between the servers. The protocol is designed to check

authentication between servers and between user and server. The mutual authentication

protocol is used to authenticate between servers before communication for user

authentication is involved. The basic password authentication protocol is used to

authenticate between user and servers. The password splitting techniques provides basic

security for the two server systems.

Three types of entities are involved in our system, i.e., users, a service server (SS)

that is the public server in the two server model, and a control server (CS) that is the

back-end server. In this setting, users only communicate with SS and do not necessarily

know CS. For the purpose of user authentication, a user U has a password which is

transformed into two long secrets, which are held by SS and CS, respectively. Based on

their respective shares, SS and CS together validate users during user login. We assume

the following security model.

CS is controlled by a passive adversary and SS is controlled by an active adversary

in terms of offline dictionary attacks to user passwords, but they do not collude

(otherwise, it equates the single-server model).

By definition, a passive adversary follows honest-but-curious behavior, that is, it

honestly executes the protocol according to the protocol specification and does not

modify data, but it eavesdrops on communication channels, collects protocol transcripts

and tries to derive user passwords from the transcripts; moreover, when an passive

adversary controls a server, it knows all internal states of knowledge known to the server,

including its private key (if any) and the shares of user passwords. In contrast, an active

adversary can act arbitrarily in order to uncover user passwords. Besides, we assume a

secret communication channel between SS and CS for this basic protocol.

We stress that this security model exploits the different levels of trust upon the two

servers. As discussed earlier, this clearly holds with respect to outside attackers. As far as

inside attackers are concerned, justifications come from our application and

generalization of the system to the architecture of a single control server supporting

multiple service servers, where the control server affords and deserves enforcing more

stringent security measurements against inside attackers. Notice that the assumption we

53


make here is already weaker than that in, where the back-end server is strictly passive and

is not allowed to eavesdrop on communication channels, while CS in our setting is

allowed for eavesdropping. We believe this weakening is important and more realistic

since eavesdropping is practically easy and insidious.

10. SYSTEM TESTING

10.1 INTRODUCTION TO TESTING:

Testing is a fault detection technique that tries to create failure or erroneous states

in a planned way. This allows the developer to detect failures in the system before it is

released to the customer. Note that this definition of testing implies that a successful test

is a test that identifies faults. We will use this definition throughout the development

phase. Another often used definition of testing is that “it demonstrates that faults are not

present”. We will use this definition only after the system when we try to demonstrate

that the delivered system fulfills the functional requirements.

If we used this second definition all the time, we would tend to select test data that

have a low probability of causing the program to fail. If on the other hand, the goal is to

demonstrate that program has faults, we would tend to look for test data with a higher

probability of finding faults. The characteristic of a good test model is that it contains test

cases that identify faults. Tests should include broad range of input values, including

54


invalid inputs and boundary cases, otherwise faults may not be detected. Unfortunately,

such an approach requires extremely lengthy testing times for even small systems.

1. Test Planning allocates resources and schedules the testing. This activity should

occur early in the development phase so that sufficient time and skill is dedicated

to testing. For example, developers can design test cases as soon as the models

they validate become stable.

2. Usability testing tries to find faults in the user interface design the system. Often

system fails to accomplish their intended purpose simply because their users are

confused by their user interface and unwillingly introduce erroneous data.

3. Unit testing tries to find faults in participating objects and/or subsystems with

respect to the cases from the use case model.

4. Integration testing is the activity of finding faults when testing the individual

tested components together, for example, subsystems described in the subsystem

decomposition, while executing the use cases and scenarios from the RAD

(Required Analysis Document).

5. Structural testing is the culmination of integration tests and structural tests exploit

knowledge from the SDD (System Design Document) using an integration

strategy described in the Test Plan (TP).

6. System testing tests all the components together, seen as a single system to

identify faults with respect to the scenarios from the problem statement and the

requirements and design goals is identified in the analysis and system design,

respectively.

7. Functional testing tests the requirements from the RAD and the user manual.

8. Performance testing checks the nonfunctional requirements and additional design

goals from the SDD. Functional and performance tests are done by developers.

55


9. Acceptance testing and installation testing check the system against the project

agreement and is done by the client, if necessary, the help by the developers.

10.2 TESTING CONCEPTS:

In this section, we present the model elements during testing

1. A component is a part of the system that can be isolated for testing. A component

can be an object, or one or more subsystems.

2. A fault also called bug or defect is a design or coding mistake that may cause

abnormal component behavior.

3. An erroneous state is a manifestation of a fault during the execution of the system.

An erroneous state is caused by one or more faults and can lead to failure.

4. A failure is a deviation between the specification and the actual behavior. A

failure is triggered by one or more erroneous states. Not all erroneous states

trigger a failure.

5. A test case is a set of inputs and expected results that exercises a component with

the purpose of causing failures and detecting faults.

6. A test stub is a partial implementation of a component that depends on the tested

component. Test stubs and drivers enable components to be isolated from the rest

of the system for testing.

7. A correction is a change to a component. The purpose of a correction is repair a

fault. Note that correction can introduce new faults.

10.3 TESTING OBJECTIVES:

1. Testing is process of executing a program with the internet of finding an error.

56


2. A good test case design is one that has a probability of finding an as yet undiscovered

error.

3. A successful test is one hat uncovers an as yet undiscovered error.

10.4 TEST CASE DESIGN:

Any Engineering product can be tested in one of two ways.

1. White Box Testing:

This testing is also called a Glass Box Testing. In this testing, by

knowing the specified function that a product has been designed to perform the test can

be conducted that demonstrates each function is fully operation at the same time

searching for errors in each function. It is a test case design method that uses the control

structure of the procedural design to derive test cases. Basis path testing is a white box

testing.

Basis Path Testing:

1. Flow Graph Notation

2. Cyclamatic Complexity

3. Deriving Test Cases

4. Graph matrices.

Control Structure Testing:

1. Condition Testing

2. Data flow Testing

3. Loop Testing

2. Black Box Testing:

57


In this testing by knowing the internal operation of a product tests can be

conducted to ensure that “all gears mesh”, that is the internal operation performs

according to specification and all internal components have been adequately exercised.

It fundamentally focuses on the functional requirements of the software.

The steps involved in black box testing case design are:

1. Graph based testing methods.

2. Equivalence partitioning.

3. Boundary value Analysis.

4. Comparison testing.

10.5 SOFTWARE TESTING STRATEGIES:

A software testing strategy provides a road map for the software developer.

Testing is a set of activities that can be planned in advance and conducted systematically.

For this reason a template for software testing a set of steps into which we can place

specific test case design methods should be designed for software engineering process.

Any software testing strategy should have the following characteristics:

1. Testing begins at the module level and works” outward” toward the integration of the

entire computer based system.

2. Different testing techniques are appropriate at different points in time.

3. The developer of the software and an independent test group conducts testing.

58


4. Testing and Debugging are different activities but debugging must be accommodated

in any testing strategy.

10.6 TEST CASES:

A test case is a set of input data and expected results that exercises a component

with purpose of causing failures and detecting faults. A test case has five attributes: name,

location, input, oracle, and log (table 11-1). The name of the test case allows the tester to

distinguish between different test cases. A heuristic for naming test cases is to derive the

name from the requirement it is testing or from the component being tested. For example,

if you are testing a use case cancel(), you might want to call the test case Test cancel. If a

test case involves two components A and B then a good name would be Test_AB. The

location attribute describes where the test case can be found.

TEST CASES:

Table 1 –Test Case Title: Registration of the user

Test Case # : Registration of the user Priority (H,L) : High

Test Objective : To Register the user

Test Description: With the username and password as the input, registering the user.

Requirements Verified: yes

Test Environment : Tomcat Server, Ms Access Database

Actions Expected Results

Valid userid and password entered user registered

Userid already existed user not registered

Pass : Yes Condition Pass: Fail :

Problems/Issues : None

59


Notes:Successfully Tested and Executed.

Table 2–Test Case Title: Login

Test Case # : Login Priority (H,L) : High

Test Objective: Checking whether the password is valid or not

Test Description: When the given user id and the password whose value matches ith the value that is stored in the database.Requirements Verified: yes

Test Environment : Tomcat Server, Ms Access Database

Actions Expected Results

Correct Username and password as input . login successful

wrong Username and password as input . login unsuccessfullPass : Yes Condition Pass: Fail :

Problems/Issues : None

Notes:Successfully Tested and Executed.

10.DISPLAY SCREENS

LOGIN FORM:

60


Fig 10.1 Login Form

NEW USER FORM:

61


Fig 10.2 NEW USER FORM

NEW USER VALIDATION FORM:

62


Fig 10.3 NEW USER VALIDATION FORM

PASSWORD VALIDATION FORM:

63


Fig 10.4 PASSWORD VALIDATION FORM

USER VALIDATION FORM:

64


Fig 10.5 USER VALIDATION FORM

VALID USER FORM:

65


Fig 10.6 VALID USER FORM

SERVICE SERVER DATABASE:

66


Fig 10.7 SERVICE SERVER DATABASE

CONTROL SERVER DATABASE:

67


Fig 10.8 CONTROL SERVER DATABASE

12. SYSTEM SECURITY

INTRODUCTION

The protection of computer based resources that include hardware, software, data,

procedures and people against unauthorized use or natural disaster is known as System

Security.

System Security can be divided into four related issues:

Security

Integrity

68


Privacy

Confidentiality

SYSTEM SECURITY refers to the technical innovations and procedures applied to the

hardware and operating systems to protect against deliberate or accidental damage from a

defined threat.

DATA SECURITY is the protection of data from loss, disclosure, modification and

destruction.

SYSTEM INTEGRITY refers to the power functioning of hardware and programs,

appropriate physical security and safety against external threats such as eavesdropping

and wiretapping.

PRIVACY defines the rights of the user or organizations to determine what information

they are willing to share with or accept from others and how the organization can be

protected against unwelcome, unfair or excessive dissemination of information about it.

CONFIDENTIALITY is a special status given to sensitive information in a database to

minimize the possible invasion of privacy. It is an attribute of information that

characterizes its need for protection.

Security Software:-

System security refers to various validations on data in form of checks and

controls to avoid the system from failing. It is always important to ensure that only valid

data is entered and only valid operations are performed on the system. The system

employees two types of checks and controls.

13. LIMITATIONS

Maintaining two servers is some what difficult.

The security model underlying the proposed protocols assumes that the control

server can only be controlled by a passive adversary.

69


14. CONCLUSION

The proposed authentication system can be used instead of existing single server

system such as FTP and email servers where the number of users can be increased by

providing two way user authentication using two servers. The future work to be carried is

designing the protocol in the wireless environment between users and servers and placing

a back up third server when any one of the server fails.

70


15. REFERENCES

1. E. Bresson, O. Chevassut, and D. Pointcheval, “Security Proofs for an Efficient

Password-Based Key Exchange”.

2. O. Goldreich, “Secure Multi-Party Computation”, version 1.3, June 2001.

3. D.P. Jablon, “Password Authentication Using Multiple Servers,” RSA Security

Conf., 2001.

71


Related Websites:

www.w3schools.com

www.javacompletereference.com

www.amazon.com

16. APPENDICES

PVD : Password Verification Data

SSL : Secure Socket Layer

MAP : Mutual Authenticating Protocol

HMAC : Hash Message Authentication Code

ALC : Analysis Level Classes

SRS : Software Requirements Specification

72

http://www.amazon.com/

http://www.javacompletereference.com/

http://www.w3schools.com/


JSP : Java Server Pages

SS : Service Server

CS : Control Server

RAD : Required Analysis Document

SDD : System Design Document

TP : Test Plan

73

Two-Key_Exchange

Documents

server authentication

authentication server

password authentication

single server

hidden server

backend server

servercontrol server

encrypted password