3. 1. INTRODUCTION
1.1 PROBLEM DEFINITION
By definition, authentication is the use of one or more mechanisms to prove that you
are who you claim to be. Once the identity of the human or machine is validated, access is
granted. Three universally recognized authentication factors exist today: what you know (e.g.
passwords), what you have (e.g. ATM card or tokens), and what you are (e.g. biometrics).
Recent work has been done in trying alternative factors such as a fourth factor, e.g. somebody
you know, which is based on the notion of vouching.
Most systems today rely on ‘static passwords’ to verify the user’s identity. However,
such passwords come with major management security concerns. Users tend to use easy-to-
guess passwords, use the same password in multiple accounts, write the passwords or store
them on their machines, etc. Furthermore, hackers have the option of using many techniques
to steal passwords such as shoulder surfing, snooping, sniffing, guessing, etc.
Passwords are known to be one of the easiest targets of hackers. Therefore, most
organizations are looking for more secure methods to protect their customers and employees.
Biometrics are known to be very secure and are used in special organizations, but they are not
used much in secure online transactions or ATM machines given the expensive hardware that
is needed to identify the subject and the maintenance costs, etc.
1.2 EXISTING SYSTEM:
Two factor authentication is a mechanism which implements two of the above
mentioned factors and is therefore considered stronger and more secure than the traditionally
implemented one factor authentication system. Withdrawing money from an ATM machine
utilizes two factor authentication; the user must possess the ATM card, i.e. what you have,
and must know a unique personal identification number (PIN), i.e. what you know. Banks
and companies are using tokens as a mean of two factor authentication.
A security token is a physical device that an authorized user of computer services is
given to aid in authentication. It is also referred to as an authentication token or a
cryptographic token. Tokens come in two formats: hardware and software. Hardware tokens
are small devices which are small and can be conveniently carried.
4. Some of these tokens store cryptographic keys or biometric data, while others display
a PIN that changes with time. At any particular time when a user wishes to log-in, i.e.
authenticate, he uses the PIN displayed on the token in addition to his normal account
password. Software tokens are programs that run on computers and provide a PIN those
changes with time. Such programs implement a One Time Password (OTP) algorithm. OTP
algorithms are critical to the security of systems employing them since unauthorized users
should not be able to guess the next password in the sequence. The sequence should be
random to the maximum possible extent, unpredictable, and irreversible. Factors that can be
used in OTP generation include names, time, seed, etc. Several commercial two factor
authentication systems exist today such as BestBuy’s BesToken, RSA’s SecurID, and Secure
Computing’s Safeword.
1.2.1 DISADVANTAGES:
1. Using tokens involves several steps including registration of users, token production
and distribution, user and token authentication, and user and token revocation among
others
2. Expensive: While tokens provide a much safer environment for users, it can be very
costly for organizations. For example, a bank with a million customers will have to
purchase, install, and maintain a million tokens.
3. Training to use tokens: Furthermore, the bank has to provide continuous support for
training customers on how to use the tokens.
4. Replacement if token gets stolen or broke: The banks have to also be ready to
provide replacements if a token breaks or gets stolen. Replacing a token is a lot more
expensive than replacing an ATM card or resetting a password.
5. need to carry multiple tokens: From the customer’s prospective, having an account
with more than one bank means the need to carry and maintain several tokens which
constitute a big inconvenience and can lead to tokens being lost, stolen, or broken. In
many cases, the customers are charged for each token.
5. 1.3 PROPOSED SYSTEM
Two factor authentication using devices such as tokens and ATM cards has been
proposed to solve the password problem and have shown to be difficult to hack. And using
hardware tokens in two factor authentication also leads to many problems as mentioned
above. Therefore, we propose a mobile-based software token that will save the organizations
the cost of purchasing and maintaining the hardware tokens. Furthermore, it will allow
customers to install multiple software tokens on their mobile phones. Hence, they will only
worry about their mobile phones instead of worrying about several hardware tokens.
Mobile phones have traditionally been regarded as a tool for making phone calls. But
today, given the advances in hardware and software, mobile phones use have been expanded
to send messages, check emails, store contacts, etc. Mobile connectivity options have also
increased. After standard GSM connections, mobile phones now have infra-red, Bluetooth,
3G, and WLAN connectivity. Most of us, if not all of us, carry mobile phones for
communication purpose. Several mobile banking services available take advantage of the
improving capabilities of mobile devices. From being able to receive information on account
balances in the form of SMS messages to using WAP and Java together with GPRS to allow
fund transfers between accounts, stock trading, and confirmation of direct payments via the
phone’s micro browser. Installing both vendor-specific and third party applications allow
mobile phones to provide expanded new services other than communication. Consequently,
using the mobile phone as a token will make it easier for the customer to deal with multiple
two factor authentication systems; in addition it will reduce the cost of manufacturing,
distributing, and maintaining millions of tokens.
1.4 SELECTION OF S/W & HARDWARE STRUCTURE
HARDWARE REQUIREMENTS
• RAM: 256MB minimum
• Hard Disk: 2 GB minimum
• Processor: Intel Pentium 4 or above
• Operating System: Windows
• GSM Modem
6.
7. SOFTWARE REQUIREMENTS
• Programming Language: java, j2me
• Web Technology: html, jsp
• Web Server: Tomcat
• Back End: Oracle 10g
• IDE: Netbeans
• Message Server
1.5. SYSTEM REQUIREMENT SPECIFICATION
A System Requirements Specification (SRS) - a requirements specification for a
software system - is a complete description of the behavior of a system to be developed. It
includes a set of use cases that describe all the interactions the users will have with the
software. Use cases are also known as functional requirements. In addition to use cases, the
SRS also contains non-functional (or supplementary) requirements. Non-functional
requirements are requirements, which impose constraints on the design or implementation
(such as performance engineering requirements, quality standards, or design constraints).
The system requirements are broadly classified as
Functional requirements
Non functional requirements
FUNCTIONAL REQUIREMENTS
We propose a mobile-based software token system that is supposed to replace existing
hardware and computer-based software tokens. The proposed system is secure and consists of
three parts:
(1) software installed on the client’s mobile phone,
(2) server software, and
(3) a GSM modem connected to the server.
The system will have two modes of operation:
Connection-Less Authentication System: A onetime password (OTP) is generated
without connecting the client to the server. The mobile phone will act as a token and use
8. certain factors unique to it among other factors to generate a one-time password locally.
The server will have all the required factors including the ones unique to each mobile
phone in order to generate the same password at the server side and compare it to the
password submitted by the client. The client may submit the password online or through a
device such as an ATM machine. A program will be installed on the client’s mobile
phone to generate the OTP.
SMS-Based Authentication System: In case the first method fails to work, the password
is rejected, or the client and server are out of sync, the mobile phone can request the one
time password directly from the server without the need to generate the OTP locally on
the mobile phone. In order for the server to verify the identity of the user, the mobile
phone sends to the server, via an SMS message, information unique to the user. The
server checks the SMS content and if correct, returns a randomly generated OTP to the
mobile phone. The user will then have a given amount of time to use the OTP before it
expires. Note that this method will require both the client and server to pay for the
telecommunication charges of sending the SMS message.
Two factor authentication using mobile phones involves 3 main modules. They are
1. Generation of OTP
2. Client Design
3. Server Design
OTP Algorithm
In order to secure the system, the generated OTP must be hard to guess, retrieve, or trace by
hackers. Therefore, it’s very important to develop a secure OTP generating algorithm.
Several factors can be used by the OTP algorithm to generate a difficult-to-guess password.
Users seem to be willing to use simple factors such as their mobile number and a PIN for
services such as authorizing mobile micro payments [9]. Note that these factors must exist on
both the mobile phone and server in order for both sides to generate the same password. In
the proposed design, the following factors were chosen:
• IMEI number: The term stands for International Mobile Equipment Identity which is
unique to each mobile phone allowing each user to be identified by his device. This is
accessible on the mobile phone and will be stored in the server’s database for each client.
9. • IMSI number: The term stands for International Mobile Subscriber Identity which is a
unique number associated with all GSM and Universal Mobile Telecommunications System
(UMTS) network mobile phone users. It is stored in the Subscriber Identity Module (SIM)
card in the mobile phone. This number will also be stored in the server’s database for each
client.
• Username: Although no longer required because the IMEI will uniquely identify the user
anyway. This is used together with the PIN to protect the user in case the mobile phone is
stolen.
• PIN: This is required to verify that no one other than the user is using the phone to generate
the user’s OTP. The PIN together with the username is data that only the user knows so even
if the mobile phone is stolen the OTP cannot be generated correctly without knowing the
user’s PIN. Note that the username and the PIN are never stored in the mobile’s memory.
They are just used to generate the OTP and discarded immediately after that. In order for the
PIN to be hard
to guess or brute-forced by the hacker, a minimum of 8-characters long PIN is requested with
a mixture of upper- and lower-case characters, digits, and symbols.
• Hour: This allows the OTP generated each hour to be unique.
• Minute: This would make the OTP generated each minute to be unique; hence the OTP
would be valid for one minute only and might be inconvenient to the user. An alternative
solution is to only use the first digit of the minute which will make the password valid for ten
minutes and will be more convenient for the users, since some users need more than a minute
to read and enter the OTP. Note that the software can be modified to allow the administrators
to select their preferred OTP validity interval.
• Day: Makes the OTP set unique to each day of the week.
• Year/Month/Date: Using the last two digits of the year and the date and month makes the
OTP unique for that particular date. The time is retrieved by the client and server from the
telecommunication company. This will ensure the correct time synchronization between both
sides.
The above factors are concatenated and the result is hashed using SHA-256 which
returns a 256 bit message. The message is then XOR-ed with the PIN replicated to 256
characters. The result is then Base64 encoded which yields a 28 character message. The
message is then shrunk to an administrator-specified length by breaking it into two halves and
XOR-ing the two halves repeatedly. This process results in a password that is unique for a ten
minute interval for a specific user. Keeping the password at 28 characters is more secure but
10. more difficult to use by the client, since the user must enter all 28 characters to the online
webpage or ATM machine. The shorter the OTP message the easier it is for the user, but also
the easier it is to be hacked. The proposed system gives the administrator the advantage of
selecting the password’s length based on his preference and security needs.
Client Design
A J2ME program is developed and installed on the mobile phone to generate the OTP.
The program has an easy to use GUI that is developed using the NetBeans drag and drop
interface. The program can run on any J2ME-enabled mobile phone. The OTP program has
the option of (1) generating the OTP locally using the mobile credentials, e.g. IMEI and IMSI
numbers, or (2) requesting the OTP from the server via an SMS message. The default option
is the first method which is cheaper since no SMS messages are exchanged between the client
and the server. However, the user has the option to select the SMS-based method. In order for
the user to run the OTP program, the user must enter his username and PIN and select the
OTP generation method. The username, PIN, and generated OTP are never stored on the
mobile phone. If the user selects the connection-less method the username and PIN are used
to locally generate the OTP and are discarded thereafter. The username and PIN are stored on
the server’s side to generate the same OTP. If the user selects the SMS-based method, the
username and PIN, in addition to the mobile identification factors, are encrypted via a 256-bit
symmetric key in the OTP algorithm and sent via an SMS to the server. The server decrypts
the message via the same 256-bit symmetric key, extracts the identification factors, compares
the factors to the ones stored in the database, generates an OTP and sends the OTP to the
client’s mobile phone if the factors are valid. The advantage of encrypting the SMS message
is to prohibit sniffing or man-in-the-middle attacks. The 256-bit key will be extremely hard to
brute-force by the hacker. Note that each user will have a pre-defined unique 256-bit
symmetric key that is stored on both the server and client at registration time.
Server Design
A server is implemented to generate the OTP on the organization’s side. The server
consists of a database as described in Section 3.C and is connected to a GSM modem for
SMS messages exchange. The server application is multithreaded. The first thread is
responsible for initializing the database and SMS modem, and listening on the modem for
client requests. The second thread is responsible for verifying the SMS information, and
generating and sending the OTP. A third thread is used to compare the OTP to the one
11. retrieved using the connection-less method. In order to setup the database, the client must
register in person at the organization. The client’s mobile phone/SIM card identification
factors, e.g. IMEI/IMSI, are retrieved and stored in the database, in addition to the username
and PIN. The J2ME OTP generating software is installed on the mobile phone.
The software is configured to connect to the server’s GSM modem in case the SMS
option is used. A unique symmetric key is also generated and installed on both the mobile
phone and server. Both parties are ready to generate the OTP at that point.
NONFUNCTIONAL REQUIREMENTS
In systems engineering and requirements engineering, a non-functional requirement is
a requirement that specifies criteria that can be used to judge the operation of a system, rather
than specific behaviors. This should be contrasted with functional requirements that define
specific behavior or functions. The plan for implementing non-functional requirements is
detailed in the system architecture.
The non-functional requirements are "system shall be <requirement>". Non-
functional requirements are often called qualities of a system.
The following are the Non functional requirements for our system:
Availability A system's availability, or "uptime," is the amount of time that it is
operational and available for use.
Efficiency Specifies how well the software utilizes scarce resources: CPU cycles,
disk space, memory, bandwidth, etc.
Flexibility
If the organization intends to increase or extend the functionality of the
software after it is deployed, that should be planned from the
beginning, it influences choices made during the design, development,
testing, and deployment of the system.
New modules can be easily integrated to our system without disturbing
the existing modules or modifying the logical database schema of the
12. existing applications.
Portability
Portability specifies the ease with which the software can be installed
on all necessary platforms, and the platforms on which it is expected to
run.
By using appropriate software versions released for different platforms
our project can be easily operated on any operating system, hence can
be said highly portable.
Integrity
Integrity requirements define the security attributes of the system,
restricting access to features or data to certain users and protecting the
privacy of data entered into the software.
Certain features access must be disabled to students such as giving
feedback more than once etc Access can also be disabled by providing
appropriate logins for students, faculty and administrator separately.
Scalability
Software that is scalable has the ability to handle a wide variety of
system configuration sizes. The nonfunctional requirements should
specify the ways in which the system may be expected to scale up (by
increasing hardware capacity, adding machines, etc.).
Our system can be easily expandable. Any additional requirements
such as hardware or software which increase the performance of the
system can be easily added. An additional server would be useful to
speed up the application.
Usability
Ease-of-use requirements address the factors that constitute the
capacity of the software to be understood, learned, and used by its
intended users.
Hyperlinks will be provided for each and every service the system
provides through which navigation will be easier. A system that has
high usability coefficient makes the work of the user easier.
13. Performance
The performance constraints specify the timing characteristics of the
software.
The tasks are more time sensitive here.
Table 1.1: Non-Functional Requirements
1.6 FEASIBILITY STUDY
Feasibility study is the test of a system proposal according to its workability, impact
on the organization, ability to meet user needs, and effective use of recourses. It focuses on
the evaluation of existing system and procedures analysis of alternative candidate system cost
estimates. Feasibility analysis was done to determine whether the system would be feasible.
The development of a computer based system or a product is more likely plagued by
resources and delivery dates. Feasibility study helps the analyst to decide whether or not to
proceed, amend, postpone or cancel the project, particularly important when the project is
large, complex and costly. Once the analysis of the user requirement is complement, the
system has to check for the compatibility and feasibility of the software package that is aimed
at. An important outcome of the preliminary investigation is the determination that the system
requested is feasible.
The primary areas of feasibility analysis are:
• Technical Feasibility
• Financial Feasibility
• Resource Feasibility
• Operational Feasibility
• Economical Feasibility
Technical Feasibility:
The technology used can be developed with the current equipments and has the technical
capacity to hold the data required by the new system.
This technology supports the modern trends of technology.
Easily accessible, more secure technologies.
14. Technical feasibility on the existing system and to what extend it can support the
proposed addition. We can add new modules easily without affecting the Core Program. Most
of parts are running in the server using the concept of stored procedures.
Financial Feasibility:
This system could be done with the current equipments and existing software technology.
The cost for creating the system too is moderate and worthy.
The hardware and software resources are easily available and so the project is
financially feasible. No special investment is needed to manage the tool.
No specific training is required for users to use the tool.
The software used in this project is freeware so the cost of developing the tool is
minimal.
Resource feasibility:
Our proposed project also have resource feasibility when it can be built, whether it interferes
with normal business operations, type and amount of resources required, dependencies, etc.
Contingency and mitigation plans can also be stated.
Operational Feasibility:
This proposed system can easily implemented, as this is based on JSP coding (JAVA) &
HTML. The database created is with MySql server which is more secure and easy to handle.
The resources that are required to implement/install these are available. The personal of the
organization already has enough exposure to computers. So the project is operationally
feasible.
Technical Feasibility matrix
Is the proposed technology or solution practical? Yes
Do we currently possess the necessary technology? Yes
Do we possess the necessary technical expertise? Yes
The technology for any defined solution is usually available. Yes
15. Economical Feasibility:
Economic analysis is the most frequently used method for evaluating the effectiveness of a
new system. More commonly known cost/benefit analysis, the procedure is to determine the
benefits and savings that are expected from a candidate system and compare them with costs.
If benefits outweigh costs, then the decision is made to design and implement the system. An
entrepreneur must accurately weigh the cost versus benefits before taking an action. This
system is more economically feasible which assess the brain capacity with quick & online
test. So it is economically a good project.
17. 2. SYSTEM ANALYSIS
The goal of systems analysis is to find out where the problem is in attempt to fix the
system. This step involves breaking down the system in different pieces and drawing
diagrams to analyze the situation. Analyses project goals, breaking down functions that need
to be created, and attempts to engage users so that definite requirements can be defined.
2.1 SCENARIO BASED MODELLING
Use-oriented techniques are widely used in software requirement analysis and
design. Use cases and usage scenarios facilitate system understanding and provide a common
language for communication. This paper presents a scenario-based modeling technique and
discusses its applications. In this model, scenarios are organized hierarchically and they
capture the system functionality at various abstraction levels including scenario groups,
scenarios, and sub-scenarios. Combining scenarios or sub-scenarios can form complex
scenarios. Data are also separately identified, organized, and attached to scenarios. This
scenario model can be used to cross check with the UML model. It can also direct systematic
scenario-based testing including test case generation, test coverage analysis with respect to
requirements, and functional regression testing.
2.1.1 IDENTIFIED USECASES
A use case diagram in the Unified Modeling Language (UML) is a type of behavioral
diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical
overview of the functionality provided by a system in terms of actors, their goals (represented
as use cases), and any dependencies between those use cases
The main purpose of a use case diagram is to show what system functions are
performed for which actor. Roles of the actors in the system can be depicted.
Interaction among actors is not shown on the use case diagram. If this interaction is
essential to a coherent description of the desired behavior, perhaps the system or use case
boundaries should be re-examined. Alternatively, interaction among actors can be part of the
assumptions used in the use case.
Use case: A use case describes a sequence of actions that provide something of measurable
value to an actor and is drawn as a horizontal ellipse.
18. Actor: An actor is a person, organization, or external system that plays a role in one or more
interactions with the system.
System boundary boxes (optional): A rectangle is drawn around the use cases, called the
system boundary box, to indicate the scope of system [25]. Anything within the box
represents functionality that is in scope and anything outside the box is not.
Four relationships among use cases are used often in practice.
Include: In one form of interaction, a given use case may include another. "Include is a
Directed Relationship between two use cases, implying that the behavior of the included use
case is inserted into the behavior of the including use case.
The first use case often depends on the outcome of the included use case. This is
useful for extracting truly common behaviors from multiple use cases into a single
description. The notation is a dashed arrow from the including to the included use case, with
the label "«include»"... There are no parameters or return values [25]. To specify the location
in a flow of events in which the base use case includes the behavior of another, you simply
write include followed by the name of use case you want to include, as in the following flow
for track order.
Extend: In another form of interaction, a given use case (the extension) may extend another.
This relationship indicates that the behavior of the extension use case may be inserted in the
extended use case under some conditions. The notation is a dashed arrow from the extension
to the extended use case, with the label "«extend»". Modelers use the «extend» relationship to
indicate use cases that are "optional" to the base use case.
Generalization: In the third form of relationship among use cases, a
generalization/specialization relationship exists. A given use case may have common
behaviors, requirements, constraints, and assumptions with a more general use case [25]. In
this case, describe them once, and deal with it in the same way, describing any differences in
the specialized cases. The notation is a solid line ending in a hollow triangle drawn from the
specialized to the more general use case (following the standard generalization notation).
19. Associations: Associations between actors and use cases are indicated in use case diagrams
by solid lines. An association exists whenever an actor is involved with an interaction
described by a use case. Associations are modeled as lines connecting use cases and actors to
one another, with an optional arrowhead on one end of the line [25]. The arrowhead is often
used to indicating the direction of the initial invocation of the relationship or to indicate the
primary actor within the use case.
Use case diagram:
user
generat e OTP
request OTP
login
FIG 2.1: Use Case Diagram
2.1.2 ACTIVITY DIAGRAM
Activity diagrams are graphical representations of workflows of stepwise activities
and actions with support for choice, iteration and concurrency. In the Unified Modeling
Language, activity diagrams can be used to describe the business and operational step-by-step
workflows of components in a system [25]. An activity diagram shows the overall flow of
control. Activity diagrams are constructed from a limited repertoire of shapes, connected with
arrows. The most important shape types:
• rounded rectangles represent activities;
• diamonds represent decisions;
• bars represent the start (split) or end (join) of concurrent activities;
20. • a black circle represents the start (initial state) of the workflow;
• an encircled black circle represents the end (final state)
Arrows run from the start towards the end and represent the order in which activities
happen [25]. However, the join and split symbols in activity diagrams only resolve this for
simple cases; the meaning of the model is not clear when they are arbitrarily combined with
decisions or loops.
Activity Diagram:
user mobile system database
open application in mobile provide options
enter PIN number generate OTPand display to user
view the result
enter username and PIN number
send sms to server generates OTPand send to mobile
display msg to user
login into website receives and send query to database process query and send details
generates OTP ad verifies
display home page
connection less method
SMSbased method
valid user
valid details
enter correct details
invalid user
invalid details
21. 2.2 FLOW-ORIENTED MODELLING
Flow-oriented Modeling continues to be one of the most widely used analysis
notations today. In this modeling, we begin with drawing the data flow diagrams and control
flow diagrams. Data flow diagrams show us how the data flows from one process to another.
Control flow diagrams shows how the control goes from one process to another.
2.2.1 OVERALL DATAFLOW DIAGRAMS
A data flow diagram is graphical tool used to describe and analyze movement of data
through a system. These are the central tool and the basis from which the other components
are developed. A full description of a system actually consists of a set of data flow diagrams.
Each component in a DFD is labeled with a descriptive name. The top-level diagram is often
called context diagram.
FIG 2.3: Overall Data Flow Diagram
2.2.2 CONTROL FLOW
The control flow of a system defines the flow of execution at different states. It can be
graphically represented using a control flow diagram (flow chart). For this system the order
User
Generate
OTP
Displays
OPT to user
Enter
username, PIN
in mobile
Server
independentl
y generate
OTP again
Server
compare
s both
OTPs
If both OTPs are
same, server
allows the user
to access the
service
Enter username,
OTP
Server
generates
OTP
Request the
server to
generate OTP
through SMS
Send OTP to
user through
SMS
22. of execution that the system performs is different for administration, attendance entry and for
report generation.
FIG 2.4: Control Flow Diagram
Stop
Select
s an
option
Start
Enter username, OTP for login
User generates OTP by giving username, PIN
Server requests
to reenter
Gets the values
from database
Server generates OTP
Server
checks
userna
me
Compare
OTPs
Login into
account
Client sends SMS with necessary details
Server verify all details
Checks
details
in
databas
e
Send incorrect
details message
Send OTP
password
Do login using
OTP password
23. 2.3 BEHAVIOURIAL MODELLING
The behavioral model indicates how the software will respond to external events or
stimuli.
2.3.1. STATE CHART DIAGRAM
The name of the diagram itself clarifies the purpose of the diagram and other details. It
describes different states of a component in a system [25]. The states are specific to a
component/object of a system.
A Statechart diagram describes a state machine. Now to clarify it state machine can be
defined as a machine which defines different states of an object and these states are
controlled by external or internal events.
Purpose:
Statechart diagram is one of the five UML diagrams used to model dynamic nature of a
system. They define different states of an object during its lifetime. And these states are
changed by events.. Statechart diagram describes the flow of control from one state to another
state. States are defined as a condition in which an object exists and it changes when some
event is triggered. So the most important purpose of Statechart diagram is to model life time
of an object from creation to termination. Statechart diagrams are also used for forward and
reverse engineering of a system. But the main purpose is to model reactive system.
How to draw Statechart Diagram?
Statechart diagram is used to describe the states of different objects in its life cycle. So the
emphasis is given on the state changes upon some internal or external events. These states of
objects are important to analyze and implement them accurately.
Statechart diagrams are very important for describing the states. States can be identified as
the condition of objects when a particular event occurs.
Before drawing a Statechart diagram we must have clarified the following points:
• Identify important objects to be analyzed.
• Identify the states.
• Identify the events.
24. 2.3.2 SEQUENCE DIAGRAM:
• A sequence diagram in Unified Modeling Language (UML) is a kind of interaction
diagram that shows how processes operate with one another and in what order.
• Sequence diagrams are sometimes called event diagrams, event scenarios, and timing
diagrams. A sequence diagram shows, as parallel vertical lines (lifelines), different
processes or objects that live simultaneously, and, as horizontal arrows, the messages
exchanged between them, in the order in which they occur. This allows the
specification of simple runtime scenarios in a graphical manner.
• If the lifeline is that of an object, it demonstrates a role. Note that leaving the instance
name blank can represent anonymous and unnamed instances. In order to display
interaction, messages are used [25]. These are horizontal arrows with the message
name written above them. Solid arrows with full heads are synchronous calls, solid
arrows with stick heads are asynchronous calls and dashed arrows with stick heads are
return messages. This definition is true as of UML 2, considerably different from
UML 1.x.
• Activation boxes, or method-call boxes, are opaque rectangles drawn on top of
lifelines to represent that processes are being performed in response to the message
(Execution Specifications in UML).
• Objects calling methods on themselves use messages and add new activation boxes on
top of any others to indicate a further level of processing. When an object is destroyed
(removed from memory), an X is drawn on top of the lifeline, and the dashed line
ceases to be drawn below it (this is not the case in the first example though). It should
be the result of a message, either from the object itself, or another.
25. Sequence Diagrams:
Connectionless method:
/ user / m obile / server / dat abase
1 : enter username and PIN()
2 : generates OTP()
3 : displays OTP()
4 : enter username and OTPpassword()
5 : checks username with the database()
6 : sends the user details()
7 : generates OTPand compares with entered password()
8 : displays the result()
FIG 2.5: Sequence diagram for connection less method
SMS based method:
/ user / mobile / GSM modem / server / dat abase
1 : enter username, PIN through sms()
2 : sends SMS()
3 : gets the details() 4 : compares the factors with the database()
5 : if valid, generates OTP()
6 : encrypts OTPand sends to mobile()
7 : displays OTP()
8 : enter username Password()
9 : compares the details()
10 : displays the result()
FIG 2.6: sequence diagram for SMS based method
26. 2.4 CLASS BASED MODELING
Class-based Modeling, or more commonly class-orientation, refers to the style of
object-oriented programming in which inheritance is achieved by defining classes of objects;
as opposed to the objects themselves (compare Prototype-based programming).
The most popular and developed model of OOP is a class-based model, as opposed to an
object-based model. In this model, objects are entities that combine state (i.e., data), behavior
(i.e., procedures, or methods) and identity (unique existence among all other objects). The
structure and behavior of an object are defined by a class, which is a definition, or blueprint,
of all objects of a specific type. An object must be explicitly created based on a class and an
object thus created is considered to be an instance of that class. An object is similar to a
structure, with the addition of method pointers, member access control, and an implicit data
member which locates instances of the class (i.e. actual objects of that class) in the class
hierarchy .
2.4.2 CRC MODELS
CRC modeling is an effective, low-tech method for developers and users to work
closely together to identify and understand business requirements. A CRC model is a
collection of CRC cards that represent whole or part of an application or problem domain.
The most common use for CRC model is to gather and define the user requirements for an
object-oriented application. The bellow figure presents an example CRC card. A CRC card
(class, responsibility, collaboration card) is a standard index card that has been divided into
three sections.
Class name
Responsibilities
Collaborators
Fig 2.7: CRC card layout
Class Name
Responsibilities Collaborators
27. A class represents a collection of similar objects. An object is a person, place,
thing, event, concept, screen, or report that is relevant to the system at hand. The name of
the class appears across the top of the card.
A responsibility is anything that a class knows or does. The things that a class
knows and do constitute its responsibilities. Responsibilities are shown on the left hand
column of a CRC card.
Sometimes a class will have a responsibility to fulfill, but will not have enough
information to do it. When this happens it has to collaborate with other classes to get the
job done. The collaborators of a class are shown in the right-hand column of a CRC card.
2.4.3. COLLABORATION DIAGRAM
A Sequence diagram is dynamic, and, more importantly, is time ordered. A
Collaboration diagram is very similar to a Sequence diagram in the purpose it achieves; in
other words, it shows the dynamic interaction of the objects in a system.
A distinguishing feature of a Collaboration diagram is that it shows the objects and
their association with other objects in the system apart from how they interact with each
other. The association between objects is not represented in a Sequence diagram.
A Collaboration diagram is easily represented by modeling objects in a system and
representing the associations between the objects as links [25]. The interaction between the
objects is denoted by arrows. To identify the sequence of invocation of these objects, a
number is placed next to each of these arrows.
Defining a Collaboration diagram:
A sophisticated modeling tool can easily convert a collaboration diagram into a sequence
diagram and the vice versa. Hence, the elements of a Collaboration diagram are essentially
the same as that of a Sequence diagram.
30. 3. SYSTEM DESIGN
3.1 COMPONENT LEVEL DATA/CLASS DESIGN
Data Design at the component level:
• Refine data objects and develop a set of data abstractions
• Implements data object attributes as one or more data structures
• Review data structures to ensure that appropriate relationships have been established
• Simplify data structures as required
3.2 ARCHITECTURAL DESIGN
3.2.1 PROCEDURAL STEPS
1. The systematic analysis principles applied to function and behavior should also be applied
to data.
2. All data structures and the operations to be performed on each should be identified.
3. A data dictionary should be established and used to define both data and program design.
4. Low level data design decisions should be deferred until late in the design process.
5. The representation of data structure should be known only to those modules that must
make direct use of the data contained within the structure.
6. A library of useful data structures and the operations that may be applied to them should
be developed.
7. A software design and programming language should support the specification and
realization of abstract data types.
31. 3.2.2 ARCHITECTURAL DESIGN DIAGRAMS
i) CONTEXT LEVEL ARCHITECTURE:
The Architectural Context diagram for the software is shown below. As it is clear from the
diagram, various actors are admin, staff and student, which use the system. The subordinate
systems that will be used by the software are the database (ORACLE) and Java. Also JDBC
thin driver is required to connect java to database. Maintenance system is super ordinate,
which needs the software for testing and maintenance purposes.
FIG 3.1: context level architecture of the system
Maintenance and
self test
User
J2ME Database
(Oracle)
Two factor authentication
using mobile phones
32. Database Design:
A database is needed on the server side to store the client’s identification information
such as the first name, last name, username, pin, password, mobile IMEI number, IMSI
number, unique symmetric key, and the mobile telephone number for each user. The
password field will store the hash of the 10 minute password. It will not store the password
itself. Should the database be compromised the hashes cannot be reversed in order to get the
passwords used to generate those hashes. Hence, the OTP algorithm will not be traced.
Users table:
Field Name Data Type
First Name Varchar2
Last Name Varchar2
Username Varchar2
PIN Number
Password Varchar2
IMEI Varchar2
IMSI Varchar2
Unique key Varchar2
Mobile Number Number
Backup Number Number
Ozekimessagein table:
Field Name Data Type
Id Number
Sender Varchar2
Receiver Varchar2
Msg Varchar2
Operator Varchar2
Msgtype Varchar2
Senttime Varchar2
Receivedtime Varchar2
Reference Varchar2
33. Ozekimessageout table:
Field Name Data Type
Id Number
Sender Varchar2
Receiver Varchar2
Msg Varchar2
Operator Varchar2
Msgtype Varchar2
Senttime Varchar2
Receivedtime Varchar2
Reference Varchar2
Status Varchar2
49. Sha256 genpwd=new Sha256();
//genpwd.update(realpin.getBytes());
int pwd=genpwd.generateHash(realpin);
message="Your Password is"+pwd+"n Note : The password will expire in 10min";
}
}
else
message="Username or Password is Incorrect";
System.out.println("message="+message);
sendSMS();
}
public void sendSMS()throws Exception
{
Statement sndsms=msgsrvrconn.createStatement();
System.out.println("insert into ozekimessageout(receiver,msg)
values('"+sender+"','"+message+"')");
ResultSet rs=sndsms.executeQuery("insert into ozekimessageout(receiver,msg)
values('9346223553','"+message+"')");
System.out.println("Message Sent Successfully"+message);
}
public void markMsgAsRead(String id)throws Exception
{
Statement updatedb=msgsrvrconn.createStatement();
System.out.println("update users set status='read' where id="+Integer.parseInt(id)
+"");
ResultSet rs=updatedb.executeQuery("update ozekimessagein set status='read' where
id="+Integer.parseInt(id));
}
}
51. 5. SYSTEM TESTING
Testing is the process of detection errors. Testing performs a very quality role for
assurance and for ensuring the ability of software. The results of testing are used latter on
during maintenance also.
5.1 TESTING OBJECTIVES
The main objective of testing is to uncover a host error, systematically and the
minimum effort and time starting formally, we can say
1. Test is the process executing a program with the intent of finding an error.
2. A successful test is one that uncovers as ad yet undiscovered error.
3. A good test case is one that has a high probability of finding errors, if it exits.
5.1.1 WHITE BOX TESTING
• This is unit testing method where is unit will be taken at a time and tested thoroughly
at a statement level to find the maximum level errors.
• We have tested step wise every piece of code, taking care that every statement in the
code
• Is executed at least once.
• The white box testing is also called glass box testing.
5.1.2 BLACK BOX TESTING
This testing method a models a single unit and checks the unit at interface and
communication with other models rather getting g into details levels[24]. Here the model will
be treated as a black box that take input and generates the output. Output of given input
combinations are forwarded to other models.
52. 5.1.3 UNIT TESTING
Unit testing focuses verification effort on the smallest unit of software that is the
model using the detailed design and the processes specifications testing is done to uncover
errors within the boundary of the model all model must be successful in the unit test before
the start of the integration testing.
In our project s unit testing involves checking each future specified in the component
a component performs only small part of the functionality on the system and relies on
cooperating with other part of the system.
5.1.4 INTEGRATION TESTING
In this project integrating all the modules forms the main system when integrating all
the modules we have checked whether the integration effects working of any of the services
by giving different combinations of inputs with which the services run perfectly before
integration.
5.1.5 FUNCTIONAL TESTING
In this test cases are decided based on specification of the system. The software or the
module to be tested is treated as a black box testing and hence this also called black box
testing.
Testing:
Testing is the process used to help identify the correctness completeness, security and
quality of developed computer software. Testing is a process of technical investigation that is
intended to reveal quality-related information about the product with respect to the context in
which it is intended to operate. This includes, but is not limited to, the process of executing a
program or application with the intent of finding errors.
Software Testing is the process of executing software in a controlled manner; in order
to answer the question “Does this software behave as specified?” Software testing is used in
association with Verification and Validation.
53. Test Cases:
S.No Test case name Test
Step
No
Description Expected Result
1 To check whether new
user is able to register
to website
Step 1 Open the website
registration page
Registration page is
displayed.
Step 2 Enter the
registration details
and click register
button
If fields are accepted then
displays the home page to
user else displays
registration page to enter
correct details.
2 To check whether the
user is able to login
with the connectionless
method OTP
Step 1 Open the mobile
OTP application in
mobile
The application should be
opened with two options.
Step 2 Select the
connection less
method
Displays the screen to
enter PIN number
Step 3 Enter the PIN
number
Generates OTP and
displays to user
Step 4 Open the website Login page is displayed
Step 5 Enter the username
and generated OTP
Server verifies the entered
details and displays the
home page.
3 To check whether the
user is able to login
with the sms based
method OTP
Step 1 Open the mobile
OTP application in
mobile
The application should be
opened with two options.
Step 2 Select the sms based
method
Displays the screen to
enter username and PIN
number
Step 3 Enter uname and
PIN number
Confirmation screen is
displayed for sending sms
to server
54. Step 4 Press ok button Displays the result screen
Step 5 Check the incoming
sms from server
Displays OTP
Step 6 Open the website
login page and enter
uname and
password
Server verifies the entered
details and displays the
home page.
4 To check whether the
user is not able to login
with invalid
information
Step 1 Open the website Login page is displayed
Step 2 Enter either invalid
username or OTP
Displays the result that
invalid username or
password.
5 To check whether the
logged on user is able
to logout of the
application
Step 1 After login into
account, click
logout button
Login page should be
displayed.
Table 5.1: Test cases
56. 7. DOCUMENTATION
HOW TO OPERATE THE PACKAGE
At the server:
1. Download & Install jdk1.6 (or above) from http://www.oracle.com/java
2. Set the path for java as follows
a. To set path for Java, right click on My Computer.
b. My Computer -> properties -> Advanced -> Environmental Variables -> System
Variables -> new
c. Set ‘variable name’ as ‘Path’ and ‘variable value’ as ‘C:;D:;E:;C: j2sdkbin’;
3. Install tomcat5.0 (or above) web server from http://www.apache.org
4. Download and install oracle express edition 10
5. Create tables in the database
6. Install Netbeans7 IDE and then place the project folder in
My Documents -> Netbeans Projects
7. Add the ojdbc14.jar and comm.jar files to library in Netbeans
8. Connect the GSM Modem to server
9. Install and configure Ozeki message server.
a. Configure GSM modem settings and test the GSM modem
b. Add oracle database plug-in and configure database connection
10. Test the server by running project in Netbeans.
11. Now the home page of the system will be displayed in the browser
57. At the client:
1. Place the jar and jad files of the application into java enabled mobile phone and
install the application.
2. Open the application in the mobile and generate OTP.
8. SCOPE FOR FURTHER DEVELOPMENT
The performance of the system is proved to be efficient. The system provides
flexibility for incorporating new features, which may be necessary in future. The proposed
system can be equally beneficial for any type of online transaction for example online billing,
online reservation, online shopping, online banking etc.
Future developments include a more user friendly GUI and extending the algorithm to work
on Blackberry, Palm, and Windows-based mobile phones. In addition to the use of Bluetooth
and WLAN features on mobile phones for better security and cheaper OTP generation. Thus
the secure processing system is flexible and can be incorporated with new features in the
future.
58. CONCLUSION
Two factor authentication system is a user-friendly package and requires little prior
knowledge of software. The project has two option of running,
• Connection-less method
• SMS based method
Both methods have been successfully implemented and tested, and shown to be
robust and secure. The system has several factors that makes it difficult to hack.
59. APPENDIX
An overview of UML:
The UML is a language for
• Visualizing
• Specifying
• Constructing
• Documenting
These are the artifacts of a software-intensive system. The three major elements of UML are
• The UML’s basic building blocks
• The rules that dictate how those building blocks may be put together.
• Some common mechanisms that apply throughout the UML.
BASIC BUILDING BLOCKS OF THE UML:
The vocabulary of UML encompasses three kinds of building blocks:
Things
Relationships
Diagrams
THINGS IN THE UML:
They are the abstractions that are first-class citizens in a model. There are four kinds of things
in the UML
1. Structural things
2. Behavioral things.
3. Grouping things.
4. Annotational things.
These things are the basic object oriented building blocks of the UML. They are used to write
well-formed models.
60. STRUCTURAL THINGS:
Structural things are the nouns of the UML models. These are mostly static parts of the
model, representing elements that are either conceptual or physical. In all, there are seven
kinds of Structural things.
Class:
A class is a description of a set of objects that share the same attributes, operations,
relationships, and semantics. A class implements one or more interfaces. Graphically a class
is rendered as a rectangle, usually including its name, attributes and operations, as shown
below.
Interface:
An interface is a collection of operations that specify a service of a class or component.
Graphically the interface is rendered as a circle together with its name.
ISpelling
Collaboration:
Collaboration defines an interaction and is a society of roles and other elements that work
together to provide some cooperative behavior that’s bigger than the sum of all the elements.
Graphically, collaboration is rendered as an ellipse with dashed lines, usually including only
its name as shown below.
Chain of
Responsibility
61. Use Case:
Use case is a description of a set of sequence of actions that a system performs that yields an
observable result of value to a particular thing in a model. Graphically, Use Case is rendered
as an ellipse with dashed lines, usually including only its name as shown below.
Active Class:
An active class is a class whose objects own one or more processes or threads and therefore
can initiate control activity. Graphically, an active class is rendered just like a class, but with
heavy lines usually including its name, attributes and operations as shown below.
Component:
Component is a physical and replaceable part of a system that conforms to and provides the
realization of a set of interfaces. Graphically, a component is rendered as a rectangle with
tabs, usually including only its name, as shown below.
orderform.java
Place Order
HRMS
EMPLOYEE
DEATILS
Suspend ()
Flush ()
62. Node:
A Node is a physical element that exists at run time and represents a computational resource,
generally having at least some memory and often, processing capability. Graphically, a node
is rendered as a cube, usually including only its name, as shown below.
server
63. REFERENCES
o Jøsang and G. Sanderud, “Security in Mobile Communications: Challenges and
Opportunities,” in Proc. of the Australasian information security workshop conference on
ACSW frontiers, 43-48, 2003.
o Medrano, “Online Banking Security – Layers of Protection,” Available at
http://ezinearticles.com/?Online-Banking-Security---Layers-of-Protection&id=1353184
o Schneier, “Two-Factor Authentication: Too Little, Too Late,” in Inside Risks 178,
Communications of the ACM, 48(4), April 2005.
o Ilett, “US Bank Gives Two-Factor Authentication to Millions of Customers,” 2005.
http://www.silicon.com/financialservices/0,3800010322,39153981,00.htm.
o de Borde, “Two-Factor Authentication,” Siemens Enterprise Communications UK-
Security Solutions, 2008. Available at http://www.insight.co.uk/files/whitepapers/Twofactor
%20authentication%20(White%20paper).pdf.
• Homework Help
• https://www.homeworkping.com/
• Math homework help
• https://www.homeworkping.com/
• Research Paper help
• https://www.homeworkping.com/
• Algebra Help
• https://www.homeworkping.com/
• Calculus Help
• https://www.homeworkping.com/
• Accounting help
• https://www.homeworkping.com/
• Paper Help
64. • https://www.homeworkping.com/
• Writing Help
• https://www.homeworkping.com/
• Online Tutor
• https://www.homeworkping.com/
• Online Tutoring
• https://www.homeworkping.com/
o
