1

TOKEN-BASED AUTHENTICATION USING JSON WEB TOKEN(JWT)

AKMAR AMIRA BINTI ABDULLAH

Degree of Computer Science (Network Security)

Faculty of Informatics and Computing

Universiti Sultan Zainal Abidin, Terengganu, Malaysia

2020

2

DECLARATION

I hereby declare that this thesis is produced based on my original work with the

aid of obtaining information from the sources. The work is a result of my

investigation. I would also declare that this thesis has been previously or

concurrently submitted for any other degree at Universiti Sultan Zainal Abidin

or other institutions.

Signature:…………………………….

Name: Akmar Amira Binti Abdullah

Date:…………………………………

3

CONFIRMATION

This is to confirm that the research conducted and the writing of this thesis

was under my supervision.

Signature:……………………………

Name : Akmar Amira binti Abdullah

Date:………………………………….

4

DEDICATION

In the name of Allah, the Most Gracious and the Most Merciful, all praise is only

for Him, the King of the whole universe. May His blessing be upon his beloved

Prophet Muhammad S.A.W and all his family. A very great hamdalah I served

to Him for giving me enough health, time, and maturity of mind to prepared this

project and complete this thesis.

I would like to express my deepest appreciation to all who provided me the

possibility to complete this thesis. A special thanks to my supervisor Prof Madya

Dr. Zarina Binti Mohamad for her guidance, ideas, help, criticism, and advice

from the start until the end that is helpful to me to complete this final year project.

Next, I was proud to thank my parents and my family for giving moral support

and encouragement throughout my life whenever I feel like giving up. I also take

this opportunity to give special thanks to all lecturers of the Faculty of

Informatics and Computing and my colleagues for their attention, guidance, and

advice during my final year project. To all panels that involve in the appraisal

session and give useful comments and tips, I express my heartful gratefulness

for their guide.

May Allah S.W.T bless all effort for completing this final year project.

Thank you

5

ABSTRACT

The most critical concerns in the scope of information technology are secure

and dependable. The most common computer authentication method is

password-based mechanisms because it is easy to use and does not have any

additional hardware. However, many users do not realize that they have many

significant drawbacks. Moreover, many users use the passwords for remote

authentication in an untrustworthy environment or use the same password

repeatedly that may lead the adversary to do the attacks such as brute force

attacks. To secure user privacy and study on how token work in compactly

authenticating the user, the new strategy that uses token as a base of

authentication and JSON Web Token as a method will be proposed in this

project. Hence, this strategy may solve security problems such as

eavesdropping and shoulder surfing attacks. In JSON Web Token, the user is

easy and convenient to get token because JSON Web token is compact and

stateless which is the user can receive it through the HTTP header and not

require users to provide another device or platform. This method approach

leads to a win-win situation. After all, the token-based authentication reduces

the risk of stolen authentication factors as the JSON tokens protected and have

information that lies in the token can be verified and trusted because it can be

digitally signed. The method also does not need much more user effort also it's

a quick process. The result that going to be yielded in this project is a secure

authentication approach that comfortable to use.

6

ABSTRAK

Kebimbangan yang paling kritikal dalam skop teknologi maklumat adalah

keselamatan dan boleh dipercayai. Kaedah pengesahan komputer yang paling

biasa adalah mekanisma berasaskan kata laluan kerana ia mudah digunakan

dan tidak mempunyai sebarang perkakasan tambahan. Walau bagaimanapun,

ramai pengguna tidak menyedari bahawa mereka mempunyai banyak

kelemahan yang ketara. Selain itu, ramai pengguna menggunakan kata laluan

untuk pengesahan jauh dalam persekitaran yang tidak boleh dipercayai atau

menggunakan kata laluan yang sama berulang kali yang boleh menyebabkan

musuh melakukan serangan seperti serangan kekerasan. Untuk menjamin

privasi pengguna dan mengkaji bagaimana penggunaan token dalam

mengesahkan pengguna dengan cara yang kompak, strategi baru yang

menggunakan token sebagai asas pengesahan dan JSON Web Token sebagai

kaedah akan dicadangkan dalam projek ini. Oleh itu, strategi ini dapat

menyelesaikan masalah keselamatan seperti mendengar rahsia orang tanpa

kebenaran dan serangan mendapatkan maklumat orang tanpa kebenaran.

Dalam JSON Web Token, pengguna mudah dan senang mendapatkan token

kerana token JSON Web adalah kompak dan tanpa statik yang pengguna dapat

menerimanya melalui header HTTP dan tidak memerlukan pengguna untuk

menyediakan peranti atau platform lain. Pendekatan kaedah ini membawa

kepada keadaan menang-menang kerana pengesahan berasaskan token

mengurangkan risiko faktor pengesahan dicuri kerana token JSON dilindungi

dan mempunyai maklumat yang terletak di token itu boleh disahkan dan

dipercayai kerana ia boleh ditandatangani secara digital. Kaedah ini juga tidak

7

memerlukan lebih banyak usaha pengguna juga merupakan proses yang cepat.

Hasil yang akan dihasilkan dalam projek ini adalah pendekatan pengesahan

selamat yang selesa untuk digunakan.

8

TABLE OF CONTENTS

DECLARATION ............................................................................................................................... 2

CONFIRMATION ............................................................................................................................. 3

DEDICATION ................................................................................................................................... 4

ABSTRACT ...................................................................................................................................... 5

ABSTRAK ........................................................................................................................................ 6

LIST OF FIGURES ........................................................................................................................ 10

LIST OF TABLES .......................................................................................................................... 12

CHAPTER 1 ................................................................................................................................... 13

INTRODUCTION ............................................................................................................................ 13

1.1 BACKGROUND .............................................................................................................................. 13 1.2 PROBLEM STATEMENT ................................................................................................................. 15 1.3 OBJECTIVES ................................................................................................................................... 16 1.4 SCOPES OF WORK ......................................................................................................................... 16 1.5 LIMITATION OF WORKS ................................................................................................................ 17 1.6 THESIS ORGANIZATION................................................................................................................. 17 1.7 SUMMARY .................................................................................................................................... 19

CHAPTER 2 ................................................................................................................................... 20

LITERATURE REVIEW ................................................................................................................. 20

2.1INTRODUCTION ................................................................................................................... 20 2.2 OVERVIEW OF AUTHENTICATION ................................................................................ 20 2.3 TOKEN-BASED AUTHENTICATION ............................................................................... 21 2.4 JSON WEB TOKEN (JWT) ................................................................................................ 22 2.5 RSA ALGORITHM ............................................................................................................... 25 2.6 EXISTING SYSTEM ............................................................................................................ 28 2.7 SUMMARY ............................................................................................................................ 33

CHAPTER 3 ................................................................................................................................... 34

