Design and Implementation of Authentication Scheme By

DESIGN AND IMPLEMENTATION OF AUTHENTICATION SCHEME BY

ENCRYPTED NEGATIVE PASSWORD

A Project

Presented to the

Faculty of

California State Polytechnic University, Pomona

In Partial Fulfillment

Of the Requirements for the Degree

Master of Science

Computer Science

Laxmi Chidri

2019

SIGNATURE PAGE

PROJECT: DESIGN AND IMPLEMENTATION OF AUTHENTICATION SCHEME BY ENCRYPTED NEGATIVE PASSWORD

AUTHOR: Laxmi Chidri

DATE SUBMITTED: Fall 2019

Department of Computer Science

Dr. Gilbert Young ______Project Committee Chair Computer Science

Dr. Yu Sun ______Computer Science

ABSTRACT

Secure password storage is a vital aspect in systems based on password authentication, which is still the most widely used authentication technique, despite its some security flaws.

In this project, we propose a password authentication framework that is designed for secure password storage and could be easily integrated into existing authentication systems.

In our framework, first, the received plain password from a client is hashed through a cryptographic hash function (e.g., SHA-256). Then, the hashed password is converted into a negative password. Finally, the negative password is encrypted into an Encrypted

Negative Password (abbreviated as ENP) using a symmetric-key algorithm (e.g., AES), and multi-iteration encryption could be employed to further improve security.

The cryptographic hash function and symmetric encryption make it difficult to crack passwords from ENPs. Moreover, there are lots of corresponding ENPs for a given plain password, which makes precomputation attacks (e.g., lookup table attack and rainbow table attack) infeasible. The algorithm complexity analyses and comparisons show that the ENP could resist lookup table attack and provide stronger password protection under dictionary attack.

It is worth mentioning that the ENP does not introduce extra elements (e.g., salt); besides this, the ENP could still resist precomputation attacks. Most importantly, the ENP is the first password protection scheme that combines the cryptographic hash function, the negative password and the symmetric-key algorithm, without the need for additional information except the plain password.

iii

TABLE OF CONTENTS

SIGNATURE PAGE ...... ii

ABSTRACT ...... iii

LIST OF TABLES ...... v

LIST OF FIGURES ...... vi

CHAPTER 1 ...... 1

CHAPTER 2 ...... 4

CHAPTER 3 ...... 7

CHAPTER 4 ...... 14

CHAPTER 5 ...... 17

CHAPTER 6 ...... 28

CHAPTER 7 ...... 33

CHAPTER 8 ...... 37

CHAPTER 9 ...... 45

CHAPTER 10 ...... 48

REFERENCES ...... 49

LIST OF TABLES

Table 1. Software Requirements ...... 12

Table 2. Hardware Requirements ...... 12

Table 3. Mode of Operations ...... 18

Table 4. User Operations …..……………………………………………………………21

Table 5. 8 bit lookup table ………………………………………………………………43

LIST OF FIGURES

Figure 1: Block Diagram of ENP ...... 14

Figure 2: Block Diagram for Registration phase ...... 22

Figure 3:Flow diagram for Authentication phase ...... 23

Figure 4: Block diagram for Verification phase ...... 24

Figure 5: Flow diagram for Verification phase ...... 25

Figure 6: Flow diagram for ENP-As -A-Service ...... 25

Figure 7:Flow Diagram of ENP ...... 26

Figure 8: Usage Statistics ...... 27

Figure 9:Use case diagram for ENP ...... 28

Figure 10: Sequence Diagram 1 ...... 29

Figure 11: Sequence Diagram 2 ...... 29

Figure 12:Sequence Diagram 3 ...... 30

Figure 13: Sequence Diagram 4 ...... 30

Figure 14: Class diagram 1 ...... 31

Figure 15: Class diagram 2 ...... 31

Figure 16: Class diagram 3 ...... 32

Figure 17: Class diagram 4 ...... 32

Figure 18: Program Mapping ...... 38

Figure 19: Block diagram of AES Algorithm ...... 41

Figure 20: AddRound Key generation ...... 42

Figure 21: SubByte generation ...... 43

Figure 22:ShiftRows generation ...... 44

Figure 23:MixColumn generation ...... 44

Figure 24:HomePage Screenshot ...... 45

Figure 25:Registration Phase Screenshot ...... 45

Figure 26:Verification Phase Screenshot ...... 46

Figure 27: ENP-As-A-Service Screenshot ...... 46

Figure 28:Usage Statistics of ENP service ...... 47

vii

CHAPTER 1 INTRODUCTION 1.1 Problem Identification

However, passwords may be leaked from weak systems. Vulnerabilities are constantly being discovered, and not all systems could be timely patched to resist attacks, which gives adversaries an opportunity to illegally access weak systems. In fact, some old systems are more vulnerable due to their lack of maintenance. Finally, since passwords are often reused, adversaries may log into high security systems through cracked passwords from systems of low security.

1.2 Proposed System and Advantages

In this project, a password protection scheme called Encrypted Negative Password

(abbreviated as ENP) is proposed, which is based on the Negative Database (abbreviated

as NDB), cryptographic hash function and symmetric encryption, and a password authentication framework based on the ENP is presented. The NDB is a new security technique that is inspired by biological immune systems and has a wide range of applications.

In the ENP, the secret key is the hash value of the password of each user, so it is almost always different and does not need to be specially generated and stored. Consequently, the

ENP enables symmetric encryption to be used for password protection

1.2.1 Advantages

• Stronger security algorithm which provides resistance to various kind of attacks

including dictionary attacks and look-up table attack

• No extra burden on programmers for configuring more parameters

• Simple and convenient to use

1.3 Objectives and Methodology

1.3.1 Objectives

• To implement a computationally light weight efficient password protection scheme

called Encrypted Negative Password (abbreviated as ENP)

• To design and implement the service layers to expose this password protection layer

to various other layers in the server side architecture

• To implement the solution in such a way that it should be easier to integrate this

with existing systems

• To prove that the proposed scheme provides a strong security against various kinds

of attacks.

• To provide an efficient user interface access to the clients to access the portal 2

• To deploy the project over the cloud so that it can be accessed from various

geographical location from any device.

1.3.2 Methodology

The proposed framework includes two phases: the registration phase and authentication phase. When adopting our framework to protect passwords in an authentication data table, the system designer must first select a cryptographic hash function and a symmetric-key algorithm, where the condition that must be satisfied is that the size of the hash value of the selected cryptographic hash function is equal to the key size of the selected symmetric- key algorithm.

CHAPTER 2 LITERATURE REVIEW Below are the Typical Password Protection Schemes

1. Hashed Password

The simplest scheme to store passwords is to directly store plain passwords.

However, this scheme presents a problem that once adversaries obtain the

authentication data table, all passwords are immediately compromised. To safely

store passwords, a common scheme is to hash passwords using a cryptographic

hash function, because it is infeasible to directly recover plain passwords from

hashed passwords. The cryptographic hash function quickly maps data of arbitrary

size to a fixed-size sequence of bits. In the authentication system using the hashed

