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
uname pass1 pass2

abcde 2.5 6.5
sarat 1.0 5.0
anto 0.5 4.5
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-
23
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.
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:
user registration
name name
password user id
password
login()
registration() login()
service server database

controlserver
authentication() verify()
authentication() retrieve()
key exchange() key exchange()
verification() update()
Fig: 7.3.1 Class diagram
7.4 USE-CASE DIAGRAM:
25
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.
user service control database

server server
1: login
2: check details
3: 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
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.
control
server
user
1: login
4: new user
12: logout
2: check details
5: provide new user id &password
8: send second half to the control server
11: provide authentication

3: check the database
6: store the details of new user 9: generate a value for second half
7: divide the password

10: generate the value for the first half by using value of second half
databas
e service
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
Registration login
user
logout
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
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.
password
user service server control server
authentication
Fig 7.8.3: Key Exchange
8. SYSTEM MODULES
8.1 MODULAR DESIGN:
34
 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
Q, p, q , Large prime numbers such that Q = 2p +1 and p = 2q +1
a, b
g1 , g 2 Belongs to QR p where QR p is a quadratic residues of
mod p
x, y Random numbers
a 1 , b1 , b 2 Random numbers belongs to Zq
∏ User’s password
h (..) Hash function
35
Mutual Authentication Protocol Module:
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
f ( x) = x a mod n
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
g ( x) = ( x) b mod n
g ( y ) = ( y ) b mod n
g ( x, y ) = ( xy ) b mod n
The session key k is generated by Bob
36
k = ( f ( x ) * g ( x )) mod n
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.
Alice decrypts g(x), g(y), g(x, y) and generates the key k using
k = ( f ( x ) * g ( y )) mod n
and decrypts k[x, y] and verifies for the value of x.
Alice generates the function values:
f ( y ) = ( y ) a mod n
f ( x, y ) = ( xy ) a mod n
f ( g ( x, y )) = ( g ( x, y )) a mod n
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 U , Service server
SS , and the control server CS . 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
37
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 π
1 2 the long random numbers such that
π +π mod q , where q is the prime numbers. The passwords are stored in the two servers
1 2
with the user id and the password as ( U , π1 ) and ( U , π2 ) respectively. U registers π

2
to control server CS through postal mail. To initiate a request for the server, user U
sends his identity together with a service request Re q to Server1 in M 1 .
Basic Password Authentication Protocol:
The mutual authentication and key Exchange enables between user and public
server SS . We outline the basic password authentication protocol here. The notations and
symbols followed are tabulated in table below.
38
Fig: 8.2.2 Basic Password Authentication Protocol
The user initiates the request after completing the user registration phase with the
SS in message M 1 .The SS sends the request to CS with the user id in M 2 . Then SS
computes the value of B1 by selecting a random number b1 from the set z

q .The CS
b ∏
selects the random number b
2 from the set z
q to compute the value of B =g 2g 2 .We
2 1 2
omitted the modulo p notation for arithmetic operation. The CS sends the value B 2 to
SS in M 3 . SS now computes B and sends to user U in M 4 .
The U selects the random number a from the set z
q and computes the
following values A = g1a S 'u = g 1a ( b1 +b 2 ) and S u = h (g1a ( b1 +b 2 ) ) then sends A, S u to SS in
M 5 . The SS computes S1 then passes A, S u and S1 to CS in M 6 . The CS computes

S2 and S u checks the value of S u to authenticate the user and then passes S2 to SS in
M 7 . The SS computes S u and S s , it checks the value of S u and authenticates the user.
The session key K is established between the SS and U . The SS sends the value of S
s
to U in M 8 . The U also authenticates the SS by comparing the values of S s . 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 U , Service server
SS , and the control server CS . 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.
39
User Registration:
The user must beforehand register with the servers by establishing a shared
password. The password π is divided as π and π
1 2 the long random numbers such that
π +π mod q , where q is the prime numbers. The passwords are stored in the two servers
1 2
with the user id and the password as ( U , π1 ) and ( U , π2 ) respectively.
U registers π to control server CS through postal mail. To initiate a request