METHODOLOGY ........................................................................................................................... 34

3.0 INTRODUCTION ............................................................................................................................ 34 3.1 LOGICAL MODEL ........................................................................................................................... 34 3.2 FRAMEWORK ................................................................................................................................ 35

9

3.3 USE CASE DIAGRAM ...................................................................................................................... 36 3.4 FLOWCHART ................................................................................................................................. 38

3.4.1 Flowchart of registration and login process. .......................................................... 38 3.4.2Flowchart of token validation ....................................................................................... 40 3.4.3 Flowchart of the RSA algorithm .................................................................................. 41

CHAPTER 4 ................................................................................................................................... 45

SYSTEM IMPLEMENTATIONS ................................................................................................... 45

4.0 INTRODUCTION ................................................................................................................................. 45 4.1 IMPLEMENTATIONS OF THE SYSTEM ....................................................................................................... 45

4.1.1 Registration phase ......................................................................................................... 46 4.1.2 Login Phase...................................................................................................................... 47 4.1.3 User Dashboard and JSON Web Token (JWT) ........................................................ 48 4.1.4 Database ........................................................................................................................... 49 4.1.5 Checking the token......................................................................................................... 50

4.2 SUMMARY ....................................................................................................................................... 53

CHAPTER 5 ................................................................................................................................... 54

RESULTS ....................................................................................................................................... 54

5.0 INTRODUCTION ................................................................................................................................. 54 5.1RESULTS ........................................................................................................................................... 54

5.1.1 Results of Survey ............................................................................................................ 55 5.2 SUMMARY ....................................................................................................................................... 59

CHAPTER 6 ................................................................................................................................... 60

CONCLUSION ............................................................................................................................... 60

6.1 INTRODUCTION ................................................................................................................................. 60 6.2 CONTRIBUTION ................................................................................................................................. 60 6.3 WEAKNESSES & LIMITATIONS .............................................................................................................. 61 6.4 FUTURE WORKS ................................................................................................................................ 61 6.5 OVERALL CONCLUSION ....................................................................................................................... 62

REFERENCES ............................................................................................................................... 63

APPENDIX ..................................................................................................................................... 66

A. PROJECT TIMELINE .............................................................................................................................. 66 A.1. Gantt Charts of FYP1 ....................................................................................................... 66 A.2. Gantt Charts of FYP2 ....................................................................................................... 67

10

LIST OF FIGURES

Figure 2.4.1: structure of JWT. 23

Figure 2.4.2: JWT header. 23

Figure 2.4.3: JWT payload 24

Figure 2.4.4: JWT signature 25

Figure 2.4.5: JWT example 25

Figure 2.5.1 Schema Algorithm of Public Key 28

Figure 3.2 Framework 35

Figure 3.3 Use Case Diagram 37

Figure 3.4.1 flowchart for Registration and Login process 38

Figure 3.4.2 Flowchart for token validation 40

Figure 3.4.3.1 Flowchart of Encryption Process for RSA 42

Figure 3.4.3.2 Flowchart of Decryption Process for RSA 44

Figure 4.1.1: Registration interface 46

Figure 4.1.2: Login interface 47

Figure 4.1.3: Dashboard interface 49

Figure 4.1.4: mongodb database. 50

Figure 4.1.5.1: Header of the token 51

Figure 4.1.5.2: Payload of the token. 52

11

Figure 4.1.5.3: Signature of the token 53

Figure 5.1.1.3: The number of user's accounts that still safe. 58

12

LIST OF TABLES

Table 5.1.1.1: Details of 10 registered users with a text-based 56

password.

Table 5.1.1.2: Details of 10 registered users with a token-based 57

password.

13

CHAPTER 1

INTRODUCTION

1.1 BACKGROUND

Authentication is any protocol or process that charter one entity to

authorize the identity of another entity [15]. Authentication also defined as the

process of determining whether someone or something is who or what it

declares itself to be. By checking to see if a user's credentials match or not in a

database of authorized users in the data authentication server, the technology

in authentication provides access control for systems. Usually, users are

identified by a user ID, and password. The authentication is accomplished when

the user provides a credential such as a password, that matches with that user

ID. There are a lot of different authentication methods were introduced and

applied. Every single of them trying to get the user's attention by offering the

most secure service than others. In the beginning, they introduced password-

based authentication. Next, they offered session-based, biometric

authentication, and later they offered token-based authentication [12]. The

password-based technique is widely used nowadays to verify and authenticate

users. A password is a secret word or phrase that created to ensuring the

unauthorized user cannot access the restricted resource by the user. Password

14

also well known that there is a tension between security usability. A secure

password is often tended to be difficult to remember, as an example because it

is less usable by the user. To make the authentication system to be practical,

password and token-based authentication have designed to provide additional

security in fast performance. Authentication is really necessary because it

enables organizations to keep their networks secure by permitting only

authenticated users or processes to access its protected resources. This may

include computer systems, networks, databases, websites, and other network-

based applications or services. Once authenticated, a user or process is usually

subjected to an authorization process as well. This process is to determine

whether the authenticated entity should be permitted access or not to a

protected resource or system. If that user was not granted permission to access

it, a user can be authenticated but fail to be given access to a resource.

In the field of information technology, tokens are new terms [3]. It is often

hardware-use items for identifying and authenticating users and also can be

software-based artifacts of permission granting systems, where the multipath

authentication algorithms are used [6]. Usually, tokens are shared between

multiple components. This will be making every token has to be unique in its

usage, autonomous and not repeated. It also contains only tacit information

such as they carry information about the owner of the token, the purpose of the

token, and how long the validation of the token [6]. There are different types of

tokens referring to RFC which are perishable token, session token, access

token, and refresh token. Token-based authentication was the most trusted

authentication because it is structure and described authentication using

https://searchsoftwarequality.techtarget.com/definition/authorization

15

certificates. It is also a technique that the user needs a token to be

authenticated.

JSON Web Token (JWT) is an open standard (RFC 7519). It illustrates

a compact and self-contained way to securely address information between

parties as a JSON object [5]. This information can be verified and trusted

because it is digitally signed. JSON Web Tokens is to contribute an open and

ensure a way for defining claims between two parties [7]. JWT contains tripartite

which are Header, Payload, and Signature token structure that is encoded in a

compact JSON serialization format which is using Base64-URL. It is contained

JSON Web Signature (JWS) and JSON Web Encryption (JWE) [12].

1.2 PROBLEM STATEMENT

Many users use the passwords for remote authentication in an

untrustworthy environment or use the same password repeatedly. They tend to

repeat it because they feel convenient without remembering many passwords

for different applications.

Nowadays, the use of token-based authentication is still new and not

truly widely used. For this reason, there are still have users that did not aware