password scheme, only hashed passwords are stored. However, hashed passwords

cannot resist lookup table attack. Furthermore, rainbow table attack is more

practical for its space-time tradeoff]. Processor resources and storage resources are

becoming richer, which makes the precomputed tables used in the above two

attacks sufficiently large, so that adversaries could obtain a higher success rate of

cracking hashed passwords

2. Salted Password

To resist precomputation attacks, the most common scheme is salted password. In

this scheme, the concatenation of a plain password and a random data (called salt)

is hashed through a cryptographic hash function. The salt is usually generated at

random, which ensures that the hash values of the same plain passwords are almost

always different. However, under dictionary attack, salted passwords are still weak.

Note that compared with salted password, the ENP proposed in this paper

guarantees the diversity of passwords without the need for extra elements (e.g., salt)

3. Key Stretching

To resist dictionary attack, key stretching, which converts weak passwords to

enhanced passwords, was proposed. Key stretching could increase the time cost

required to every password attempt, so that the power of defending against

dictionary attack is increased. In this scheme, multi-iteration encryption is used to

further improve password security under dictionary attack, and compared with key

stretching, the ENP does not introduce extra elements (e.g., salt).

N. Provos and D. Mazi`eres, “A future-adaptive password scheme,” in Proceedings of

the Annual Conference on USENIX Annual Technical Conference. USENIX

Association, 1999, pp. 32–32.

“RFC 7914: The scrypt Password-Based Key Derivation Function,” https://tools.ietf.org/html/rfc7914

A. Biryukov, D. Dinu, and D. Khovratovich, “Argon2: New generation of memory- hard functions for password hashing and other applications,” in Proceedings of 2016

IEEE European Symposium on Security and Privacy, Mar. 2016, pp. 292–302.

The above Key Stretching schemes are used to defend against dictionary attack.

Drawbacks:

Although key stretching schemes provide stronger password protection than salted

password under dictionary attack, they impose an extra burden on programmers for

configuring more parameters.

M. C. Ah Kioon, Z. S. Wang, and S. Deb Das, “Security analysis of MD5 algorithm in

password storage,” in Proceedings of Instruments, Measurement, Electronics and

Information Engineering. Trans Tech Publications, Oct. 2013, pp. 2706–2711.

In the above paper, a scheme based on MD5 was proposed. It is a variant of salted

password, where the salt is two random strings.

Drawbacks:

Although it could resist lookup table attack and make dictionary attack difficult, it

introduces many parameters, which makes it complicated and inconvenient to use

S. Boonkrong and C. Somboonpattanakit, “Dynamic salt generation and placement for secure password storing,” IAENG International Journal of Computer Science,

vol. 43, no. 1, pp. 27–36, 2016.

Here, the dynamic salt generation and placement are used to improve password

security. Essentially, this scheme is also a variant of salted password, where the salt

is a random string that is dependent on the original password

Drawbacks:

It could resist lookup table attack, however it could not defend against dictionary

attack and also introduces an extra element (i.e., salt).

CHAPTER 3 ANALYSIS 3.1 Introduction

The Analysis Phase is where the project lifecycle begins. The Analysis Phase is where you break down the deliverables in the high-level Project Charter into the more detailed business requirements. The Analysis Phase is also the part of the project where you identify the overall direction that the project will take through the creation of the project strategy documents.

3.2 Software Requirement Specification

3.2.1 Introduction

A software requirements specification (SRS) – a requirements specification for a software system – is a complete description of the behavior of a system to be developed.

In addition to a description of the software functions, the SRS also contains non-functional requirements.

3.2.1.1 Purpose

The purpose of this document is to provide Software Requirement Specification for

“Design and Implementation of Authentication scheme by Encrypted Negative Password”.

3.2.1.2 Scope

The software product produced is an application by name “Design and

Implementation of Authentication scheme by Encrypted Negative Password ".

Negative Password (abbreviated as ENP) using a symmetric-key algorithm (e.g., AES), and multi-iteration encryption could be employed to further improve security.

ENP-as-a-Service

This portal enables the owner of the product to share the solution we have proposed to the external applications. The user just have to add a new client by entering the client’s email

ID. The portal will then generate the Client Identifier and the unique PIN and sends it across an email to the client. The client will also get the API details which has to be invoked to consume the web services we are exposing. The client identifier and the client PIN are mandatory to be included in each client request.

Basically, two APIs are been exposed to the external clients

• Registration Service

• Verification Service

These APIs are exposed as a RESTFul web services.

REST stands for Representational State Transfer. REST is web standards based architecture and uses HTTP Protocol. It revolves around resource where every component is a resource and a resource is accessed by a common interface using HTTP standard methods. In REST architecture, a REST Server simply provides access to resources and REST client accesses and modifies the resources. Here each resource is identified by URIs/ global IDs. REST uses various representation to represent a resource like text, JSON, XML. JSON is the most popular one.

A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter- process communication on a single computer. This interoperability (e.g., between Java and Python, or Windows and Linux applications) is due to the use of open standards.

Web services based on REST Architecture are known as RESTful web services. These webservices uses HTTP methods to implement the concept of REST architecture. A

RESTful web service usually defines a URI, Uniform Resource Identifier a service, provides resource representation such as JSON and set of HTTP Methods.

3.2.2 General Description

3.2.2.1 Product Perspective

• Accepting each input from the user and validating them against right expressions

as mentioned in the conditional statements

• Ability for the user to provide the input in various formats.

• Providing the responsive HTML web interface where the users can access the tool

from various devices

• Enabling the user to enter their registration details in a user-friendly manner without

having the backend algorithm parameters been displayed on the web screen

• Ability for the users to execute the registration process at any given time without

any down time

• Ability for the users to execute the authentication process at any given time without

any down time.

3.2.2.2 Product functions

• The core algorithm application will be implemented using pure Java libraries.

• The product will be deployed on a fully functional application server like Apache

Tomcat or WildFly Application Server

• All the modules will be implemented as a dynamic web application.

3.2.2.3 User Characteristics

• In this project, we will need a small amount of configuration work to be done in the

Eclipse box to set up the application

• User also needs to install Apache Tomcat/ WildFly server to host the all the user

portals

• The input provided by the users should be from the web browsers where the users

will be the output again in the web browsers.

• The appropriate portal must be accessed only the appropriate users belonging the

correct role

3.2.2.4 Assumptions and Dependencies

• JDK has to be installed in the machine where all the three subcomponent will be

executing.

• The application servers like either the JBOSS or the Apache Tomcat will have to

be supported by the host machines

• There shall not be any firewall or other engines that prevents the remote requests

from the portal.

• There shouldn’t be any permission related issues on any cluster. The host operating

system should take of permitting all the requests to the cluster from the interface

layer.

3.2.3 Requirements

3.2.3.1 Functional Requirements

• To implement a computationally light weight efficient password protection scheme

called Encrypted Negative Password (abbreviated as ENP)

• To design and implement the service layers to expose this password protection layer

to various other layers in the server side architecture

• To implement the solution in such a way that it should be easier to integrate this

with existing systems

• To prove that the proposed scheme provides a strong security against various kinds

of attacks.

• To provide an efficient user interface access to the clients to access the portal

• To deploy the project over the cloud so that it can be accessed from various

geographical location from any device.

3.2.3.2 Non-Functional Requirements

• Should be easier to access it from the various browsers available.

• Response time of the applications should reflect the real time observations.

• The algorithm should never fail in any of the test cases.

• There shouldn’t be any security concerns on the merged data.

• Each user’s activity should be separated from the other user’s activities

3.2.3.3 Software Requirements

Table 1: Software Requirements Operating System Windows

Programming Language – Core Java, Advanced Java, J2EE, Map Reduce

Backend Framework, MVC Framework

Programming language - Bootstrap Framework, HTML, CSS, JavaScript, Ajax,

Frontend JQuery

Development Eclipse Oxygen IDE

environment

Application Server Apache Tomcat v9.0

Database HDFS

3.2.3.4 Hardware Requirements

Table 2: Hardware Requirements Processor Intel Core i5 or AMD FX 8 core series with clock speed of 2.4

GHz or above

RAM 2GB or above

Hard disk 40 GB or above

Input device Keyboard or mouse or compatible pointing devices

Display XGA (1024*768 pixels) or higher resolution monitor with 32

bit color settings

Miscellaneous USB Interface, Power adapter, etc.

CHAPTER 4 SYSTEM DESIGN

4.1 Introduction

Systems design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. Systems design could see it as the application of systems theory to product development. There is some overlap with the disciplines of systems analysis, systems architecture and systems engineering.

4.2 System Architecture Diagram

The below figure shows a general block diagram describing the activities performed by this project.

The entire architecture has been implemented in nine modules which we will see in high level design and low level design in later chapters.

---, I

HashComponent ~ . ~ ' ' I' I Client ~ I' Generate Layer Verify Negative ■ Negative Password ..... Password Rest I - J J I Web ' Services Cryptograph" ic co mponent @]r I J

I r- Authent1cat1on. • Data Table I J ■

I - I J

Figure 1: Block Diagram of ENP

Registration phase

On the client side, a user enters his/her username and password. Then, the username and plain password are transmitted to the server through a secure channel;

If the received username exists in the authentication data table, “The username already exists!” is returned, which means that the server has rejected the registration request, and the registration phase is terminated; otherwise, go to Step (3);

The received password is hashed using the selected cryptographic hash function;

The hashed password is converted into a negative password using an NDB generation algorithm. The negative password is encrypted to an ENP using the selected symmetric- key algorithm, where the key is the hash value of the plain password. Here, as an additional option, multi-iteration encryption could be used to further enhance passwords;

The username and the resulting ENP are stored in the authentication data table and

“Registration success” is returned, which means that the server has accepted the registration request.

Authentication phase

On the client side, a user enters his/her username and password. Then, the username and plain password are transmitted to the server through a secure channel;

If the received username does not exist in the authentication data table, then “Incorrect username or password!” is returned, which means that the server has rejected the authentication request, and the authentication phase is terminated; otherwise, go to Step

(3), Search the authentication data table for the ENP corresponding to the received username. The ENP is decrypted (one or more times according to the encryption setting in

the registration phase) using the selected symmetric-key algorithm, where the key is the hash value of the plain password; thus, the negative password is obtained;

If the hash value of the received password is not the solution of the negative password then

“Incorrect username or password!” is returned, which means that the server has rejected the authentication request, and the authentication phase is terminated; otherwise,

“Authentication success” is returned, which means that the server has accepted the authentication request.

ENP-as-a-Service

This portal enables the owner of the product to share the solution we have proposed to the external applications. The user just have to add a new client by entering the client’s email

ID. The portal will then generate the Client Identifier and the unique PIN and sends it across an email to the client. The client identifier and the client PIN are mandatory to be included in each client request. Basically, two APIs are being exposed to the external clients

• Registration Service

• Verification Service

Usage Statistics

This portal enables the users of the product to get access to the usage statistics of the clients on the APIs they have shared with them. Fundamentally, each and every clients request access through the RESTFul webservice will be logged into the database. The owner of the product will then be shown with a cumulative report of the numbers of times each APIs have been consumed by each client. This report is useful especially when the owner of the product wants to charge the clients over pay-as-you-go model.

CHAPTER 5 HIGH LEVEL DESIGN 5.1 Introduction

The System design phase involves two sub phases

• High Level Design

• Low Level Design

In the high level design, the proposed functional and non-functional requirements of the software are depicted. Overall solution to the architecture is developed which can handle those needs. This chapter involves the following consideration.

• Design consideration

• Data flow diagram

5.2 Design consideration

There are several design consideration issues that need to be addressed or resolved before getting down designing a complete solution for the system

5.2.1 Assumptions and dependencies

The main assumptions and dependencies identified are as follows:

• JDK has to be installed in the machine where all the three subcomponent will be

executing.

• The application servers like either the JBOSS or the Apache Tomcat will have to

be supported by the host machines

• There shouldn’t be any permission related issues on any cluster. The host operating

system should take of permitting all the requests to the cluster from the interface

layer.

5.2.2 Mode of operation of a System

The system is capable of operating in two different modes

Table 3: Mode of Operations • Registration Phase On the client side, a user enters his/her username and

password. Then, the username and plain password are

transmitted to the server through a secure channel;

If the received username exists in the authentication data

table, “The username already exists!” is returned, which

means that the server has rejected the registration request,

and the registration phase is terminated; otherwise, go to

Step (3);

The received password is hashed using the selected

cryptographic hash function;

The hashed password is converted into a negative

password using an NDB generation algorithm

The negative password is encrypted to an ENP using the

selected symmetric-key algorithm, where the key is the

hash value of the plain password. Here, as an additional

option, multi-iteration encryption could be used to further

enhance passwords;

The username and the resulting ENP are stored in the

authentication data table and “Registration success” is

returned, which means that the server has accepted the

registration request

• Authentication On the client side, a user enters his/her username and

Phase password. Then, the username and plain password are

transmitted to the server through a secure channel;

If the received username does not exist in the

authentication data table, then “Incorrect username or

password!” is returned, which means that the server has

rejected the authentication request, and the authentication

phase is terminated; otherwise, go to Step (3);

Search the authentication data table for the ENP

corresponding to the received username;

The ENP is decrypted (one or more times according to the

encryption setting in the registration phase) using the

selected symmetric-key algorithm, where the key is the

hash value of the plain password; thus, the negative

password is obtained;

If the hash value of the received password is not the

solution of the negative password then “Incorrect

username or password!” is returned, which means that the

server has rejected the authentication request, and the

authentication phase is terminated; otherwise,

“Authentication success” is returned, which means that

the server has accepted the authentication reques

• ENP – as – service This portal enables the owner of the product to share the

solution we have proposed to the external applications.

The user just have to add a new client by entering the

client’s email ID. The portal will then generate the Client

Identifier and the unique PIN and sends it across an email

to the client. The client will also get the API details which

has to be invoked to consume the web services we are

exposing. The client identifier and the client PIN are

mandatory to be included in each client request.

Basically, two APIs are been exposed to the external

clients

• Registration Service

• Verification Service

These APIs are exposed as a RESTFul web services.

REST stands for Representational State Transfer.

REST is web standards based architecture and uses

HTTP Protocol. It revolves around resource where every

component is a resource and a resource is accessed by a

common interface using HTTP standard methods. REST

was first introduced by Roy Fielding in 2000.In REST

architecture, a REST Server simply provides access to

resources and REST client accesses and modifies the

resources. Here each resource is identified by URIs/

global IDs. REST uses various representation to

represent a resource like text, JSON, XML. JSON is the

most popular one.

• Usage Statistics This portal enables the users of the product to get

access to the usage statistics of the clients on the APIs they

have shared with them. Fundamentally, each and every

client request access through the RESTFul webservice

will be logged into the database. The owner of the product

will then be shown with a cumulative report of the

numbers of times each APIs have been consumed by each

client. This report is useful especially when the owner of

the product wants to charge the clients over pay-as-you-

go model.,

5.2.3 User operations

Table 4: User Operations Registration Phase Here the users can create a new account

by providing their email ID and password

Authentication Phase Here the users can verify if the entered

credentials is valid or not

ENP – as – service Here, the users can share the Registration

and Verification APIs with their clients

Usage Statistics Here the users can access the usage

statistics on the APIs from their clients

User Operations

5.3 Data flow diagram

Module: Registration Phase

web.xm l regis t ra t ion.jsp

RegisterServ let.java

AESjava

Figure 2: Block Diagram for Registration phase

The registration phase is divided into six steps

1. On the client side, a user enters his/her username and password. Then, the username

and plain password are transmitted to the server through a secure channel;

2. If the received username exists in the authentication data table, “The username

already exists!” is returned, which means that the server has rejected the registration

request, and the registration phase is terminated; otherwise, go to Step (3);

3. The received password is hashed using the selected cryptographic hash function;

4. The hashed password is converted into a negative password using an NDB

generation algorithm

5. The negative password is encrypted to an ENP using the selected symmetric-key

algorithm, where the key is the hash value of the plain password. Here, as an

additional option, multi-iteration encryption could be used to further enhance

passwords;

6. The username and the resulting ENP are stored in the authentication data table and

“Registration success” is returned, which means that the server has accepted the

registration request

password

Hash

hashed password

Generate Negative Password

negative password (data) and hashed password (key)

Encrypt

Auth entication Data Table

Figure 3:Flow diagram for Authentication phase

Module: Verification Phase

D web.xml 0 VerificationServletjava 71 0 0 OataTableJava AES.java ENPJava

Figure 4: Block diagram for Verification phase

The authentication phase is divided into five steps.

1. On the client side, a user enters his/her username and password. Then, the username

and plain password are transmitted to the server through a secure channel;

2. If the received username does not exist in the authentication data table, then

“Incorrect username or password!” is returned, which means that the server has

rejected the authentication request, and the authentication phase is terminated;

otherwise, go to Step (3);

3. Search the authentication data table for the ENP corresponding to the received

username;

4. The ENP is decrypted (one or more times according to the encryption setting in the

registration phase) using the selected symmetric-key algorithm, where the key is

the hash value of the plain password; thus, the negative password is obtained;

5. If the hash value of the received password is not the solution of the negative

password then “Incorrect username or password!” is returned, which means that the 24

server has rejected the authentication request, and the authentication phase is

terminated; otherwise, “Authentication success” is returned, which means that the

server has accepted the authentication request

plain password

Amhenrication Data Tab le Hash

ENP (data) hashed password (key)

Decrypt

nogativ• password and hasb,d password L is solution? ~

Figure 5: Flow diagram for Verification phase

Module: ENP-As-A-Service

Read CLI ENT ID Read PIN Read EMAIL I O Read PASSW ORD

i YES

Genera te Neg ative Data base and store 1t mto Aut hen ticatio n Da ta Table

Log di ent req uest

Figure 6: Flow diagram for ENP-As -A-Service

This portal enables the owner of the product to share the solution we have proposed to the external applications. The user just has to add a new client by entering the client’s email

~ NO Redd CLIENT ID Read PIN ---•1 Read EMAIL ID ~ Rea d PASSWORD 1YES IN VALID USER

VAIID U S ER

~ YES l Rea d NDB from Auth ent ica ti on D a ta Ta bl e l og d ten t Req uest

Co nstru ct Pas sw or d H as h

Figure 7:Flow Diagram of ENP

Basically, two APIs are been exposed to the external clients

• Registration Service

• Verification Service

PIN REGISTER DONE

EMAIL ID USER ENTRY EXISTS

PASSWORD

CLIENT ID

PIN VALID USER

EMAIL ID INVALID USER

Module: Usage Statistics

D UsageDAOjava D UsageDAOJmpljava

usage.jsp D Usage.java

MySQLUtilityjava

Figure 8: Usage Statistics

CHAPTER 6 LOW LEVEL DESIGN 6.1 Introduction

During the detailed phase, the view of the application developed during the high level design is broken down into modules and programs. Logic design is done for every program and then documented as program specifications. For every program, a unit test plan is created.

6.2 Use case diagram

ENP

AuthenticationData Tablt

Figure 9:Use case diagram for ENP

The external objects that interact directly with the system are called actors. Actors include humans, external devices and other software systems. The important thing about actors is that they are not under control of the application. In this project, user of the system is the actor. To find use cases, for each actor, list the fundamentally different ways in which the actor uses the system. Each of these ways is a use case. 28

6.3 Sequence diagram

6.3.1 Sequence diagram 1

I permutedBils:String I I rHult_ndb:list I

ll'flerateNega' tivePa~ord' :Jllri'lgTo8i'11rt ~ ~

~ p ereaie~ceOfSyrit,ols

J [perrnutedBit charA!Ji)== 'l' ] I : '

, resut ncll 1 j( •.•.•. - ---,

Figure 10: Sequence Diagram 1

6.3.2 Sequence diagram 2

l hash:Stritvgj -

f [numlmOf,P(ndbliD- l!= i]

················,

-.~,~-. -~.-,,~,~-,,,~,

Figure 11: Sequence Diagram 2

6.3.3 Sequence diagram 3

a ciphecCipher Base64:Base64 CiphecCipher ,tr ToEncrypt:String tmpEncodecEncoder *encrypt

TRY

::J setKey getlnstance inl ge!EncO

null

Figure 12:Sequence Diagram 3

6.3.4 Sequence diagram 4 * ~ cipher.Cipher Base64:Base64 Cipher.Cipher tmpDecoder.Decoder decrypt

TRY

I ::J selKey getlnslance iii gelOecoder 'decode , doFnal I a~Base64.ge1Decod~r().decode(strlo0eqypl)))

nul

Figure 13: Sequence Diagram 4

6.4 Class Diagrams

6.4.1 Class diagram 1

<> 0 ENP com enp core

~ fff'I.) <> J verilyNegativePass w ord(List,Slrng) boolean 0 Datalab le Jm exOISfl'.cha,O,Set) ri com enp core J runt>erOISR'.charO)ri Srfse nal\lemorlJD long• 1L Jg enerateNegaw ePassw ord(Strng ) 1.Jst a entries Map>• new HashMap<>() J getRandom'WihExclJsion(Randorn.ri,ri .List )•ri 0 e oataTable() J n,ertf'erlTlJtabon(charO.Strng,ri ) cha,O • getfroies () Map> J crealeSequ enceOISyrrbots(ri) ·cha,O • setErirles (Map>):vood Jr andooFe rlTlJtabon(Strng) _Strng Jrt.Array ToCllarArray(riO)·c ha,O J charArrayToriArray (charO)_riO J strngTo&nary(Strng) Slrng J sha256(Strng )-5trng J man(Slrn((]) VOid

•, I ,l, <> <> 0 RegisterServtet 0 AES com enp strV lec com enp core 5cfs enal\lers l0r/JD long= 1L a5secr etKey SecretKeySpec ~ RegisterServlet() 5 o key byteO ♦ doGet(t-ttpServletRequest,HtpServletResponse )·vood eCA'fS () ♦ -t (HtpServletRequesLHtpServ letResponse ):void J setKey(Slrng) -vood J encrypl(Stmg ,Stmg ) Stmg J decrypt(Strng ,strng) Stmg

Figure 14: Class diagram 1

6.4.2 Class diagram 2

<> 0 DataTa~ 0 vertricationSer'l1el

SJ s er11Wers!Ol'tD:long • 1l s.f s en11Wers1onll): long - 1L ····-~ 11er1rie s M!r.p> • nevw HHhM!r.po( ) h ert1C1111C11'1Servlet() 4f o1u11T11ble() • doGet(tttpS ervletRe> ♦ ooAlst(tttpS ervletRe>)·voicl'

¥ ""() tf'v erifyNegauvePassword(List-J_n 0 AES til"llnt>erDrSA.:char(]J n Jgener a1eNegalwe Passw ord(Slrn.1J-~t ..Ssecre!Key SecretKeySpee '---- ...... ______,,.,, ______,,, .. ·------· .. ·------.... ------~ J getR&nclon1llfl'&ckl.s lOl"'(~ noom,n ,n ,Us141 eoer>) n ··········! .,Skey b

Figure 15: Class diagram 2 31

6.4.3 Class diagram 3

<> (3 VerifyServlet @ Regis ter SeMet comanp1-IM COffl"'IP$-ltl V senaN'ersot.l.) . long• 1L Y' serilNe,siCll'lllJ IC>n0•1L e'v ertyServlet() ~ Re"'°tMS ervlet(} ♦ doGet(l-ttpSetvle!Re(JJest>ttp,ServletResponle ) VOid ♦ doGet(ttlpServle'.Raq.iast.t-tlpServletResponlt )-vOld ♦ doflosl(lt.p$ervletRl!

< > ,.. COffl4t1PdlO O UsogeOAO con~d.c e w rite(Clert) -vOld • r11T10¥e(Stmg ) VOid • w rt e(Usage )-vOld • gelA.IJsageF«Clerc(SUng )·IJs1 • getAKJenl() us,~ • getAUageBytts (String} Ust • ISVakOerc(Strng.Strng) boolean • getAIJsagefo,Cierc8yHts (Str1"195trnQ) Ust <> (3 aien t

II ~i.:f ---$trng II 1"111,tne5tmQ " "'Simo -'~ • oet<>ert..

Figure 16: Class diagram 3

6.4.4 Class diagram 4

< @ AP IServ1et < • gelCienl_icl()·Strng ♦ ooPost(tttpS ervletRe q.ies1,1-ttpServletRespons e)-vOld • gelAIJs111ge8yHts(Strin9) Ust • se lCienl_icl(Strng) -vOld • gelAIJsageF«aertBy Hts (Strng,Strng) Ust • getHl_type() Strng • setHli_type(Strni!) ·v oo • getErtry_tme():Tmestall1) • se:Ertry_lme(Tme s!a1T1>)·v oo

< O ClientDA0 com enpd.lO <, @ O ienl • YI rte(ClertJ ·vOld

e re010Ye(Strin9)-vOld 11clert _il:l:Strng e gelAIClert( ) Usl 11 name Strng • isVaidCiert(SIJng,Strng) boolean II pn. Stfng

J=aert< J • gelOert _icl()Strng • setClert _ld(Stri'lc;i)·vOld • gecteme() Strng • seCName(Strr,g)-vOld • oecPll() Strin9 • seCFWl(Strng)'vOld

Figure 17: Class diagram 4

CHAPTER 7 IMPLEMENTATION 7.1 Introduction

Implementation is the realization of an application, or execution of a plan, idea, model, design, specification, standard, algorithm, or policy. In other words, an implementation is a realization of a technical specification or algorithm as a program, software component, or other computer system through programming and deployment.

Implementation is one of the most important phases of the Software Development

Life Cycle (SDLC). It encompasses all the processes involved in getting new software or hardware operating properly in its environment, including installation, configuration, running, testing, and making necessary changes. Specifically, it involves coding the system using a particular programming language and transferring the design into an actual working system. This phase of the system is conducted with the idea that whatever is designed should be implemented; keeping in mind that it fulfills user requirements, objective and scope of the system. The implementation phase produces the solution to the user problem.

7.2 Overview of System Implementation

This project is implemented considering the following aspects:

1. Usability Aspect.

2. Technical Aspect.

7.2.1 Usability Aspect

The usability aspect of implementation of the project is realized using two principles: a.) The project is implemented as a Java application

There could be many ways of implementing this project. We have chosen JAVA to come up with the required reader. The reason being many: 33

Firstly, Java provides a wonderful library which simplifies the implementation part

of it. Secondly, JAVA is platform independent, meaning the project can run on literally

any platform which has JVM installed within it.

b.) The user-friendly interface using Java's view architecture

The interface provided by this application is very user friendly and is developed

using Java Swings.

7.2.2 Technical Aspect

The technical aspect of implementation of the project is realized as explained below:

7.2.2.1 Servers

Apache Tomcat to develop the product

Apache Tomcat (or simply Tomcat, formerly also Jakarta Tomcat) is an open

source web server and servlet container developed by the Apache Software Foundation

(ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for

Java code to run.

7.2.2.1 Database

MySQL officially, but also called /maɪ ˈsiːkwəl/ "My Sequel") is (as of 2008) the world's most widely used open source relational database management system (RDBMS)

that runs as a server providing multi-user access to a number of databases. The SQL phrase

stands for Structured Query Language.

7.3 Implementation Support

7.3.1 Installation of Eclipse

The following steps should be followed to install eclipse:

• Installation of JVM: Regardless of the operating system, some Java virtual

machine (JVM) has to be installed. A Java Runtime Environment (JRE), or a

Java Development Kit (JDK) can be installed depending on what is to be done

with Eclipse. If Eclipse is intended for Java development, then a JDK (the JDK

includes--among other useful things--the source code for the standard Java

libraries) has to be installed.

• Download Eclipse from the Eclipse Downloads Page.

• The download will be delivered as a compressed (i.e. a ".zip", or ".tar.gz") file.

Decompress this file into the directory of your choice (e.g. "c:\Program

Files\Eclipse Indigo" on Windows). You can optionally create a shortcut of the

executable file ("eclipse.exe" on Windows, or "eclipse" on Linux).

7.3.2 Installation of Apache Tomcat Server

The following steps should be followed to install Apache Tomcat in Eclipse:

• If Apache Tomcat is not present on the machine, it has to be downloaded and

unzipped.

• Start the Eclipse WTP workbench.

• Open Window -> Preferences -> Server -> Installed Runtimes to create a Tomcat

installed runtime.

• Click on Add to open the New Server Runtime dialog, then select your runtime

under Apache (Apache Tomcat v7.0 in this project).

• Ensure the selected JRE is a full JDK and is of a version that will satisfy Apache

Tomcat (this scenario was written using SUN JDK 1.6.029). If necessary, you can

click on Installed JREs to add JDKs to Eclipse. 35

• Click Finish. Click Next, and fill in your Tomcat installation directory.

7.3.3 Installation of MySQL Database

• Log into the computer as an administrator

• Download the free MySQL Server Community Edition

• Double-click the downloaded file

• Double-click Setup.exe

• Click Next.

• Click Custom > Next

• Click Install

• Click Skip Sign-Up and then Next

• Configure MySQL.

• Click Next

• Check Standard Configuration and then click Next

• Make sure Install as Windows Service and Launch the MySQL Server

Automatically are hacked, then click Next.

• Create a root password. Type in what you want your root password to be and make

sure Enable root access from remote machines is checked. Make sure you choose a

difficult to guess password and 'write it down so you don't forget it. Click Next.

• Click Execute. This will start the MySQL server. After MySQL has done its thing,

click Finish.

CHAPTER 8 PSEUDOCODE 8.1 Introduction

Pseudo code is an informal high-level description of the operating principle of a computer program or other algorithm.

8.2 Pseudo codes

Below shows the pseudo code for this project.

This contains several folders that make up to an entire plugin. Each folder has a specific function that helps in the functioning of the plugin.

~ ENP o ~ Deployment Descriptor. ENP O ,9 JAX-WSWeb Services • ~ Java Resources • '5 src • EBcom. enp.core: O I!) AES.java Implementation of ENP algorithm, AES Algorithm and the Data Table o 0 DataTable.j•v• O 0 ENP.java ., £Bcom .enp.dao o ll/ ClientDAOJava DAO Interfaces for Client and Usage Tables o ll/ UsageDAO.j•v• • EBcom.enp .daoimpl O I!) ClientDAOlmpl.j•v• O I!) UsageDAOlmpl.java DAO Implementations for Client and Usage Tables • 1Bcom. enp.mail O 0 MailThread.jav::•= =:::::::----..s ------, t> (lJ SenderAuthentication.java Utility to trigger emails from our project to the clients o 0 SendMail.j•v• • 81 com.enp.pojo o 0 Client.j•v• o 0 UsageJ•v• POJO classes. for Client and Usage Tables • £Bcom. enp.servlet O 0 APJServlet.java ~ Servlet Layer t> [Z)RegisterServle:t. j:~.":.... I t> I!) RegistrationServlet.java ~------~ t> (lJ VerificationServld.java o 0 VerifyServletJ•v• ., £8 com. enp.util t> IDConstants.ja va Utility layer for obtaining the MySQL connection, defining the project O 0 MySQLUtili1y.java constants, and generating the client identifiers o 0 Util.java

fi=, WebContent I> fi=, assets I> Cc,, META-INF I> Cc,, WEB-INF d UI Interface for adding a new client ~ asaservice.jsp client.png -d Entry po i nt . Just a Welcome screen ~ index .jsp ~ registration .jsp ~ UI Interface f or regi strat i on pha s e ~ usage.jsp UI Interface for retriev i ng the cllent "s u s a g e stati st ic s ---- ~~=~~_verification .jsp ~ UI I nterface for ver i fication phase ]~ ------~

Figure 18: Program Mapping

The files written under the folder named ‘Java Resources’ constitutes the back end logic.

The files written under the folder named ‘Web Content’ constitutes the front end logic. The

mapping from front end request to the backend servlet will be written inside web.xml

8.2.1 Generation Algorithm

Input: A password String ‘str’

Step 1: Compute the Hash code of the input String ‘str’ using

SHA256 Algorithm

hashStr • sha256(str)

Step 2: Convert the ‘hashStr’ into binary format

binaryStr • strToBinary(hashStr)

Step 3: Compute the Random permutation of ‘binaryStr’

permutedBits • randomPermutation(binaryStr)

Step 4:

m • permutedBits.length ndb[] • empty[m] for i • 0 to m with step size of 1

x[] • CREATESYMBOLS(m);

for j • 0 to i with step size of 1

x[j] • permutedBits.charAt(j);

x • invertPermutation(x)

ndb[i] • x

result[][] • empty[m][m]

for i • 0 to m with step size of 1

result[i] • AES.encrypt(ndb[i])

return result

8.2.2 Verification Algorithm

Input: A password String ‘str’ and a negative database ‘ndb’

Step 1: Compute the Hash code of the input String ‘str’ using

SHA256 Algorithm

hashStr • sha256(str)

Step 2: Convert the ‘hashStr’ into binary format

binaryStr • strToBinary(hashStr)

Step 3:

m • binaryStr.length

decryptedNDB • empty[m][m]

k • 0

for i • 0 to m with step size of 1

decryptedNDB[k][i] • AES.decrypt(ndb[i])

k++;

Step 4:

for i • 0 to m with step size of 1

if (NUMBEROFSP(ndb[i])!= i)

return false;

Step 5:

X[] • empty[m] for i • 0 to m with step size of 1

index • INDEXOFSP(ndb[i])

x[index] • ndb[i][index]

for j • i+1 to m with step size of 1

ndb[j][index] = ‘*’

if (hash == x) return true else return false

8.2.3 AES Algorithm

AES has a fixed block size of 128 bits, and a key size of 128, 192, or 256 bits.AES operates on a 4 × 4 column-major order matrix of bytes.

For instance, if there are 16 bytes, , these bytes are represented as this matrix:

b4 bs b12 b1 b5 bg b13 b2 b6 b10 b14 b3 b1 b11 b15 40

The key size used for an AES cipher specifies the number of repetitions of transformation rounds that convert the input, called the plaintext, into the final output, called the cipher text. The number of cycles of repetition are as follows:

• 10 cycles of repetition for 128-bit keys.

• 12 cycles of repetition for 192-bit keys.

• 14 cycles of repetition for 256-bit keys.

28-bil plaintexl

C Roundkey s (128 bits) Pre-round transfonnation Ko . Cipher key ' (128, 192, 01· 256 bits) ' , C: Round I . 0 K1 ·;;; C: ' & R Key size Round 2 . x Kz

RoundN,. . Relationship between (slightly different) ' KR number of rounds(R) and cipher key size

128-bitciphe 11ex1

Figure 19: Block diagram of AES Algorithm

Step 1: KeyExpansions

Round keys are derived from the cipher key using Rijndael's key schedule. AES requires a separate 128-bit round key block for each round plus one more.

Step 2: InitialRound

• AddRoundKey: Each byte of the state is combined with a block of the round key

using bitwise xor.

• Step 3: Rounds

• SubBytes: a non-linear substitution step where each byte is replaced with another

according to a lookup table.

• ShiftRows: a transposition step where the last three rows of the state are shifted

cyclically a certain number of steps.

• MixColumns: a mixing operation which operates on the columns of the state,

combining the four bytes in each column.

• AddRoundKey

Step 4: Final Round (no MixColumns)

.o 8 0 , 1 80.2 8 o.3 bo.o bo.1 bo.2 bo., €ddRoundKjY 8 8 1 ,0 a,. a, - 1, 3 b, .o b, . b,, b.., I- 8 - a,.. a,. 2. 2 2,] • b,,. b,. b. ,2 '2.> ♦ - 8 8 3, 1 ... 3 . 2 3,3 b '1 ,2 3.o --~ b. .o ~ ,., ,-r-, k..o k. ,1 k..2 k.., '- 1---' k, .o k1,1 k,., k,,, / k..• k,,! k..~ ~ ,., k..o ~ -11 ~.,<;.

Figure 20: AddRound Key generation

In the AddRoundKey step, each byte of the state is combined with a byte of the round subkey using the XOR operation (⊕).

The SubBytes step

b o,o bo,1 bo,2 b o,3 I S ubBy tcs I --~--· bi, 0 bi.1

Figure 21: SubByte generation

In the SubBytes step, each byte in the state is replaced with its entry in a fixed 8-bit lookup table, S; bij = S(aij).

Table 5: 8 Bit Lookup Table

I o 1 2 3 4 5 6 7 8 9 a b C d e f -- I- - I- - I- - I- - I- - I- -1- - I -- I --1 - - I - - 1-- I-- I -- I -- I 00 63 7c 77 7b f2 6b 6f cs 30 01 67 2b fe d7 ab 76 10 ca 82 c9 7d fa 59 47 fO ad d4 a2 af 9c a4 72 co 20 b7 fd 93 26 36 3f f7 cc 34 as es fl 71 d8 31 15 30 04 c7 23 c3 18 96 OS 9a 07 12 80 e2 eb 27 b2 75 40 09 83 2c la lb 6e Sa aO 52 3b d6 b3 29 e3 2f 84 so 53 dl 00 ed 20 fc bl Sb 6a cb be 39 4a 4c 58 cf 60 do ef aa fb 43 4d 33 85 45 f9 02 7f so 3c 9f a8 70 51 a3 40 Bf 92 9d 38 fS be b6 da 21 10 ff f3 d2 80 cd Oc 13 ec Sf 97 44 17 c4 a7 7e 3d 64 Sd 19 73 90 60 81 4f de 22 2a 90 88 46 ee b8 14 de Se Ob db ao eO 32 3a Oa 49 06 24 Sc c2 d3 ac 62 91 95 e4 79 bO e7 c8 37 6d 8d dS 4e a9 6c 56 f4 ea 65 7a ae 08 co ba 78 25 2e le a6 b4 c6 e8 dd 74 1f 4b bd 8b 8a do 70 3e bS 66 48 03 f6 Oe 61 35 57 b9 86 cl ld 9e eO el f8 98 11 69 d9 Be 94 9b le 87 e9 ce 55 28 df fO 8c al 89 Od bf e6 42 68 41 99 2d Of bO 54 bb 16

The ShiftRows step

No I cha ng e 8a,o 8<>,11 8a ,2 8a,3 8 0,0 8 0,1 8 0,2 8 o,3 I (shifl:Row1 Shift 8i,o 8i,1 8i,2 8 1 1 8 1 2 8 1 3 8 1 0 ,,3 ' ' ' ' - Shift ~ 8i,o 8i, 1 8i,2 ► 8 2,2 8 2,3 8 2,0 8 2,1 ~ .. .. ~.3 Shift : 8:3 0 8:3,1 8:3,2 8:3,3 8 3 0 8 3 1 8 3 2 ' ,,3 ' ' '

Figure 22:ShiftRows generation

In the ShiftRows step, bytes in each row of the state are shifted cyclically to the left. The number of places each byte is shifted differs for each row.Row {n} is shifted left circular by {n-1} bytes

The MixColumn step

aO, l bO,l ao , ao 3 b o,3 ' a l l ( MixColumn} a l , ' al,3 ~ . 3

a2 . a2 ,l a2 ,3 ► b2 3 '

a3 , a3 3 ,2 ~.3 ' I ® c(x) I

Figure 23:MixColumn generation

In the MixColumns step, each column of the state is multiplied with a fixed polynomial

C(x).

CHAPTER 9 SCREEN SHOTS

9.1 Screenshot 1:

~ ➔ C 0 localhost 8080/ENP/ ~ * ABP I- ( .,J C9 (i

.: Apps p cs 575 Piazza Rh Blackboard , . University Library 0~ Mail - lch1dn@cpp Java Tutorial for Co rdProgram Compute job CPP Health lnsuran ~ Common Git Com p Portfohum ))

Encrypted Negative Password (ENP)

Home

[? RegistrationPhase

c(J VerificationPhase Design and Implementation of Authentication scheme by Encrypted Negative Password

• ENP-AS-A-SERVICE

UsageStatistics 1~ Secure password storage is a vital aspect in systems based on password authentication, which is still the most widely used authentication technique, despite its some security flaws. In this project, we propose a password authentication framework that is designed for secure password storage and could be easily integrated into existing authentication systems. In our framework, first, the received plain password from a client is hashed through a cryptographic hash function (e.g., SHA-256). Then, the hashed password is converted into a negative password. Finally, the negative password is encrypted into an Encrypted Negative Password (abbreviated as ENP) using a symmetric-key algorithm (e.g., AES),and multi iteration encryption could be employed to further improve security. The cryptographic hash function and symmetric encryption make it difficult to crack passwords from ENPs. Moreover, there are lots of corresponding ENPs for a given plain password, which makes precomputation attacks (e.g., lookup table attack and rainbow table attack) infeasible. The algorithm complexity analyses and comparisons show that the ENP could resist lookup table attack and provide stronger password protection under dictionary attack. It is worth mentioning that the ENP does not introduce extra elements {e.g., salt); besides this, the ENP could still resist precomputation attacks. Most importantly, the ENP is the first password protection scheme that combines the cryptographic hash function, the negative password and the symmetric-key algorithm, without the need for additional information except the plain password

Existing Systems

Owing to the development of the Internet, a vast number of on line services have emerged, in which password authentication is the most widely used authentication technique, for it is available at a low cost and easy to deploy. Hence, password security always attracts great interest from academia and industry. Despite great research achievements on password security, passwords are still cracked since usersa£™ careless behaviors. For instance, many users often select weak passwords; they tend to reuse same passwords in different systems; they usually set their passwords using familiar vocabulary for its convenience to remember. In addition, system problems may cause password compromises. It is very difficult to obtain passwords from high security systems. On the one hand, stealing authentication data tables (containing usernames and passwords) in high security systems is difficult. On the other hand, when carrying out an on line guessing attack, there is usually a limit to the number of login attempts. However, passwords may be leaked from weak systems. Vulnerabilities are constantly being discovered, and not all systems could be timely patched to resist attacks, which gives adversaries an opportunity to illegally access weak systems. In fact, some old systems are more vulnerable due to their lack of maintenance. Finally, since passwords are often reused, adversaries may log into high security systems through crackedpasswordsfromsystemsoflowsecurity

Proposed Solution

In this project, a password protection scheme called Encrypted Negative Password (abbreviated as ENP) is proposed, which is based on the Negative Database (abbreviated as NDB), cryptographic hash function and symmetric encryption, and a password authentication framework based on the ENP is presented. The NDB is a new security technique that is inspired by biological immune systems and has a wide range of applications. In the ENP, the secret key is the hash value of the password of each user, so it is almost always different and does not need to be specially generated and stored. Consequently, the ENP enables symmetric encryption to be used for password protection

Advantages

Figure 24:HomePage Screenshot 9.2 Screenshot 2:

Encrypted Negative Password (ENP)

Figure 25:Registration Phase Screenshot

9.3 Screenshot 3:

Encrypted Negative Password (ENP)

Verification

(7 RegistrationPhase

• ENP-AS-A-SERVICE

!5 UsageStatistics

Verify

Figure 26:Verification Phase Screenshot 9.4: Screenshot 4:

Encrypted Negative Password (ENP)

11 Home ENP-AS-A-SERVICE

[J' RegistrationPhase

• ENP-AS-A-SERVICE Messagefrom the Server:

!§ UsageStatistics Deleted the Access to the Client CLIENT-08120656043

Figure 27: ENP-As-A-Service Screenshot

9.5 Screenshot 5:

Negative Password (ENP)

Figure 28:Usage Statistics of ENP service

CHAPTER 10 CONCLUSION AND FUTURE WORK Conclusion

In this project, we proposed a password protection scheme called ENP, and

presented a password authentication framework based on the ENP. In our framework, the entries in the authentication data table are ENPs. In the end, we analyzed and compared the attack complexity of hashed password, salted password, key stretching and the ENP. The results show that the ENP could resist lookup table attack and provide stronger password protection under dictionary attack. It is worth mentioning that the ENP does not need extra elements (e.g., salt) while resisting lookup table attack.

Future work

In the future, other NDB generation algorithms will be studied and introduced to

the ENP to further improve password security. Furthermore, other techniques, such as

multi–factor authentication and challenge–response authentication, will be introduced into

our password authentication framework.

REFERENCES

[1] J. Bonneau, C. Herley, P. C. van Oorschot, and F. Stajano, “Passwords and the evolution of imperfect authentication,” Communications of the ACM, vol. 58, no. 7, pp. 78–87, Jun. 2015. [2] M. A. S. Gokhale and V. S. Waghmare, “The shoulder surfing resistant graphical password authentication technique,” Procedia Computer Science, vol. 79, pp. 490–498, 2016. [3] J. Ma, W. Yang, M. Luo, and N. Li, “A study of probabilistic password models,” in Proceedings of 2014 IEEE Symposium on Security and Privacy, May 2014, pp. 689–704. [4] A. Adams and M. A. Sasse, “Users are not the enemy,” Communications of the ACM, vol. 42, no. 12, pp. 40–46, Dec. 1999. [5] E. H. Spafford, “Opus: Preventing weak password choices,” Computers & Security, vol. 11, no. 3, pp. 273–278, 1992. [6] Y. Li, H. Wang, and K. Sun, “Personal information in passwords and its security implications,” IEEE Transactions on Information Forensics and Security, vol. 12, no. 10, pp. 2320–2333, Oct. 2017. [7] D. Florencio and C. Herley, “A large-scale study of web password habits,” in Proceedings of the 16th International Conference on World Wide Web. ACM, 2007, pp. 657–666. [8] R. Shay, S. Komanduri, A. L. Durity, P. S. Huh, M. L. Mazurek, S. M. Segreti, B. Ur, L. Bauer, N. Christin, and L. F. Cranor, “Designing password policies for strength and usability,” ACM Transactions on Information and System Security, vol. 18, no. 4, pp. 13:1–13:34, May 2016. [9] D. Wang, D. He, H. Cheng, and P. Wang, “fuzzyPSM: A new password strength meter using fuzzy probabilistic context-free grammars,” in Proceedings of 2016 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, Jun. 2016, pp. 595–606. [10] H. M. Sun, Y. H. Chen, and Y. H. Lin, “oPass: A user authentication protocol resistant to password stealing and password reuse attacks,” IEEE Transactions on Information Forensics and Security, vol. 7, no. 2, pp. 651–663, Apr. 2012.

[11] M. Zviran and W. J. Haga, “Password security: An empirical study,” Journal of Management Information Systems, vol. 15, no. 4, pp. 161– 185, 1999. [12] P. Andriotis, T. Tryfonas, and G. Oikonomou, “Complexity metrics and user strength perceptions of the pattern-lock graphical authentication method,” in Proceedings of Human Aspects of Information Security, Privacy, and Trust. Springer International Publishing, 2014, pp. 115– 126. [13] D. P. Jablon, “Strong password-only authenticated key exchange,” SIGCOMM Computer Communication Review, vol. 26, no. 5, pp. 5–26, Oct. 1996. [14] J. Jose, T. T. Tomy, V. Karunakaran, A. K. V, A. Varkey, and N. C. A., “Securing passwords from dictionary attack with character-tree,” in Proceedings of 2016 International Conference on Wireless Communications, Signal Processing and Networking, Mar. 2016, pp. 2301–2307. [15] A. Arora, A. Nandkumar, and R. Telang, “Does information security attack frequency increase with vulnerability disclosure? an empirical analysis,” Information Systems Frontiers, vol. 8, no. 5, pp. 350–362, Dec. 2006. [16] R. Song, “Advanced smart card based password authentication protocol,” Computer Standards & Interfaces, vol. 32, no. 5, pp. 321–325, 2010. [17] M. C. Ah Kioon, Z. S. Wang, and S. Deb Das, “Security analysis of MD5 algorithm in password storage,” in Proceedings of Instruments, Measurement, Electronics and Information Engineering. Trans Tech Publications, Oct. 2013, pp. 2706–2711. [18] P. Oechslin, “Making a faster cryptanalytic time-memory trade-off,” in Proceedings of Advances in Cryptology - CRYPTO 2003. Springer Berlin Heidelberg, 2003, pp. 617– 630. [19] S. Noel, M. Elder, S. Jajodia, P. Kalapa, S. O’Hare, and K. Prole, “Advances in topological vulnerability analysis,” in Proceedings of 2009 Cybersecurity Applications Technology Conference for Homeland Security, Mar. 2009, pp. 124–129.