Homework Help https://www.homeworkping.com/

Research Paper helphttps://www.homeworkping.com/

Online Tutoringhttps://www.homeworkping.com/

CHAPTER 1

INTRODUCTION

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.

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.

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

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

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.

• 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

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

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

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.

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.

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

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.

CHAPTER 2SYSTEM ANALYSIS

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 USECASESA 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.

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).

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;

• 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 applicat ion in mobile provide options

enter PIN number generate OTP and display to user

view the result

enter username and PIN number

send sms to server generates OTP and 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

connect ion less method

SMS based method

valid user

valid details

enter correct details

invalid user

invalid details

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 independently generate OTP again

Server compares 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

of execution that the system performs is different for administration, attendance entry and for

report generation.

FIG 2.4: Control Flow Diagram

Stop

Selects 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 username

Compare OTPs

Login into account

Client sends SMS with necessary details

Server verify all details

Checks details in database

Send incorrect details message

Send OTP password

Do login using OTP password

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.

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.

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 OTP password()5 : checks username with the database()

6 : sends the user details()

7 : generates OTP and compares with entered password()

8 : displays the result()

FIG 2.5: Sequence diagram for connection less method

SMS based method:

/ user / m obile / GSM m odem / 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 OTP and 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

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 MODELSCRC 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

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.

Collaboration diagrams:

Connectionless method:

FIG 2.8: collaboration diagram for connection less method

SMS based method:

FIG 2.9: collaboration diagram for SMS based method

CHAPTER 3

SYSTEM DESIGN

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.

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

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 TypeFirst Name Varchar2Last Name Varchar2Username Varchar2PIN NumberPassword Varchar2IMEI Varchar2IMSI Varchar2Unique key Varchar2Mobile Number NumberBackup Number Number

Ozekimessagein table:

Field Name Data TypeId NumberSender Varchar2Receiver Varchar2Msg Varchar2Operator Varchar2Msgtype Varchar2Senttime Varchar2Receivedtime Varchar2Reference Varchar2

Ozekimessageout table:

Field Name Data TypeId NumberSender Varchar2Receiver Varchar2Msg Varchar2Operator Varchar2Msgtype Varchar2Senttime Varchar2Receivedtime Varchar2Reference Varchar2Status Varchar2

CHAPTER 4

SYSTEM IMPLEMENTATION

4. SYSTEM IMPLEMENTATION

Client Side:

Midlet.java

package usage;

import algorithms.*;import javax.microedition.midlet.*;import javax.microedition.lcdui.*;//import java.io.UnsupportedEncodingException;//import java.security.MessageDigest;//import java.security.NoSuchAlgorithmException;import java.util.*;import javax.wireless.messaging.*;//import java.io.*;import javax.microedition.io.*;