of the ability of token in authenticating them. They still used one only common

authentication mechanism to authenticate them such as password

authentication to provide basic computer security.

Furthermore, users are not realizing the existence of token-based

authentication in the daily applications they are used such as in online banking

https://tools.ietf.org/html/rfc7519

16

that provides users to enter the TAC number, which is one of the types of types

to authorize them. For this reason, the users will not familiar with how token

works and their effectiveness after using it.

1.3 OBJECTIVES

This project aims to evaluate the effectiveness of using token-based

authentication in the JSON web token method to improve the security system.

The objective as follows:

• To study how token work in compactly authenticate the user.

• To propose the authentication system using token-based and JSON

Web Token as a method.

• To implement token-based authentication at the web page.

1.4 SCOPES OF WORK

The main highlight of this project is to implement the JSON Web Token in

the RSA algorithm for user authentication which involves the user and the

application. The scope of this project is involved in the user scope and the

application scope.

Firstly, for the user scope, the user will able to register the application as a

user. The users will register the data and the data will be stored in the local

17

storage in the webserver. Next, the user will be able to login after permitting the

application to access the resources.

The application scope is the application will save the user data after the

registration in the local storage. Moreover, the application also will be able to

send the token to the user after the user enters their credentials at the login

session.

1.5 LIMITATION OF WORKS

• Only can be used in the authentication session.

• The token cannot be modified freely.

1.6 THESIS ORGANIZATION

This thesis consists of 5 chapters and it covers all the necessary information

about the project.

Chapter1

This chapter covers the important parts which the details of the whole project.

The parts of this chapter include the background of the project, problem

statement, objectives, scope, limitation of work, and also the expected result for

this project.

18

Chapter2

In chapter 2, the thesis mainly covers the related work of the previous

researchers that were used as a reference for this project that will help to gain

more understanding and knowledge of the project idea. This chapter discussed

token-based authentication, JSON Web Token, and RSA algorithm based on

the reading material and sources such as the journal, related website, and

existing project.

Chapter3

This chapter is for methodology details. This chapter will explain the framework

and the system requirement of this project which is hardware and software that

this project used to produce results. The diagram including framework, use case

diagram, and flowchart diagram will be described in detail in this chapter.

Chapter4

This chapter will describe the implementation and testing of the project. This

chapter also where the result of the project is being shown and it covers the

discussion about the result.

Chapter5

The conclusion included in this chapter. This last chapter describes the project's

conclusion, system contributions, system constraints, and recommendations for

future works. The summary of the whole thesis also will be described in this

chapter.

19

1.7 SUMMARY

The details of the system were discussed in this chapter. The token-based

authentication using JSON Web Token was used to overcome the problem.

After the detailed explanation in this chapter, it proceeds to the next chapter

about the literature review.

20

CHAPTER 2

LITERATURE REVIEW

2.1INTRODUCTION

There are similar published studies concerns token-based authentication,

JSON Web Token (JWT), and RSA. This chapter will discuss the basic

concept of authentication using the JSON Web Token and RSA algorithm.

Besides that, some of the related or existing works will be discussed as well.

2.2 OVERVIEW OF AUTHENTICATION

In information technology, authentication is a process of verifying you who you

are, and are you pretend to be or not [3]. It helps to determine proof of identity.

To know whether an authentication system is computer-based or not, there are

several elements and certain things take place. Firstly, we need a particular

person or group of people to be authenticated. Next, we need the different

characteristic that a particular person or group from others. Then, for the system

being used and relies on mechanized authentication, we need a proprietor to

differentiate authorized users from other people. Forth, to verify the presence

21

of the distinguishing characteristic, we need an authentication mechanism.

Lastly, when the authentication succeeds by using an access control

mechanism and the same mechanism denies the privilege if authentication fails,

we grant some privilege [3]. To access resources, users can be authenticated

via passwords, biometric, token-based, or certificates. All of these methods

require an authentication factor of the supplicant. It is individual information or

an object that presented to the authentication server. Authentication factors are

classified as either a knowledge factor which is an authentication server and a

supplicant share a secret such as a password or a personal identification

number. Next, ownership factor which is the supplicant owns an object, which

cannot be copied or which hardly duplicated. Then, the inherence factor is a

factor that permanently connected to the supplicant such as a biometric

criterion. Each of these authentication factors needs to fulfill some quality

criteria such as in the case of username or password- authentication, it needs

to respect to the chosen password and has to be protected against

unauthorized access [18]. In this project, the token-based authentication is

discussed.

2.3 TOKEN-BASED AUTHENTICATION

In [3] states that the usage of the token has increased dramatically from year to

year. Tokens are system generated arbitrary construct that asserts the identity

of what it claims and utilized as a key to confirm the client for secure record

login [12][2]. It carries information about the user who wants to authenticate

22

because of the word of the token, which is signed not encrypted. The token is

usually hardware-items for identifying and authenticating users such as smart

cards but, token also can be software artifacts or permission granting systems,

where multipath authentication algorithms are used. There are different types

of token referred to RFC which are a perishable token that used to validate a

single action, session token that valid for one specific session and can be

several times within this session, access token that can be used multiple times

but cannot be renewed and refresh token that can be only once which is must

be invalid after use [3]. Token-based authentication covers the exchange of

client authentication credentials. The credentials are needed to the server-

generated authentication server and for the subsequent client request to

access. It sent the token as part of the request in the HTTP header to the server

[12].

2.4 JSON WEB TOKEN (JWT)

RFC 7519 is an open standard of JSON Web Token (JWT). In defining a

compact and self-contained way for securely transmitting information between

parties as a JSON object, this information can be verified and trusted because

it is digitally signed. By using a secret with the HMAC algorithm or a public or

private key pair using RSA or ECDSA, JWTs can be signed. The integrity of the

claims contained within it can be verified by signed tokens. While encrypted the

tokens, those claims are hidden from other parties. The signature often certifies

that it is only the party holding the private key that has signed it when the tokens

23

are signed using a public or private key pair. JSON Web Tokens are useful in

authorization and information exchange. That subsequent request will include

a JWT that will allow the user to access the paths, facilities, and resources that

the token unlocks when the user logs in. In the exchange of information, since

JWTs can be signed, such as using public or private key pairs, JSON Web

Tokens are a good way to securely transmit information between parties.

However, since the signature is determined using the header and the payload,

this can make it possible for the user to check that the material has not been

tampered with. In the compact form of JSON Web Token structure, it consists

of three parts separated by dots (.), which are header, payload, and signature.

Therefore, a JWT typically looks like the following:

Figure 2.4.1: structure of JWT.

JWT header consists of two parts which are a type of tokens such as JWT and

the signing algorithm being used such as HMAC SHA256 or RSA. This JSON

is the Base64 URL encoded to form this first part of JWT. For example:

Figure 2.4.2: JWT header.

Next, the second part of the token is the payload which contains the claims.

Claims include claims about an object, typically about a user and other

additional data. Claims also have their forms, which include three categories of

24

licensed, public, and private claims. Registered claims are a collection of

predefined claims that are not compulsory but recommended. It is intended to

provide a collection of valid and interoperable statements. There are some of

them are iss(issuer), exp (expiration time), sub(subject), aud(audience), and

others. Furthermore, public claims can be defined at will by those using JWTs.

To avoid the collisions, it specified in the IANA JSON Web Token Registry or

be defined as a URL that consists of a collision-resistant namespace. Lastly,

private claims which are the custom claims have been generated to share

information between two parties. It agreed on using them and are neither

registered or public claims. The payload also in the Base64Url encoded to form

this second part of JWT. As an example of the payload is:

Figure 2.4.3: JWT payload

Lastly, the signature. The use of signature is to verify the message has not been

changed along the way and it can also verify that the sender of the JWT is who

it says it is in the case of tokens signed with a private key. While creating the

signature component, it needs to take the encoded header, the encoded

payload, a secret, the algorithm specified in the header, and sign that. There is

an example of a signature in the form of an HMAC SHA256 algorithm:

25

Figure 2.4.4: JWT signature

All of these parts need to be put all together and the output of these three parts

is in Base64-URL strings and separated by dots. This can result in JWT can be

easily passed in HTML and HTTP environments, while being more compact

when compared to XML-based standards such as SAML.

Figure 2.4.5: JWT example

.

2.5 RSA ALGORITHM

Ron Rivest, Adi Shamir, and Leonard Adleman have introduced a cryptographic

algorithm in 1978. This algorithm is essential to replace the less secure National

Bureau of Standards (NBS) algorithm [9]. The motivation of RSA is the

published works of Diffle and Hellman that described the idea of such an

algorithm but never developed it[9]. RSA is an asymmetric key cryptosystem

relies on the assumption. The distribution that involves is the public and private

key to the sender and receiver to encrypt and decrypt the message respectively.

It uses two prime numbers to generate public and private keys.

26

RSA is determined its security from the adversity of factoring huge integers that

are the product of two huge prime numbers. Although by multiplying these two

numbers are easy, but derive the original prime numbers from the total factoring

is the deal with absurd. The most complex part if RSA cryptography is the public

and private key-generation algorithm. The two huge prime numbers, p, and q

are set up using the Rabin-Miller primality test algorithm. By multiplying p and

q, a modulus n is calculated. This modulus is worn by both the public and private

keys that bring the links between them. Its diameter, commonly describe in bits

that called key length. Public key contains the modulus n and the public

exponent, e, which normally set a 65537, as its prime number that not too big.

Public exponent, e, doesn't need to be privately selected prime number as the

public key exponent d, which is determined by using the Extended Euclidean

algorithm to find the multiplicative inverse concerning the totient of n.

The following steps below show the example of the RSA algorithm.

1. Select p=3 and q=11

2. Calculate n =p*q

=3*11

=33

3. Calculate φ(n)=(p-1)*(q-1)

=(3-1)*(11-1)

=20

4. Select e with respect to 1

27

6. Public key is (e,n) where e=7 and n=33

7. Private key is (d,n) where d=3 and n=33

=> m = cd mod n

8. Encryption of m=2 is C= m^ e mod n => C=2^7 % 33 = 29

9. Decryption of c= 29 is m = cd mod n => m= 29^3 % 33=2

According to this example, two big prime number p and q have to be

generated. These numbers are very huge at least 512 digits, but 1024 digits are

considered protected. For RSA security, two very huge prime numbers must be

generated that pretty far apart. RSA is insecure when generating composite

numbers, or even prime numbers that are close together. A modulus n is

calculated by multiplying p and q from the two huge numbers. Upon the fact that

given two large prime numbers, a composite number, in this case, n can very

easily be deduced by multiplying the two primes together is the RSA'S main

foundation relies on. Nevertheless, given just n, there is no known algorithm to

effectively determine n's prime factor. It is considered a tough problem. The

totient of n, ϕ(n) is computed. The totient can be very quickly calculated as

ϕ(n)=(p−1)⋅(q−1), with the prime factors of n. then, the public key is specified. It

is a prime number which a prime number is generated from the

range [7,ϕ(n)) that has a greatest common divisor of 1 with ϕ(n) that commonly

declare as e. 7 is a greatest common divisor of 1 with ϕ(n) for the thoughts of

the capable reader and 7 is selected that could lead to security flaws. Thus, in

practice, the public key is usually set at 65537. It has a high chance of a gcd

equal to 1 with ϕ(n) because the public key is prime. We must use another

prime number that is not 65537 if this is not the case. However, this only

appears if 65537 is a factor of ϕ(n), something that is quite impossible but must

28

still be checked for. A key pair of the exponent e and the modulus n is the public

key. It is present as follows (e,n). The multiplicative inverse of the public key

concerning ϕ(n) can be accurately and immediately specified using

the Extended Euclidean Algorithm because the public key has

a gcd of 1 with ϕ(n). the private key is the multiplicative inverse. The normal

notation for declares the private key is d so, we have the following equation

(one of the most important equations in RSA) as e⋅ d=1 mod ϕ(n). The private

key is a key pair of the exponent d and modulus n as (d,n), the same goes to

the public key. Given a public key is one of the ultimate fundamental security

assumptions behind RSA, one cannot efficiently determine the private key.

Let choose m to be 2, the encryption and decryption can identify based on the

example above.

Cipher Text Plain Text

Figure 2.5.1 shows a Schema Algorithm of Public Key

2.6 EXISTING SYSTEM

Nowadays, many hackers hack our credentials such as personal data for their

benefits like bank details. There are many authentication methods are used but

Private

Key

Public

Key

Decrypt Encrypt A B

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

29

still need to improve because mostly the existing approaches are easy to crack

or hack. For instance, the password is too easy for guessing and loss to

someone.

In 2012, [18] have proposed a system for secure hardware token-based

authentication. In this paper, hardware token-based user authentication which

allows single sign-on had been proposed for multiple client applications

distributed over several servers that didn't modify on the server-side. The

approach that presented is using the user certificate stored in the token whereby

the pin of the token has to be put in only once and not each time a new

application is called. In this paper, they used hardware token because it is a

hardware that easy to bring that contains microprocessors, volatile and non-

volatile memory, operating system, and interfaces for computer connections

such as smartcards and sticks with USB connectors. In this paper, they

combined a certificate-based authentication mechanism using cryptographic

hardware tokens with single sign-on software. The purpose of this combination

is certificate-based approaches have the drawback of it require a public key

infrastructure (PKI) and adequate transport methods for the associated keys.

Moreover, it also increases the efforts of service providers and users. However,

the people do not accept the technology if the raise of security is the only

disagreement because of the proposed approach that requires carrying

additional hardware. So, they conclude that this approach needs to be

expanded by further functionalities that ease the user's tasks without loss of

security, to raise the user's acceptance.

In 2016, [11] have proposed an authentication system that used two factors

zero-knowledge proof. The system that proposed in this paper is to solve all the

30

problems of hardware or software keyloggers that user need to log in at

untrusted devices such as public kiosks or other possibly compromised systems

which can allow an adversary to have full knowledge of all data transferred from

the user to the system and also shoulder surfing that is prevalent in a public

area such as outdoor ATMs. The proposed protocol is a two-factor

authentication scheme which means that both pieces of knowledge of the

password and ownership of the device are strictly necessary to login. This

means that the protocol is intended to allow a user to log in to an account on an

untrusted device while in the presence of keylogging and shoulder surfing using

an unsecured network. The reason that they combined the use of zero-

knowledge proofs and two-factor authentications is that's an only reliable and

practical way to login to systems in situations involve not passing any sensitive

information through the untrusted device. The security that involved in this

system is secure password storage because the proposed protocol avoids the

issue of passwords are often leaked due to the user send directly his passwords

to the server by never giving the passwords of the users to the server in the first

place. Next, it involved two factors that are necessary to log in. This is because

they want to make sure that only users with both factors of knowledge of

password and ownership of the trusted device can successfully log in. Then,

security on keylogging also involved in this system. Because of one of the

assumptions made is that the untrusted device is being key logged, the two

tokens are randomly generated and provide an adversary with no information

on the user's password of the trusted device's secret key. If the adversary

attempts to use one of the tokens to log in then he will not be successful

because only the unique computer that is halfway “logged in” and the untrusted

31

device that the user is using to log in can finish log in attempt. Lastly, this system

involved the security of an unsecured network. The adversary was able to read

everything sent and received by the server in eavesdropping if the network is

unsecured. To prevent this, the server and the trusted device agree on a

username and the trusted device sends the server both public keys. The

vulnerabilities also detected in this system in case of trusting the trusted device,

denial attack, and passive vs active attacks.

In 2017, [14] have proposed a system to secure RESTful web services. This

system is developing for multiple tokens, one per transaction. The method that

is used for the token-based is JSON Web Token (JWT). The algorithm that is

used for the signature in JWT is the HMAC algorithm. The objective of this work

is to develop a scalable authentication and authorization system based on

tokens that allow any time token revocation, that complies with the stateless

constraint of RESTful web services and that prevents replay attacks. Because

of its simplicity, instead of adapting an existing framework to the needs, the

authors decided to build a custom authorization system based on JWT. In this

paper, they compared the performance of a single token and multiple tokens

using only one server and two servers. The result of the performance obtained

is similar. There is only 5% of the obtained values. There are only a single server

and the slight time increase because of the time needed to issue the new token.

However, when two servers are used, the performance will be worse. By

comparing the time per transaction with that obtained using a single token and

one server, the result was increased by 32% and an increase of 126% in

comparison to a single token with two servers. They also compared the

performance of multiple tokens with that of database authentication that

32

conclude the multiple tokens has a much better performance. Time per

transaction of the latter is worse by 140% but the results of using a single server,

that value rises to 198%. In conclusion, the proposed system has a worse

performance because of the use of multiple tokens compared to the single token

but these multiple tokens have the advantage of enabling fast token revoking if

a device is compromised.

In October 2017, [12] had proposed a system to ease the user to access the

protected resources by using secure JWT access tokens. The proposed model

in this research paper, token-based authentication, and access control model is

used. In this paper, the access control model is tracked and charted to be in line

with the present Resource Access Policy (RAP). The flow of this proposed

process is stated like this. First, the user appeal calls to the resource that goes

over a Policy Match gate (PMG). Each activity or process is monitored by Policy

Activity Monitor (PAM) that assures the user access tokens making the call have

the allot RAP. The advantages of this proposed model in this paper are the

security and scalability and efficiency. In the form of security, the model accepts

a dual authentication mechanism at Policy Match Gate (PMG) and the resource

server (RS) for each User, Application, or Device (UAD). It deals to persuade

the security of cloud resources and to provide concurrency of policy and token

per UAD. In terms of scalability and efficiency, cloud-based authentication that

using IdPs ensure efficiency to meet increased user access demands because

of the use of compacts appearance of the JWT (JSON Web Token) UAD (User,

Apps, or Device) GAR (Granted Access Right) which is highly portable via

HTTPS header.

33

In 2018, [16] have proposed a system that used token-based single sign-on with

JWT as an information dashboard for the government. They used JSON Web

Token because it has an advantage as a token authorization of single sign-on

since JWTs can authenticate the sender of the request on the receiver. In this

paper, they compared the performance of the proposed SSO to a non-JWT

based SSO that usually uses an encryption token. They also compared a token

of JWT containing roles to a token of JWT without roles and a token of non-

JWT. They also build a menu dashboard that provides a list of the information

system to facilitate users' access because the proposed SSO has been

implemented with another functionality in this system. The result of the

proposed SSO shows better performance than SSO with the conventional token

as the JWT based SSO can do authorization and send information user as well

as roles of the user with only a single token and a single request. But this system

also has its limitation which is there is still no discussion about how to manage

the session of each accessed information system centrally.

2.7 SUMMARY

In this chapter, from what had been explained on the above page, hopefully,

this chapter would provide an overview regarding the concept of the application.

Based on the study that had been made, it shows that the literature review is

one of the important parts in research and we could know whether the idea had

been studying or not.

34

CHAPTER 3

METHODOLOGY

3.0 INTRODUCTION

The methodology is the entire framework or design of the research which is the

choice of methods, tools, and techniques to be applied in the project. This

chapter will explain thoroughly the specific details on the method that will be

used to run in this project. The project methodology is important to ensure the

project can be accomplished and working as planned. All diagrams that applied

in structural analysis and design are implemented which are used framework,

use case diagram, and sequence diagram of the system in the logical model.

3.1 LOGICAL MODEL

A logical model usually used during planning and implementation. This model

acts as a tool to evaluate the effectiveness of the program or the system that is

also known as a logical framework. Logic models are usually a graphical

representation of the logical relationships between the resources, activities, and

35

outputs. The underlying purpose of constructing a logic model is to assess the

causal relationship between the elements.

3.2 FRAMEWORK

Figure 3.2 Framework

Figure 3.2 shows a framework of the token-based authentication using the

JSON web token (JWT). This framework describes the overview of the system

work. The framework shows guidelines for the user. In the registration process,