2
for the server, user U sends his identity together with a service request Re q to Server1
in M 1 .
Proposed Password Authentication Protocol:
The mutual authentication and key Exchange enables between user and servers
Server1 and Server 2 . 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 Server1 or Server 2
in message M 1 . If the user request Server1 , then Server1 computes the value of
f ( x) = x a mod n , U ' = h (∏1 )[f ( x )] and V ' = h (∏1 )[ x ] . Server1 sends uid, U ' , V ' to
Server 2 in M 2 .
Server 2 decrypts using the hash that is stored in the database to obtain f(x) and x.
Server 2 then computes g ( x ) = x b mod n ,, g ( y) = y b mod n , g ( x , y) = ( xy) b mod n ,
k = (f ( x ) * g ( x )) mod n and U '' =h (∏2 )[g ( x ), g ( y), g ( x , y)] . Server 2 sends the ''
U , k[ x , y ]
to Server1 in M 3 . Server1 computes k = (f ( x ) * g ( y)) mod n , f ( y) = y a mod n ,
f ( x , y) = ( xy) a mod n and f (g ( x , y)) =(g ( x , y)) a mod n . Server1 sends

f ( y ), f ( x , y ), f ( g ( x , y )), k[ y ] to Server 2 in M 4 . Server 2 checks the values
?
g (f ( x ), f ( y)) =f (g ( x , y)) to authenticate the Server1 . Server 2 computes
b b
B 2 = g1 2 g ∏ 2
2 mod p
meanwhile Server1 computes B = g 1g ∏1 mod p . Server 2 sends
1 1 2
g ( f ( x , y )), B 2 to Server1 in M 5 . Server1 computes and validates to authenticate the
?
Server 2 f (g ( x ), g ( y )) =g (f ( x , y)) and B = B1B2 mod p . Server1 sends the value B to
40
a
S'u = (B / g ∏ ) 1 mod p
a
user U in M 6 . The user U computes A = g11 mod p , and Su = h (S'u ) .
2
b
The user U sends A, S u to Server1 in M 7 . Server1 computes S1 = A 1 mod p and
b
sends the value A, S u and S1 to Server 2 in M 8 . Server 2 computes S 2 = A 2 mod p and
?
authenticates the Server1 by checking the values of S u = h (S S 2 mod p) . Server 2
1 sends
the value of S2 to Server1 in M9 . Server1 computes
? b1
S u = h (SA
2 mod p) ,
b
SS = h ( A 1 S 2 mod p) , and
b
K = h ( uid , ser1, A 1S 2 mod p)
then passes the value S

s to user U in M10 . The U also authenticates the Server1 by
comparing the values of S s . 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 ∈ z

R q of order q , for probabilistic
polynomial time algorithm A , the following condition is satisfied:
DDH r r r
Adv ( A) =| Pr[ A( g , h , g , h )] −Pr[ A( g , h , g , z )] |<∈
G
Where r ∈ z
R q , ∈ QR
R p , and ∈ is a negligible function. That is computationally
intractable for A to distinguish between ( g , h, g
r
,h
r
) and ( g , h, g r , z ) .
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.
41
The attacks against the password of the user. Control server can obtain B
1
from M 4 . The control server cannot know anything of π1 .

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 π
2 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.
9. SYSTEM IMPLEMENTATION
42
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
(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?
Request WEB
CLEINT SERVER
Servlet
Name +
parameters
JVM
Response DATA
SERVLET BASE
43
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.
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.
44
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:
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.
45
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
CLASS INSTANCE
INIT
DOPOST SERVICE DOGET
DESTROY
Fig 9.1.1.3 Servlet Life Cycle
46
TOMCAT
Own Folder
WEB-INF web.xml
Classes Class files
Package folder Class files
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
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
47
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:
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.
48
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.
Bean
Request
Browser
JSP
Response
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.
49
Request
Servlet
JDBC Database
Browser
Response Bean
JSP
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.
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.
50
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.
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.
51
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
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
52
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
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.
53
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
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.
54
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
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.
55
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.
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.
56
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.
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.
57
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:
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.
58
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.
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.
59
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
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 unsuccessfull

Pass : Yes Condition Pass: Fail :
Problems/Issues : None
Notes:Successfully Tested and Executed.
60
10.DISPLAY SCREENS
LOGIN FORM:
Fig 10.1 Login Form
61
NEW USER FORM:
Fig 10.2 NEW USER FORM
62
NEW USER VALIDATION FORM:
Fig 10.3 NEW USER VALIDATION FORM
63
PASSWORD VALIDATION FORM:
Fig 10.4 PASSWORD VALIDATION FORM
64
USER VALIDATION FORM:
Fig 10.5 USER VALIDATION FORM
65
VALID USER FORM:
Fig 10.6 VALID USER FORM
66
SERVICE SERVER DATABASE:
Fig 10.7 SERVICE SERVER DATABASE
67
CONTROL SERVER DATABASE:
Fig 10.8 CONTROL SERVER DATABASE
68
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
• 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.
69
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.
70
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.
71
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.
Related Websites:
 www.w3schools.com
 www.javacompletereference.com
 www.amazon.com
72
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
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

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Two-Key Exchange

Uploaded by

Copyright:

Available Formats

A Practical Password based Two Server Authentication and Key Exchange System

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

2. SCOPE OF THE PROJECT

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

3.1 INTRODUCTION TO PROJECT:

Password Authentication is the most widely used method. Password based

Most password-based authentication systems employ a Secure Socket Layer

3.2 PROBLEM SPECIFICATION:

Passwords are the most common method of authentication used to control

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

There are two ways of attacking passwords:

There are three types of cracking attacks:

2. Brute force attacks:

Hybrid attacks build on dictionary attacks by adding or substituting other

3.3 COMPANY PROFILE:

Research and development Training makes students to understand new concepts,

4.1 EXISTING SYSTEM:

Single Server Model:

Fig: 4.1.1 Single Server Model

Fig: 4.1.2 Multi-server model

Gateway Multi-Server Model:

Fig: 4.1.3 Gateway multi-server model

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

4.2 PROPOSED SYSTEM:

Two Server Model:

Fig: 4.2.1 Two Server Model

Three key considerations involved in the feasibility analysis:

5.1 ECONOMIC FEASIBILITY:

5.2 TECHNICAL FEASIBILITY:

5.3 BEHAVIORAL FEASIBILITY:

5.4 TECHNICAL ANALYSIS:

 Short term implementation consideration

6. SOFTWARE REQUIREMENT SPECIFICATIONS

Software requirements specification is the starting point of software development

6.2 USER REQUIREMENTS:

6.3 SOFTWARE REQUIREMENTS:

6.4 HARDWARE REQUIREMENTS:

6.5 FUNCTIONAL REQUIREMENTS:

The project mainly contains the following modules

6.6 PERFORMANCE REQUIREMENTS:

6.7 INTRODUCTION TO JAVA

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

Applet Life Cycle:

List Boxes and Combo Boxes:

Sliders and Progress Bars:

Using a JTree can be as simple as saying:

Detailed design focuses on refinements to the architectural representations that

7.2 DATA DICTIONARY:

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

uname pass1 pass2

7.3 CLASS DIAGRAM:

service server database

Fig: 7.3.1 Class diagram

7.4 USE-CASE DIAGRAM:

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

Common uses of use-case diagram:

Identifying the actors:

Actors can be identified by following questions:

Identifying the use-cases:

USE CASE DIAGRAM:

Fig: 7.4.1 Use case diagram

7.5 SEQUENCE DIAGRAM: