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