users need to register their information or data in the provided form. The

information will send to the server and save in the database. Now, the user can

36

log in to the system. In the login process, the user needs to enter their username

and password in the browser and send it to the server. The server will compare

the username and password with the database. If the username and password

are matching, the server will validate login, and JSON Web Token will generate

a token. Then, the token will be returned to the browser and save the token in

the local storage. Next, the user will enter the token after getting it from the local

storage and input the token in the browser. The server will verify the token.

3.3 USE CASE DIAGRAM

A use case diagram is a graphic representation of the interactions among the

elements of the application. Uses cases are typically used to illustrate the visible

interactions that the application would have with users and external

applications. A use case diagram contains four components included the

boundary, the user, the use cases, and the relationship between the user and

the use case.

37

Figure 3.3 Use Case Diagram

Figure 3.3 shows that the user can register the application. From this process,

the user needs to enter their information such as name, username, password,

and email in the provided form. Then, the user can involve in the login process.

In this process, the user needs to enter the username and password, then the

system will generate a token to the user if the data collected in the login process

are matched in the local storage in the server. Next, the user needs to insert the

token to be authenticated. Also, the login process provides the user to change

their profile if they want.

38

3.4 FLOWCHART

3.4.1 Flowchart of registration and login process.

Figure 3.4.1 flowchart for Registration and Login process

Figure 3.4.1 shows the flowchart of the registration and login process. In the

registration process, the user will start and go through the registration by

entering the details in the form provided. Then, the registration will successful.

39

After the successful registration, the user can log in to the system. In the login

process, it requires the user to enter the username and password. If the input

of username and password matches in the database, the server will generate

the JSON Web Token (JWT) and send it to the user. If not match, the system

will display the login page that requires the user to input the username and

password again.

40

3.4.2Flowchart of token validation

Figure 3.4.2 Flowchart for token validation

Figure 3.4.2 shows the flowchart of token validation. After the user enters the

token back to the server, the server will check the validation of the token. The

process of checking the validity of the token will start with the user input token

and it checks the validity of JSON Web Token (JWT). If JWT is valid, it will check

the signature, and if the signature is still valid, it will check the validation time

41

(expired time). If JWT and signature not valid, the token is considered as invalid

and if the validation time is expired, the token is considered as an expired token.

If the JWT, signature, and validation time is valid, the server will generate

session and provide services to the user.

1. User will input the token

2. The server will check the token validation that consists of validity JWT

and signature.

3. If JWT is valid, the server will check the validity of the signature. If not,

it considers as an invalid token.

4. If the signature is valid, the server will check the validation time

(expired or not), if not valid, the token is considered as an invalid token.

5. If validation time is valid, the server will generate session and provide

services to the user, if not valid, the token is considered as an expired

token.

3.4.3 Flowchart of the RSA algorithm

In generating the token, JSON Web Token will use the RSA algorithm to

encrypt and decrypt the token. RSA algorithm consists of the public and private

keys. It is one of the best-known public-key cryptosystems for key exchange or

digital signatures or encryption of block of data.

42

3.4.3.1 Flowchart of Encryption Process For RSA

Figure 3.4.3.1 Flowchart of Encryption Process For RSA

Figure 3.4.3.1 Flowchart of Encryption Process For RSA. RSA algorithm can be

used for both key exchange and digital signatures. The mathematical behind

RSA is relatively straight forward, even though it deals with numbers using

43

hundreds of digits. The following steps can be used to create an RSA public

and private key pair.

1. Two prime numbers, p, and q need to be chosen. From these prime

numbers, you can calculate the modulus, n=pq.

2. A third number, e is needed to be selected that is relatively prime to

(i.e. it does not divide evenly into) the product (p-1)(q-1), the number e

is the public exponent.

3. An integer d needs to be calculated from the quotient (𝑒𝑑−1)

(𝑝−1)(𝑞−1). The

number d is the private exponent.

4. The number pair (n,e) is the public key. Even though these values are

publicly known, it is computationally infeasible to know d from n and e if

p and q are large.

5. Creates the ciphertext, C, using the equation C= 𝑀𝑒 Mod n, to encrypt

a message, M, with the public key.

6. Then, by using the equation M= 𝐶𝑑 Mod n the receiver can decrypt the

ciphertext with the private key.

By assuming that a sender ‘A’ wants to send a message to a receiver ‘B’,

the sender wall takes these steps;

1. Gain the recipients B’s public key (e,n).

2. M represents the plaintext message as a positive integer.

3. Calculate the ciphertext C= 𝑀𝑒 Mod n

4. Deliver the ciphertext, C to B.

44

3.4.3.2 Flowchart of Decryption Process For RSA

Figure 3.4.3.2 Flowchart of Decryption Process For RSA

Figure 3.4.3.2 Flowchart of Decryption Process For RSA. To receive the

message that had been sent by the sender ‘A’, the recipient ‘B’ will take the

following steps:

1. To calculate M= 𝐶𝑒 Mod n, use the private key (n,d).

2. Derive the plaintext from the integer representation M.

45

CHAPTER 4

SYSTEM IMPLEMENTATIONS

4.0 Introduction

This system is implemented as a webpage system using JavaScript language.

In this system, angular is used for creating efficient and sophisticated single-

page apps at the frontend and at the backend, node js is using to add the

function of JSON Web Token(JWT) and database. This system contains 3 main

functions, which are registration, login, and authentication.

4.1 Implementations of the system

This system is implemented as a login system and can be accessed through

any browser. Two primary features are user-oriented, which are registration and

login. Users can log in to the system using the browser. The other key feature

of authentication is system-oriented and cannot be reached by users.

46

4.1.1 Registration phase

During the registration process, users need to have the key in their credentials,

such as username, password, and password validation, as shown in Figure 4.1.

This phase is very relevant as it will be used to authenticate the user with his /

her credentials in the database whether or not it fits the registration and login

process.

Figure 4.1.1: Registration interface

Case 1: If registered successfully

Successful register to the user had successfully registered himself into the

system. The database of the system now contains useful information such as a

username, password, and email. The user can now login to the system using

their username and password also they will get their token.

47

Now, the user is successfully login in with their credentials and get their token

successfully. Users also can access their dashboard after successful login.

Case 2: If failed to register

Failed to register means the user did not register successfully into the system

database. He might be doing something wrong within the step in registering

himself into a system database such as did not confirm the password. System

database does not contain user information such as username and password

therefore the user cannot log in into the system yet and have to try to register

himself into the system database again.

4.1.2 Login Phase

Figure 4.1.2: login interface

48

Login interfaces are shown to users when they try to access the system as

shown in Figure 4.2. when trying to access the system, this interface is shown

first and required users to be authenticated by the system to gain access to

the system. It lets the user to key in username and password to be continued.