public class Midlet extends MIDlet implements CommandListener{//private Form f1,f2;private Command ok,cancel;private TextField uname,pin;private Display disp;private ChoiceGroup ch;private Form start; public Midlet() { disp=Display.getDisplay(this); ok = new Command("ok", Command.OK, 2); cancel = new Command("Cancel", Command.CANCEL, 2); } public void startApp() { //System.out.print(Integer.toHexString(r[i]&0xff)); start= new Form("OTP GENERATOR"); //f1.append(pin); ch=new ChoiceGroup("Select the way you want to generate password\n",Choice.EXCLUSIVE); ch.append("Generate Password locally", null); ch.append("Request for Password", null); //ch.insert(1,"generate OTP", null);

//ch.insert(2,"request OTP", null); start.append(ch); assigncmds(start); } public void pauseApp() { } public void destroyApp(boolean unconditional) { notifyDestroyed(); } public void commandAction(Command c,Displayable s) { if(s.getTitle().equalsIgnoreCase("OTP GENERATOR")) { if(c.getLabel().equalsIgnoreCase("ok")) { String option=ch.getString(ch.getSelectedIndex()); if(option.equalsIgnoreCase("Generate Password locally")) enterPIN(); else requestOTP(); } else { destroyApp(false); } } else if(s.getTitle().equalsIgnoreCase("genOTP")) { if(c.getLabel().equalsIgnoreCase("ok")) showOTP(); else if(c.getLabel().equalsIgnoreCase("Cancel")) disp.setCurrent(start); } else if(s.getTitle().equalsIgnoreCase("showOTP")) { if(c.getLabel()=="ok") disp.setCurrent(start); } else if(s.getTitle().equalsIgnoreCase("reqOTP")) {

if(c.getLabel()=="ok") sendSMS(); else if(c.getLabel()=="cancel") disp.setCurrent(start); } else if(s.getTitle().equalsIgnoreCase("sendSMS")) { if(c.getLabel().equalsIgnoreCase("ok")) disp.setCurrent(start); } } public void enterPIN() { //disp= Display.getDisplay(this); pin=new TextField("PIN","",30,TextField.ANY); Form genOTP= new Form("genOTP"); genOTP.append(pin); assigncmds(genOTP); } public void requestOTP() { //disp= Display.getDisplay(this); Form reqOTP= new Form("reqOTP"); uname=new TextField("UNAME","",30,TextField.ANY); pin=new TextField("PIN","",30,TextField.NUMERIC); reqOTP.append(uname); reqOTP.append(pin); assigncmds(reqOTP); }

public void showOTP() { //disp= Display.getDisplay(this); Form showOTP= new Form("showOTP"); String p= pin.getString(); Sha256 sha1=new Sha256(); int pwd=sha1.generateHash(p); // String s="guna"; // byte[] b= s.getBytes(); //f2.append(p); //f2.append(String.valueOf(min));

//f2.append(String.valueOf(time.charAt(0))); showOTP.append("Your Password:"); showOTP.append(Integer.toString(pwd)); assigncmds(showOTP); //String model= System.getProperty("microedition.platform"); } public void sendSMS() { //String name=uname.getString(); // String pwd=pin.getString(); AES aes=new AES(); //String en=aes.EncryptString(pin.getString()); String t="Uname:"+uname.getString()+"\nPIN:"+aes.EncryptString(pin.getString()); Form sendSMS=new Form("sendSMS"); try { String addr = "sms://919346223553"; /* MessageConnection conn = (MessageConnection)Connector.open(addr); TextMessage msg = (TextMessage)conn.newMessage(MessageConnection.TEXT_MESSAGE); msg.setAddress(addr); msg.setPayloadText(t); conn.send(msg);*/ } catch (Exception e) { /// mhhhhh sendSMS.append(e.getMessage()); //e.printStackTrace(); } sendSMS.append("Password Request Sent\n\nUser Name : "+uname.getString()+"\nPIN : "+pin.getString()); //disp.setCurrent(sendSMS); assigncmds(sendSMS); } public void assigncmds(Form form) { String frmname=form.getTitle(); form.addCommand(ok); if(!(frmname.equals("showOTP") || frmname.equals("sendSMS"))) form.addCommand(cancel); form.setCommandListener(this); disp.setCurrent(form); } }

Sha256.java:

package algorithms;import java.util.*;

public class Sha256 extends BaseHash { // Constants and variables // ------------------------------------------------------------------------- private static final int[] k = { 0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5, 0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174, 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da, 0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967, 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85, 0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070, 0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3, 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2 }; private static final int BLOCK_SIZE = 64; // inner block size in bytes private String DIGEST0 = "BA7816BF8F01CFEA414140DE5DAE2223B00361A396177A9CB410FF61F20015AD"; private static final int[] w = new int[64]; /** caches the result of the correctness test, once executed. */ private static boolean valid; /** 256-bit interim result. */ private int h0, h1, h2, h3, h4, h5, h6, h7; // Constructor(s)

// ------------------------------------------------------------------------- /** Trivial 0-arguments constructor. */ public Sha256() { super("SHA256_HASH", 32, BLOCK_SIZE); } /**104 * <p>Private constructor for cloning purposes.</p>105 *106 * @param md the instance to clone.107 */ private Sha256(Sha256 md) { this(); this.h0 = md.h0; this.h1 = md.h1; this.h2 = md.h2; this.h3 = md.h3; this.h4 = md.h4; this.h5 = md.h5; this.h6 = md.h6; this.h7 = md.h7; this.count = md.count; this.buffer = (byte[]) md.buffer.clone(); } // Class methods // ------------------------------------------------------------------------- public static int[] G(int hh0, int hh1, int hh2, int hh3, int hh4, int hh5, int hh6, int hh7, byte[] in, int offset) { return sha(hh0, hh1, hh2, hh3, hh4, hh5, hh6, hh7, in, offset); } // Instance methods // ------------------------------------------------------------------------- // java.lang.Cloneable interface implementation ---------------------------- public Object clone() { return new Sha256(this); } // Implementation of concrete methods in BaseHash --------------------------

protected void transform(byte[] in, int offset) { int[] result = sha(h0, h1, h2, h3, h4, h5, h6, h7, in, offset); h0 = result[0]; h1 = result[1]; h2 = result[2]; h3 = result[3]; h4 = result[4]; h5 = result[5]; h6 = result[6]; h7 = result[7]; } protected byte[] padBuffer() { int n = (int) (count % BLOCK_SIZE); int padding = (n < 56) ? (56 - n) : (120 - n); byte[] result = new byte[padding + 8]; // padding is always binary 1 followed by binary 0s result[0] = (byte) 0x80; // save number of bits, casting the long to an array of 8 bytes long bits = count << 3; result[padding++] = (byte) (bits >>> 56); result[padding++] = (byte) (bits >>> 48); result[padding++] = (byte) (bits >>> 40); result[padding++] = (byte) (bits >>> 32); result[padding++] = (byte) (bits >>> 24); result[padding++] = (byte) (bits >>> 16); result[padding++] = (byte) (bits >>> 8); result[padding] = (byte) bits; return result; } protected byte[] getResult() { return new byte[] { (byte) (h0 >>> 24), (byte) (h0 >>> 16), (byte) (h0 >>> 8), (byte) h0, (byte) (h1 >>> 24), (byte) (h1 >>> 16), (byte) (h1 >>> 8), (byte) h1, (byte) (h2 >>> 24), (byte) (h2 >>> 16), (byte) (h2 >>> 8), (byte) h2, (byte) (h3 >>> 24), (byte) (h3 >>> 16), (byte) (h3 >>> 8), (byte) h3, (byte) (h4 >>> 24), (byte) (h4 >>> 16), (byte) (h4 >>> 8), (byte) h4, (byte) (h5 >>> 24), (byte) (h5 >>> 16), (byte) (h5 >>> 8), (byte) h5, (byte) (h6 >>> 24), (byte) (h6 >>> 16), (byte) (h6 >>> 8), (byte) h6, (byte) (h7 >>> 24),

(byte) (h7 >>> 16), (byte) (h7 >>> 8), (byte) h7 }; } protected void resetContext() { // magic SHA-256 initialisation constants h0 = 0x6a09e667; h1 = 0xbb67ae85; h2 = 0x3c6ef372; h3 = 0xa54ff53a; h4 = 0x510e527f; h5 = 0x9b05688c; h6 = 0x1f83d9ab; h7 = 0x5be0cd19; } // SHA specific methods ---------------------------------------------------- private static final synchronized int[] sha(int hh0, int hh1, int hh2, int hh3, int hh4, int hh5, int hh6, int hh7, byte[] in, int offset) { int A = hh0; int B = hh1; int C = hh2; int D = hh3; int E = hh4; int F = hh5; int G = hh6; int H = hh7; int r, T, T2; for (r = 0; r < 16; r++) { w[r] = (in[offset++] << 24 | (in[offset++] & 0xFF) << 16 | (in[offset++] & 0xFF) << 8 | (in[offset++] & 0xFF)); } for (r = 16; r < 64; r++) { T = w[r - 2]; T2 = w[r - 15]; w[r] = ((((T >>> 17) | (T << 15)) ^ ((T >>> 19) | (T << 13)) ^ (T >>> 10)) + w[r - 7] + (((T2 >>> 7) | (T2 << 25)) ^ ((T2 >>> 18) | (T2 << 14)) ^ (T2 >>> 3)) + w[r - 16]);

} for (r = 0; r < 64; r++) { T = (H + (((E >>> 6) | (E << 26)) ^ ((E >>> 11) | (E << 21)) ^ ((E >>> 25) | (E << 7))) + ((E & F) ^ (~E & G)) + k[r] + w[r]); T2 = ((((A >>> 2) | (A << 30)) ^ ((A >>> 13) | (A << 19)) ^ ((A >>> 22) | (A << 10))) + ((A & B) ^ (A & C) ^ (B & C))); H = G; G = F; F = E; E = D + T; D = C; C = B; B = A; A = T + T2; } return new int[] { hh0 + A, hh1 + B, hh2 + C, hh3 + D, hh4 + E, hh5 + F, hh6 + G, hh7 + H }; } public int generateHash(String input) { Date d=new Date(); Calendar c=Calendar.getInstance(); c.setTime(d); int min=c.get(Calendar.MINUTE); int hr=c.get(Calendar.HOUR_OF_DAY); int date=c.get(Calendar.DAY_OF_MONTH); int month=c.get(Calendar.MONTH); int year=c.get(Calendar.YEAR); int time=(int)Math.floor((double)min/10.0); //System.out.println(time+" "+((int)(double)min/10.0)); input+=String.valueOf(time)+hr+date+month+year; update(input.getBytes()); byte []output=digest(); int pwd=0; for(int i=0;i<output.length;i++) { pwd+=(output[i]&0xff); } return pwd; } }

Server Side:

Login.jsp:

<%@page contentType="text/html" pageEncoding="UTF-8"%><!DOCTYPE html><html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>Login Page</title> </head> <body style="background-color:#f8f8f8"> <center> <h1><pre><form action="verify.jsp" method="post"> Login Username:<input type="text" name="name"/> Password:<input type="text" name="pwd"/> </pre><input type="submit" value="Login"/> <input type="reset" value="Reset"/> </form> </body></html>

verify.jsp:

<%@page contentType="text/html" pageEncoding="UTF-8"%><!DOCTYPE html><html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>Home Page</title> <style> body.bckgrnd{ background-image: url(images/bckgrnd.jpg);background-repeat:no-repeat;z-index:3; } </style> </head> <%@ page import="java.sql.*" %> <%@page language="java" import="algorithms.Sha256,algorithms.BaseHash" %> <% String name=request.getParameter("name"); int pwd= Integer.parseInt(request.getParameter("pwd")); RequestDispatcher rd=null; // out.println("name="+name); String p=""; Class.forName("oracle.jdbc.driver.OracleDriver");

Connection conn=DriverManager.getConnection("jdbc:oracle:thin:@//localhost:1521/XE","otp","otp"); Statement st= conn.createStatement(); ResultSet rs= st.executeQuery("select * from users where uname='"+name+"'"); if(rs.next()) {//out.println("query executed"); p= rs.getString("pin"); // out.println("p ="+p);// String imei= rs.getString("imei"); //String ukey= rs.getString("ukey"); } Sha256 sha1= new Sha256(); int otp=sha1.generateHash(p);//out.println("p value="+p); /* for(int i=0;i<b.length;i++) { out.println("b="+b); out.println("<br>"); }*/ /* java.util.Date d=new java.util.Date(); java.util.Calendar cal=java.util.Calendar.getInstance(); cal.setTime(d); int min=cal.get(java.util.Calendar.MINUTE); int time=(int)Math.floor((double)min/10.0); //String time=String.valueOf(min); //out.println(min+" "+time); p+=String.valueOf(time); //out.println(p); byte[] b= p.getBytes(); sha1.update(b); byte[] r=sha1.digest(); //out.println("r value="+r // out.println("<br>"); //String result=""; int r1=0; for(int i=0;i<r.length;i++) { r1+=(r[i]&0xff);*/ //out.println("r["+i+"]="+r1); //out.println("<br>"); //out.println(Integer.toString(r1)); //String otp= Integer.toString(r1); if(pwd==otp)

{%> <body class='bckgrnd'><%@include file='header.jsp'%> <% out.println("<div style='position:absolute;width: 100%;height: 100px;left: 100px;top:250px;font-size: 20px;font-style: italic;font-family: TimesNewRoman;font-weight: bolder;'><h1 style=\"color:white\"> Welcome:"+name+"</h1>"); } else{ out.println("<h3 style=\"position:relative;left:310px;top:510px;color:white;width:480px\">User Name or Password is Incorrect</h3>"); rd=request.getRequestDispatcher("index.jsp"); rd.include(request,response); }

//response.sendRedirect("login.jsp"); %> </html>

ReceiveSMS.java:

package sms;import java.sql.*;import algorithms.*;

public class ReceiveSMS implements Runnable { Connection msgsrvrconn; Connection dbconn; String message; String sender; Statement msgst; ResultSet msgrs; Thread Rthread=null; /* public static void main(String args[]) { try { ReceiveSMS r=new ReceiveSMS(); }catch(Exception e) { System.err.println(e+"Message Receiving Stopped"); } //r.receive(); }*/

public ReceiveSMS()throws Exception { msgsrvrconn=null; dbconn=null; message=null; sender=null; msgst=null; msgrs=null; Class.forName("oracle.jdbc.driver.OracleDriver"); msgsrvrconn=DriverManager.getConnection("jdbc:oracle:thin:@//localhost:1521/XE","sms","sms"); if(msgsrvrconn!=null) { Rthread=new Thread(this); Rthread.start(); } //Rthread=new Thread(this); } public void run() { try{ while(true) { System.out.println("thread woke up"); msgst= msgsrvrconn.createStatement(); msgrs= msgst.executeQuery("select * from ozekimessagein where status is null"); if(msgrs!=null) { readMsg(); msgst.close(); msgrs.close(); System.out.print("thread in sleep"); Thread.sleep(2000); } // run(); } }catch(Exception e) { System.out.println(e); } }

private void readMsg()throws Exception { String msg=null,msgid=null; String uname=null,pin=null; //String test="uname"; //System.out.println("method call"); //msgsrvrconn=DriverManager.getConnection("jdbc:oracle:thin:@//localhost:1521/XE","sms","sms"); while(msgrs.next()) { sender=msgrs.getString("sender"); msg=msgrs.getString("msg"); msgid=msgrs.getString("id"); if(msg!=null) { uname=msg.substring(msg.indexOf("Uname")+6,msg.indexOf("PIN")); pin=msg.substring(msg.indexOf("PIN")+4); System.out.println("uname="+uname+" PIN="+pin); generatePwd(uname,pin); } markMsgAsRead(msgid); System.out.println(msgrs.getString("sender")+" "+msgrs.getString("msg")+"\n "+uname+"end"+pin); } } public void generatePwd(String uname,String pin)throws Exception { dbconn=DriverManager.getConnection("jdbc:oracle:thin:@//localhost:1521/XE","otp","otp"); Statement dbst=dbconn.createStatement(); System.out.println("select * from users where uname='"+uname+"'"); ResultSet dbrs=dbst.executeQuery("select * from users where uname='"+uname+"'"); if(dbrs.next()) { String realpin=dbrs.getString("pin"); AES aes=new AES(); String decryptpin=aes.DecryptString(pin); if(realpin.equals(decryptpin)) {

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)); } }

CHAPTER 5SYSTEM TESTING

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.

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.

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 userStep 4 Open the website Login page is displayedStep 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

numberStep 3 Enter uname and

PIN number

Confirmation screen is

displayed for sending sms

to server

Step 4 Press ok button Displays the result screenStep 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

CHAPTER 6SCREENS

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:\ j2sdk\bin’;

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

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.

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.

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.

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

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

EMPLOYEEDEATILS

Suspend ()Flush ()

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

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

• https://www.homeworkping.com/ • Writing Help • https://www.homeworkping.com/ • Online Tutor • https://www.homeworkping.com/ • Online Tutoring • https://www.homeworkping.com/

o