4.1.3 User Dashboard and JSON Web Token (JWT)

If the login session is successful, the user will get the user dashboard and get

their token as shown in figure 4.1.1.2. The token will be generated after the

user successful login with their credentials in JSON Web Token (JWT) format.

The information that included in the token’s payload are the username of the

user, iat (the time that JSON Web Token (JWT) was issued that used to

determine the age of the token) and exp (expiration times that used to reject

the token which have been expired). The token will be sent through the HTTP

header to the user and the user will be automatically authenticated after get

the token.

49

Figure 4.1.3: dashboard interface

4.1.4 Database

This system is using mongodb database. MongoDB is a document-oriented

NoSQL database used for high-volume data collection. Instead of using tables

and rows as in standard relational databases, MongoDB uses sets and records.

Documents consist of key-value pairs which are the basic data unit in

MongoDB. Collections include collections of records and features that are

similar to the relational database tables. All of the input that successfully register

in registration phase will be recorded in mongodb database and it will be used

in matching process during login phase.

JSON Web

Token (JWT)

50

Figure 4.1.4: mongodb database.

4.1.5 Checking the token

To checking the token that has been implemented, jwt.io was used. Jwt.io is

an official website that provide the platform to check or verify the JSON Web

Token (JWT). The user only needs to input the token and the details of the

token will be come out. The valid token should consist three part which are

header, payload and signature.

51

4.1.5.1 Header

In the header part, it consists of type and algorithm of the token. In this

system, the token it would be JWT and the algorithm that implemented is

RS256. Figure 4.1.5.1 shows the header of the token and the algorithm that

has been implemented in the system.

Figure 4.1.5.1: Header of the token

4.1.5.2 Payload

In this implemented system, the payload will contain three things which are

username, iat and exp. Username will contain the username of the user that

recorded during the registration phase, iat is time the token was issued that

used to determine the age of the token and exp is expiration time stamp. Figure

4.1.5.2 shows the payload part in the token.

Implemented

algorithm: RSA &

SHA256

52

Figure 4.1.5.2: Payload of the token.

4.1.5.3 Signature

In the signature part, it consists all the header and payload but these two parts

will be signed with the signing algorithm. In this implemented system, RSA

SHA256 has been used to sign the signature part. Figure 4.1.5.3 shows the

signature of the token that has been signed with RSA SHA256.

Payload that have all the

information of the token

such as username, age of

the token and the

expiration of the token.

53

Figure 4.1.5.3: Signature of the token

4.2 Summary

To login to the system, users need to register their credentials into the user

database first. To be authenticated into the system, the user needs to key in

their email and password and gain the token. After the successful login phase,

the user will get their dashboard and gain the token that contain of their

information.

Signature verification

54

CHAPTER 5

RESULTS

5.0 Introduction

To test the consistency and reliability of the system, surveys and evaluations

were carried out. A total of 6 different users are invited to the survey. They are

divided into 2 classes of 3 users. The first group of users is asked to log in to

their username and password with their token. In the other party, users are

asked to sign in to the system using only a standard text-based password. The

outcome is best documented in the sense of protection between the system

introduced and the current system.

5.1Results

The security intensity of the text-based password depends very much on the

text used. The more complex and stronger the elements, the stronger the

strength of the password. However, it is difficult to recall a successful text-based

password and the opponent can still hack the user's credentials for their

products. The security value of a token-based password is as high as a well-

55

constructed one. As for the JSON Web Token (JWT), it is created with user

credentials and digitally signed with an RSA SHA256 algorithm. This makes it

more convenient is that this JWT token is only valid for a limited time. Either

text-based authentication or token-based authentication is carried out, the result

is reported in the tables.

On top of that, comparisons are carried out to test the performance and security

of the system implemented in this thesis.

5.1.1 Results of Survey

In the surveys, a total of 20 different users included children and aged users are

invited. They are divided into 2 groups; each group consisting of 10 users. Each

group is required to register a username and password then login to the system.

56

5.1.1.1 Survey of text-based password

Username Password First week

The first

week

account

safe

Second week

The second

week account

safe

Third week

The third week

account safe

Alex Alex12345 Yes No No

Amira Amira298 Yes No No

Abil2690 AbiL@!98 Yes Yes Yes

Faridfahmi Farid!!!fahmI Yes Yes Yes

Aqilah.nik niKaqilah290 Yes Yes No

aliaMedang AYYA.98 Yes Yes No

Azizahyouz jijahYouzlan98 Yes No No

Hafizza pijAAnis98 Yes Yes No

Izzaty98 Izzatykamarudin98 Yes No No

Asrulpp Asrul98daod Yes Yes No

Table 5.1.1.1: details of 10 registered users with a text-based password.

The table that displays the attribute used to record and survey for 10 different

users who use text-based password are shown in Table 5.1.1.1. the users are

restricted to use a text-based password which is a combination of upper-case

alphabets, lower-case alphabets, and digits. This is because a text-based

password is only secure if contains those elements in the password. The users

are surveyed once every week to check whether their account is still safe or

57

not. Users are surveyed and tested by try to login with username and password

they registered.

5.1.1.2 Survey of token-based password

Username Password First week

The first

week

account

safe

Second week

The second

week account

safe

Third week

The third

week

account

safe

Alex Alex12345 Yes Yes No

Amira Amira298 Yes Yes Yes

Abil2690 AbiL@!98 Yes Yes Yes

Faridfahmi Farid!!!fahmI Yes Yes Yes

Aqilah.nik niKaqilah290 Yes Yes Yes

aliaMedang AYYA.98 Yes Yes Yes

Azizahyouz jijahYouzlan98 Yes Yes Yes

Hafizza pijAAnis98 Yes Yes Yes

Izzaty98 Izzatykamarudin98 Yes Yes Yes

Asrulpp Asrul98daod Yes Yes Yes

Table 5.1.1.2: Details of 10 registered users with a token-based password.

The table that displays the attribute used to record and survey for 10 different

users who use text-based password are shown in Table 5.1.1.1. these users

58

are registered with their credentials and get the token during their login

session and only valid at that time only. If the user inputs the right token, the

user will successfully login, if not, they need to log in again. The users are

surveyed once a week to check whether their account is safe or not with their

username, password, and token.

5.1.1.3 Comparison of Text-based Password Survey and Token-based

Password Survey.

Figure 5.1.1.3: Bar chart shows the number of user's accounts that still safe.

According to figure 5.1.1.3, it can be examined that many users who use a text-

based password lost their account within 2 weeks. The number of users who

still have their accounts decreased very fast after 3 weeks. Moreover, most of

the user use token-based password are still have their account without being

0

1

2

3

4

5

6

7

8

9

10

First week Second week Third week

Chart Title

Text-Based Password Token-Based Password

59

hacked. This can be proof by the data that 9 out of 10 users still have their

accounts after 3 weeks.

5.2 Summary

Token-based authentication has to be more complicated compare to text-based

authentication due to their high-security strength. But, a text-based password is

not secure enough compare to a token-based password because a text-based

password only uses username and password to login compare to a token-based

password that uses the username, password, and token to successfully log in

to the user account. The implemented algorithm in this token-based

authentication system has higher resistance toward shoulder surfing attack

compare to the existing algorithm that has been used nowadays.

60

CHAPTER 6

CONCLUSION

6.1 Introduction

This section concludes the documentation of this project in aspects of the

concept, algorithm, design, implementation, and testing.

6.2 Contribution

In this era of technology, token-based authentication is one of the important

topics in information technology. Token-based authentication has been

proposed as a possible alternative solution to text-based authentication,

motivated particularly by the fact that humans cannot remember many different

passwords for a different account. However, one big issue that is plaguing

token-based authentication is a man in the middle attack that can gain the token

before the user gets it. Unlike tradition text-based password which can be

masked right after user input, image-based password lack of an effective way

to mask the input of user when login. This thesis had discussed an approach to

used JSON Web Token (JWT) with digitally signed with the RSA algorithm. It

61

increased the resistance of this token-based authentication system to the

shoulder surfing attack used by hackers.

6.3 Weaknesses & Limitations

Similar to most of the token-based authentication, this implemented system is

taking a long time to login compare to traditional text-based password

authentication. Due to the setup of this system need the user to correctly key in

the username and password, and if the username and password match in the

database system, the user will get their token digitally signed with the RSA

algorithm. The token was containing their identities such as name, works, and

time the token expired. The token will send through the HTTP header. In this

case, the token will not require another device to get the token. If the key in

username and password does not match, the user will not get any token from

the HTTP header.

6.4 Future Works

The system implemented in this project can indeed provide a very secure token-

based authentication function. To increases the security of this system, the

token should not contain user credentials such as user's job, age, and name to

prevent the adversary gain user privacy information. This can make the token

more useless to the adversary. The website that use the JSON Web Token

62

(JWT) also can add single sign on (SSO) authentication function to access the

website’s features and content.

6.5 Overall Conclusion

This project aims to provide a very secure approach by using token-based

authentication and RSA algorithm. Token-based authentication is one of the

common authentication techniques. It is responsible for login and

authentication. The user first registers username, email, password, and confirm

password through the system. Then, the user can log in using a username and

password and gain the token through the HTTP header. The system

authenticates the user through the token that they gain from the HTTP header.

This process repeated several times and the user must key in the username

and password correctly for all rounds to be authenticated.

63

REFERENCES

1. Aakansha Gokhale, Vijaya Waghmare. (2013). Graphical Password

Authentication Techniques: A Review. International Journal of Science

and Research (IJSR), 279-285.

2. Awasthi, U. (2017). Token-Based Authentication Using Hash Key,

Session, And Javamail Ap. National Journal of Innovative Research in

Computer and Communication Engineering, 12377-12384.

3. Balaj, Y. (September 2017). Token-Based vs Session-Based

Authentication:

4. Christian Huber, J. K. (2016). A Secure Token-Based Communication

for Authentication and Authorization. Future Data and Security

Engineering: Third International Conference. Can Tho City, Vietnam.

5. Introduction to JSON Web Tokens. (n.d.). Retrieved from JWT:

https://jwt.io/introduction/

6. Jan Kubovy, Christian Huber, Markus J¨ager, Josef K¨ung. (2016). A

secure Token-based Communication for Authentication and

Authorization Servers. Future Data and Security Engineering: Third

International Conference, FDSE 2016. Can Tho City, Vietnam.

7. La ´szlo ´ Viktor Ja ´noky, J. ´. (2018). An analysis on the revoking

mechanisms for JSON Web Tokens. International Journal of Distributed

Sensor Network, 1-10.

64

8. Lashkari, A. H. (2014). GPIP: A new Graphical Password based on

Image Portions.

9. Milanov, E. (2009). The RSA Algorithm.

10. Mrs.Aakansha S. Gokhalea, Prof. Vijaya S.Waghmare. (2016). The

Shoulder Surfing Resistant Graphical Password Authentication

Technique. 7th International Conference on Communication,

Computing and Virtualization 2016 (pp. 490-498). Elsevier B.V.

11. Niranjanamurthy, M., Shashank, K., Sumanth, P., & Suhas, B. (2016).

Research Study On Two Factor Zero Knowledge Proof Authentication

System. International Journal of Advance Research in Science and

Engineering, 331-342.

12. Obinna , E., Farraz Fatemi, M., Philipp, W., & Ramin , Y. (October,

2017). A JSON Token-Based Authentication and Access Management

Schema for Cloud SaaS Applications.

13. P. Baby Maruthi1, Dr. K. Sandhya Rani, . (2017). Recall Based

Authentication System- An Overview . International Conference on

Innovative Applications in Engineering and Information Technology,

(pp. 121-125).

14. Pedro, M., Rui, M., Pedro, M.-P., & Carlos, S. (2017). Securing

RESTful Web Services using Multiple JSON Web Token. Proceedings

of the World Congress on Engineering 2017.

15. Priti, J., & Lalit, D. (2013). Survey on Authenticate Password

Technique.

65

16. Putu , A., & Linawati Nyoman, P. (2018). Token-based Single Sign-on

with JWT as Information System Dashboard for Government.

TELKOMNIKA, 1745-1751.

17. Rohit Minni, K. S. (2013). An Algorithm to Enhance Security in RSA.

4th ICCCNT 2013 . Tiruchengode, India.

18. Sandro Wefel, Paul Molitor. (2012). Raising User Acceptance of Token-

based Authentication by Single Sign-On. International Journal of

Information and Computer Science, 70-77.

19. Suo, X. (2016). A DESIGN AND ANALYSIS OF GRAPHICAL

PASSWORD .

66

APPENDIX

A. Project Timeline

A.1. Gantt Charts of FYP1

Week

Task

1 2 3 4 5 6 7

Project title proposal

Research

Proposal presentation

Development of methodology

Week

Task

8 9 10 11 12 13 14

Development of methodology

Report drafting of proposal

Presentation 1

Report submission

67

A.2. Gantt Charts of FYP2

Week

Task

1 2 3 4 5 6 7

Implementation of

database

Implementation of

JSON Web Token

(JWT)

Implementation of

RSA algorithm

Testing the

security of the

system against

shoulder surfing

attack

Collect data to

compare

Token-based

authentication

and text-based

authentication

68

Test the security

of the system

against other

attack

Analyse the

finalized system

Iteration of

analysis, design,

and

implementation