Project Report on

Password Manager with Multi Factor Authentication

Submitted to Pondicherry University

in partial fulfillment of the requirements for the Degree of

Bachelor of Technology in Information Technolgy

Submitted by
MOHAMED AZHARUDEEN 17TH0002
JENNATHUL FIRDOWS 17TD0002

Under the guidance of

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

BHARATHIYAR COLLEGE OF ENGINEERING & TECHNOLOGY
KARAIKAL- 609 609 (U.T of PONDICHERRY)
Month Year
BHARATHIYAR COLLEGE OF ENGINEERING & TECHNOLOGY
KARAIKAL- 609 609 (U.T of PONDICHERRY)
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

i
 BONAFIDE CERTIFICATE

This is to certify that this project work entitled, “Title ” is a bonafide work
done by MOHAMED AZHARUDEEN(17TH0002) and JENNATHUL
FIRDOWS(17TD0002) in partial fulfillment of Bachelor of Technology in
Information Technolgy of Pondicherry University, Pondicherry and has been
carried out under my direct supervision and guidance.

HEAD OF THE DEPARTMENT INTERNAL GUIDE

Submitted for the University Examination held on _____________________________

INTERNAL EXAMINER EXTERNAL EXAMINER

ii
 ACKNOWLEDGEMENT
Order of Acknowledgement
Chairman
Director Administration
Principal
Head of the Department
Guide
Project – Co-Ordiantor

iii
 ABSTRACT

Password managers take the hassle out of creating and remembering strong passwords.
Password is the most common method for users to authenticate themselves when entering
computer systems or websites. Problem is the sheer number of passwords we have to
remember. Banks, social media accounts, our email and utilities. It is easy to just use one
password across the board. But that make credential stuffing easier. That’s when hackers take
our password from one breached site and try to log in to our account on other sites. Using a
password manager makes it so much easier to generate and store stronger passwords that are
unique to each site, preventing credential stuffing attacks.

Passwords are stolen all the time. Sites and services are at risk of breaches as much as we are
to phishing attacks that try to trick us into turning over our password. Although companies
are meant to scramble our password whenever we enter it known as hashing not all use strong
or modern algorithms, making it easy for hackers to reverse that hashing and read our
password in plain text. Some companies don’t bother to hash at all! That puts our accounts at
risk of fraud or our data at risk of being used against us for identity theft. Password
management is organization and encryption of many personal passwords using a single login.
A master account which has master username and strong master password will be created by
the user. Most of the existing password managers stores passwords in the browser. Among all
browsers open source browsers are more vulnerable for attacks. Our project uses cloud
storage to store encrypted passwords.

KEYWORDS: Authentication, single sign-on, cryptography, master account, master

password, encryption.

iv
 TABLE OF CONTENTS

Title Page

BONAFIDE CERTIFICATE ii
ACKNOWLEDGEMENTS iii
ABSTRACT iv
LIST OF FIGURES................................................................................................viii
LIST OF TABLES.......................................................................................................x
ABBREVIATIONS xi
CHAPTER 1 INTRODUCTION

1.1 Password vulnerabilities.....................................................................................................1

1.1.1 Password Vulnerability due to Phishing........................................................2

1.1.2 Brute Force Attack......................................................................2

1.1.3 Dictionary or Wordlist Attack........................................................................2

1.2 Social Engineering.......................................................................................3

1.3 Malware attack on passwords increasing by the day...................................3
1.4 History of password storage........................................................................3
1.4.1 Plain text.....................................................................................4
1.4.2 Hashing.......................................................................................4
1.4.3 Hashing + Salting.......................................................................4
1.4.4 Hashing + Salting + Key Stretching...........................................5
1.4.5 Hashing + Salting + Memory-hard key stretching.....................5
1.5 The password managers...............................................................................6
1.6 Overview of the project...............................................................................6
1.7 Motivation...................................................................................................7

CHAPTER 2 LITERATURE SURVEY

2.1 Features of some password managers.........................................................8

2.1.1 KeePass.......................................................................................8
2.1.2 Dashlane.....................................................................................9
2.1.3 LastPass......................................................................................9
2.1.4 1Password...................................................................................10
2.2 Technology to facilitate password management.........................................10
2.2.1 Public Key Infrastructure............................................................10
 2.2.2 Single sign-on.............................................................................11
2.2.3 One-Time-Password token.........................................................11
2.3 Password manager with personal server......................................................12
2.4 The Password Manager with a Smartphone................................................12
2.4.1 MBCCO scheme.........................................................................13
2.5 Proposal for safepass password manager....................................................13
2.5.1 OAuth 2.0 client authentication and authorization.....................13
2.5.2 Session based authentication......................................................14
2.6 Cloud password manager using privacy preserved biometrics...................15
2.6.1 Authentication to the cloud password manager..........................15
2.6.2 Synchronization..........................................................................15
2.7 Multi-agent Integrated password management............................................16
2.7.1 Mobile Agent..............................................................................16
2.7.2 Methodology...............................................................................16

CHAPTER 3 DESIGN OF PROPOSED WORK

3.1 Overall Architecture....................................................................................18

3.2 Decomposition of Modules.........................................................................19
3.2.1 Module 1 – Creating Master Account for a user........................19
3.2.1.1 URL categorization based user context.....................19
3.2.2 Module 2 – Storing passwords for specified sites......................20
3.2.3 Module 3 – Authentication of user account
and retrieving passwords............................................................22
3.3 Detailed Description of authentication levels..............................................23
3.3.1 Categorization based on IP address............................................23
3.3.2 Categorization based on type of device......................................24

CHAPTER 4 IMPLEMENTATION ENVIRONMENT

4.1 Software & Hardware Requirements...........................................................25

4.2 PHP..............................................................................................................25
4.3 JavaScript.....................................................................................................26
4.4 PHTML........................................................................................................28
4.5 CSS..............................................................................................................29
4.6 MySQL........................................................................................................30

CHAPTER 5 RESULT DISCUSSION

5.1 Input/ Output Snapshots of Common registration.......................................32

5.2 Input/ Output Snapshots of password retrieval methods.............................35
5.3 Limitations in Base Paper’s Splitpass Password Manager..........................43
5.4 Limitations in LastPass Password manager................................................43
5.5 How we overcome in our Password Manager.............................................43
5.6 Performance Analysis..................................................................................46

CHAPTER 6 CONCLUSION AND FUTURE ENHANCEMENT 47

REFERENCES..........................................................................................................48
LIST OF PUBLICATIONS......................................................................................49
 LIST OF FIGURES

Figure Title Page

2.1 KeePass Password Manager...........................................................................9

3.1 Overall architecture diagram..........................................................................18
3.2 Module 1 – Creating Master Account............................................................19
3.3 URL Categorization.......................................................................................19
3.4 Module 2 – Storing Passwords.......................................................................22
3.5 Module 3 – Retrieving passwords..................................................................22
3.6 State Chart Diagram for categorization based on IP address.........................23
3.7 State Chart Diagram for categorization based on type of device...................24
4.1 Password encryption and insertion in database using PHP............................26
4.2 Implementation of Google Authenticator API in PHP...................................26
4.3 JavaScript to detect android or desktop..........................................................27
4.4 JavaScript for sending OTP............................................................................27
4.5 User registration page using phtml.................................................................28
4.6 Small Modal Style using CSS........................................................................29
4.7 Table for adminusers......................................................................................30
4.8 Table for savedsites........................................................................................31
4.9 Table for websites.......................................................................................... 31
4.10 ER diagram of password manager database.................................................31
5.1 Registration Form...........................................................................................32
5.2 Master Lock Pin generation after registration................................................32
5.3 Account Login Form......................................................................................33
5.4 Visiting Facebook...........................................................................................33
5.5 Profile.............................................................................................................34
5.6 Saving Facebook credentials first time..........................................................34
5.7 Personal device...............................................................................................35
5.8 Level 1 – personal device...............................................................................36
5.9 Facebook Opened – personal device..............................................................36
5.10 Third Party device – Android.......................................................................37
5.11 Level 1 – android.........................................................................................38
5.12 Level 2 – android.........................................................................................39
 LIST OF FIGURES

Figure Title Page

5.13 Facebook opened – android..........................................................................40

5.14 Third Party Device – Desktop......................................................................41
5.15 Level 1 – desktop......................................................................................... 41
5.16 Level 3 – desktop......................................................................................... 42
5.17 Google authenticator TOTP......................................................................... 42
5.18 GoDaddy opened – desktop......................................................................... 43
5.19 Installing LastPass as Chrome extension..................................................... 44
5.20 Saving Godaddy login credentials................................................................44
5.21 Signing in to Godaddy application...............................................................45
5.22 Launching Godaddy Application................................................................. 45
 LIST OF TABLES

Table No. Title Page

2.1 Overview of popular password managers......................................................8

3.1 MD Buffer...................................................................................................... 21
3.2 Processing message in 16-word block...........................................................21
5.1 Level of authentication based on device categorization.................................35
5.2 Performance analysis......................................................................................46
 ABBREVIATIONS

AES Advanced Encryption Standard

ASCII American Standard Code for Information Interchange

BTP Biometric Template Protection

CA Certificate Authority

CSS Cascading Style Sheets

ER Entity Relationship

HTML Hypertext Markup Language

iOS iPhone Operating System

IMAP Internet Message Access Protocol

IP Internet Protocol

KDF Key Derivation Function

MD5 Message-Digest algorithm 5

OTP One Time Password

POP3 Post Office Protocol version 3

PHP Hypertext Preprocessor (or) Personal Home Page

PKI Public Key Infrastructure

SHA Secure Hash Algorithm

SMS Short Message Service

SSO Single Sign On

URL Uniform Resource Locator

USB Universal Serial Bus

U2F Universal 2nd Factor Authentication

 CHAPTER 1
INTRODUCTION

The first method is to store users in a database and directly generate their passwords in the
application. This is the simplest procedure to design, but is nonetheless difficult to implement
due to the risks associated with password storage. Since computing power is continuously
increasing, the risk that a given password can be broken is also steadily rising. A few years
ago, passwords were required to have at least eight characters chosen from three of four
character sets (numbers, lowercase, uppercase and special characters). Today, they need to
have at least 12 characters chosen from all four available character sets in order to rule
out brute force cracking. This is only true if the number of authorized attempts is unlimited.
List of key aspects that need to be ensured are,

 The password must be encrypted using a hash function, and it must be salted, i.e.
associated with another piece of data to ensure that if two people choose identical
passwords, they will still produce different hashes. If the list of passwords is
leaked, this will make it more difficult for attackers to identify commonly used
passwords.
 The procedure for changing password must impose some complexity on the choice
of password. Typically, it is recommended to impose a minimum length of eight
characters chosen from three of the four possible character sets: uppercase letters,
lowercase letters, number and special characters.
 It should not be possible for the same password to be reused, and passwords should
have a finite lifespan. This is rarely enforced for applications intended to be used by
the general public or customers from outside of the company. Even banking websites
do not require the password to be changed.
 If an automatic password recovery procedure is available for lost passwords, it should
send an email with an encoded single-usage and time-restricted link that allows users
to change their password on a dedicated page.

1.1 Password vulnerabilities

Careless behaviour leaves crucial data and passwords vulnerable to cyber threats that can
damage privacy. To get an idea of the risks, Kaspersky reports says that phishing attacks
more than doubled in 2018 to reach almost 500 million and it registers an average of 3.7
million malware attacks per day and blocks 192,000 phishing messages per day. But by
keeping in mind the above-mentioned common password vulnerabilities, we can ensure its
security to an extent.

1.1.1 Password Vulnerability due to Phishing

This type of attack causes victims to believe they are accessing legitimate content, usually e-
mail or websites, when in fact they are accessing fake content produced by the attackers. This
type of content usually leads victims to fill in existing login and password data from other
legitimate sites or services, such as Google and Facebook, which when filled in, allows the
attacker to store the passwords before redirecting the victims to a legitimate site.

Attackers often copy the image of sites almost perfectly, that are looking to steal passwords.
But there are a few important items which cannot be copied, such as the site addresses and
the links within it. Always check the links to make sure they belong to the desired location.

1.1.2 Brute Force Attack

A brute force attack is the name of the action performed on a website to test it with thousands
of software, check against millions of passwords until you find the right one. It is a robot that
randomly tries passwords to connect to the website.

No one can really prevent a robot from doing these actions, but it is possible to reduce and
discourage such hackers. One of the first solutions is to increase the security of the website
by forcing its members to create more complex passwords. For example, a minimum of 8
characters, containing a combination of numbers and letters. This will make the task of the
robot much more complex.

1.1.3 Dictionary or Wordlist Attack

The dictionary-based attack or wordlist attack is also considered a brute-force attack. The
attacker uses files containing thousands or even millions of words of the most varied types
and languages and software that allows this list to be tested quickly until the victim’s
password is found or until the dictionary finishes.

2
Usually, the passwords present in dictionaries are not very extensive, that is, they have less
than ten characters. To avoid becoming a victim of dictionary attacks use passwords that have
more than 12 characters. Like most attacks, the above attacks can be prevented by adopting
some simple behavioural changes, and there are security solutions that can make this task
even simpler.

1.2 Social Engineering

Social engineering is somewhat similar to phishing attacks and is a widespread spying

method aimed at gaining access to confidential data. To extract confidential information,
scammers very often exploit good faith, helpfulness, but also insecurity of people. Whether
over the phone, pretending to be someone else, or the Internet, they are ready to do anything
to get access to personal data.

Reveal as little personal information as possible; social networks are real mines of
information. Be suspicious when asked for email ID. Even emails from known senders can be
falsified.

1.3 Malware attack on passwords increasing by the day

Malware is the most obvious and efficient tactic to steal passwords at the moment. Unlike
most powerful viruses, they are not so apparent because their goal is to steal your data
without you knowing or introduce a remote access Trojan horse to steal your credentials.

To prevent this from happening to you, keep your antivirus up to date, scan frequently and
avoid suspicious sites which are full of pop-up ads.

1.4 History of password storage

When you log in yourself to somewhere using a password, that password has to be stored, in
some form, on the other side. Usually this is in a server: whether it's Facebook, Yahoo, or
shop-rare-trinkets.com, the servers have to have a saved copy of that password. Otherwise,
there would be no way to check whether the password was correct. But having your password
plainly sitting on their servers like that would be a terrible idea. For one, any employee
working there could then look up anyone's password whenever they want, and a password is
a terribly private thing for someone else to be able to read. Anyone who broke into the server
would immediately know your password. So the server has to store your password,
without really storing your password.

1.4.1 Plain text

This is worst method possible, because anyone would only need to overhear it once to know
your password. It's not any different on a server. This is basically never done today, except
when people make really huge mistakes, or are really bad at making secure websites and apps
and need to learn a lot more. In this method, the password can be cracked by someone
listening, rainbow tables, cracking, parallel cracking, predictive cracking and human error.

1.4.2 Hashing

Hashing is the first way people used to solve the problem of how to “check a password
without being able to read it”. Today, this method is very insecure when used on its own, but
it is still used as the basic building block of more secure methods much like how bricks are
still used to build strong houses, but strong houses are never built with only a pile of bricks.
A cryptographic hash is a mathematical method that makes the given input, a jumble of
scramble as the output that is really hard to reverse back into the input. Example of hashing in
action, an algorithm called SHA-256. Notice a tiny change in the password from "1" to "2"
becomes a giant change in the hashed text. So that means a shorter password can't mean a
shorter hash; and passwords that look similar can't end up in hashes that look similar. The
hash must be almost completely and mathematically random when you change the password.
This is done by scramble and together the inputs a lot. This is a little bit like running your
password through a shredder, and using a complicated process to recombine letters.

1.4.3 Hashing + Salting

There are two major problems with using hashing by it. First, hashes are designed to be fast.
If it is fast, and passwords aren't very long and complex, then it can be cracked just by brute-
force cracking: trying all the common password combinations. This means that hashing
doesn't protect the people who happen to be using weak, short passwords. If two people have
the same password hash, that mean they have the same password, they probably both used a
really easy to crack password. Salting made each password entry unique. It just adds a little
touch of complexity if two people happened to share the same password; it is difficult to tell
without trying to crack it first. Salted hashes were the way to store passwords for a long time.
Each password entry is now unique, and attackers can't reverse it without a lot of effort.
1.4.4 Hashing + Salting + Key Stretching

Hashing + salting solved the big problem of someone figuring out, without much cracking, if
people have the same password. But, cracking became a bigger and bigger problem over the
years: computers are just coming too fast. People became more and more easily able to crack
shorter passwords that people can easily memorize, like a single word with some
modifications - basically anything fewer than 10 or 12 characters. At the time they were
invented, computers weren't particularly fast. That means that not being able to reverse the
salted hashes without trying a lot of passwords was good enough security by itself. As time
went on, however, and computing hardware got faster and cheaper, people were finding that
more and more passwords were being cracked. The recommendation to use 6-character
passwords slowly became 8 characters, and now it's at least 10 or 12 at the minimum if you
don't want someone to crack your password in mere seconds. That's basically what key
stretching is: it's basically like saying hashing + salting + slowing down. One obvious
solution still used was to run the hash lots and lots of times. If you take in the input, hash it,
take the output hash it again, and do that hundreds of thousands of times, and make that
repeated process the only way to save the hashed password, then the attacker will have to do
this hundreds of thousands of times , to crack it.

This is a little inconvenient to use. It is slow to log-in. And it's resource-intensive for the
server to run all those repeated rounds of hashing. Still this method could not overcome
parallel cracking and predictive cracking.

1.4.5 Hashing + Salting + Memory-hard key stretching

As graphics cards and dedicated chips become cheaper and more accessible because of more
popularity in machine learning and virtual reality, the problem of people just paying a lot of
money to rent computers in the cloud to crack passwords for them become easier and easier.
The next wave of improvements are really just to fend off the next wave of cheap password
cracking power because supercomputer power that would be unimaginable a decade ago can
be had for only as much money as a big grocery trip.

When we say memory-hard, we are trying to use a weakness in using graphics cards and
dedicated chips: they're good at doing a lot of simple repeated work all at once (like password
hashing), but they can't easily do complicated tasks. One way to complicate that task of
hashing is to make hashing require a huge amount of data, more than would normally fit in
each individual “worker unit” of a graphics card or dedicated chip. In a way, it's just another
way of making the task of password hashing slower and more complicated so each action of
testing a password in the cracking process takes more time.

1.5 The password managers

People are not good at memorizing passwords. People often remember their best memories
likes names, memes, TV shows, books, DOB and all these shared experiences can be used to
predict the types of easy-to-remember passwords they were likely to come up with.
Especially with the rise of more advanced AI, this is more likely to put us more and more at
risk. The only currently defence against this is having lots of long, completely random
passwords, and never use the same password in 2 different accounts. But this is not feasible
to remember, no one should be expected to remember hundreds of unique totally random 24-
character passwords just to keep themselves safe.

More innovation is coming in this space, and it's sorely needed. Password managers such
1Password or KeePass are some among them. Another innovation is 2-factor authentication
that protects against stealing the password with convincing fake websites. The best example
of this is the U2F key, which is a USB-drive-looking device that checks to make sure you're
logging into the right website, and then talks to the website in encrypted code to prove your
identity in addition to your password. Because each key is made to be unique and extremely
difficult for anyone else to copy, this is a second check to make sure you're truly you.

1.6 Overview of the project

Most of the existing password managers stores passwords in the browser. Among
all browsers open source browsers are more vulnerable for attacks.

Our project uses cloud storage to store encrypted passwords. A master account which has
master username and strong master password is created by the user. This master password
will in turn undergo a strong hash technique which will output a 4 digit key. This pin number
will be given to the user. This is the only 4 digit key, which the user has to remember while
entering to other websites. This factor makes the system user friendly. Considering the
factors such as the device in which the account is logged on, user context and number of
times the account is signed in, the authentication factors will be differed. This makes the user
experience more security to some important site and easy sign-on for some other sites.
1.7 Motivation

Our idea is to overcome the above disadvantages and limitations as possible as we can. The
main drawback of existing password management services is that the actual information is
accessed by the browser. With the use of personal server based password managers, the
limitations lies in device dependency. There is a need to carry devices with us always as a
personal storage. With the help of single sign on passwords, users are able to identify
themselves with the authentication server only once to access a variety of applications,
including both internal and external systems. Users can enjoy the benefit of choosing one
password to access multiple applications, instead of memorising many different passwords.
However, compromise of one authentication event could result in the compromise of all
resources that the user has access rights to. BTP is a technology to transform the biometric
data into a protected template and store it in database for direct comparisons without leaking
biometric information. Disadvantage of using this is, environment and usage can affect
measurements, system are not 100% accurate, require integration and/or additional hardware
and cannot be reset once compromised. The main constraints that we try to achieve are device
independency, browser independent etc. So that it can be user-friendly and proceeds with less
time consumption. According to the user context, the password manager will provide the
authentication levels.
 CHAPTER 2
LITERATURE SURVEY

We begin with a detailed survey of the features and policies implemented in widely
deployed password managers. The password managers we survey include:

Last Pass Dashlane 1Password KeePass

Customizable encryption algorithm no no no yes
Customizable KDF no no no yes
Open source no no no yes
Subscription restricted features no no no yes
Breach alert yes yes yes no
No data leaks no yes yes yes
External third-party storage no no no yes
Password sharing yes yes yes no
Password changer yes yes no no
Privacy respecting yes no yes yes
Beginner friendly yes yes yes no

Table 2.1: Overview of popular password managers

2.1 Features of some password managers

2.1.1 KeePass

Keepass is a freely available password storage system. Accessing the password database can
supply the passwords for all encryption used by the suspect. By default, most password
storage systems require a password to access stored passwords. But as mentioned,
complacency is a weakness, and if the password storage program is set to open without a
password, all passwords are available as if written on a sheet of paper. Again, the key is
gaining access to the application. The application code is open and can be parsed at any time.
You can configure the strength of encryption, but only works in Windows. It is free and
recommended by Electronic Frontier Foundation.
 Fig 2.1: KeePass Password Manager

2.1.2 Dashlane

It is virtually a more complete and more expensive password manager which provides access
to web passwords, works well on major platforms, and syncs data across all devices. The
coolest feature is that it allows you to change all your passwords with one click. The
application takes care of generating the combinations and accessing your accounts online.

2.1.3 LastPass

It is one of the most used password manager because it works on almost any browser and any
platform. Information is stored on LastPass servers, encrypted with AES – 256. It’s free, but
synchronization with mobile devices is restricted to premium subscribers. There are couple of
challenges faced when using the LastPass for Business software to manage usernames and
passwords. Firstly, one has to spend a portion of the budget to get access to the software.
Secondly, its password is not easy to create because it has to meet complex criteria of having
a mix of numbers, alphabets, specials characters and at-least 14 characters long. If one forget
it and reset, then have to create a new one which is not the same as old one. Finally, if once
forgotten the LastPast password as well as my email password, it won't be able to reset it on
my own because I can't access support's reset email.

2.1.4 1Password

It allows you to generate easily memorable and typed passwords, saves two-step
authentication codes, have good integration with iOS. It has well-crafted interface as well.

2.2 Technology to facilitate password management

Apart from implementing a security policy and guidelines to enforce good password
management, some of the technologies highlighted below offer effective and user-friendly
password management.

2.2.1 Public Key Infrastructure

Public Key Infrastructure (PKI) is a technology that uses mathematical algorithms and
processes to facilitate secure transactions by providing data confidentiality, data integrity and
authentication. PKI makes use of digital certificates to provide proof of identity for the
individual. A digital certificate is a kind of digital document that binds a public key to a
person for authentication, rather like a personal identity card. A trusted Certificate Authority
(CA) creates the certificate and digitally signs it using the CA’s private key, thereby
authenticating the identity of the requestor. A person can use his or her certificate for
authentication with different applications, and the applications then check the user’s identity
by verifying the digital signature with the issuing CA. PKI is particularly useful for user
authentication in on-line transaction and public applications, because there is no advance pre-
registration process required for each application. Users only need to apply for a certificate
from a trusted CA to authenticate themselves with various applications.

Deploying PKI requires some worth noting security considerations as follows:

The private key must be protected and stored in a safe place, such as in a security token or
smart card secured by a PIN. Relevant password restrictions should be imposed on the PIN of
the security token / smart card to prevent unauthorised access to the private key inside. There
should be proper procedures in place to handle key life-cycle management, issuing and
revoking of certificates, storing and retrieving certificates. For private key backup, the key
must be copied and stored in an encrypted form and protected at a level not lower than that of
the original private key. As not all applications support the use of PKI, there may be
interoperability issues.

2.2.2 Single sign-on

With the use of Single Sign-On technology, users are able to identify themselves with the
authentication server only once to access a variety of applications, including both internal and
external systems. Users can enjoy the benefit of choosing one password to access multiple
applications, instead of memorising many different passwords. However, compromise of one
authentication event could result in the compromise of all resources that the user has access
rights to.

Implementing SSO requires the following worth noting security considerations:

As one single authentication controls access to all resources, it is important that the
authentication process is secure enough to protect those resources. This protection should
satisfy the requirements of the most critical application. The single authentication process
should not be weaker than the original authentication method used by the various
applications, otherwise, the result is a downgrade in security level. A second factor of
authentication, such as a security token and smart card, can be used to strengthen the
authentication process. Relevant password restrictions, such as the minimum password
length, the password complexity, the maximum number of trial attempts and the minimum
time for renewal, and so on, should be imposed. As the authentication server may become an
attractive target for attack, it should be well protected so that intruders cannot access
authentication information which could then be used for unauthorised access to all the
systems. Auditing and logging functions should be used to facilitate the detection and tracing
of suspicious unsuccessful login attempts. Encryption should be used to protect against
authentication credentials transmitted across the network.

2.2.3 One-Time-Password token

Another technology that may be used to facilitate password management is the one-time
password token. Users authenticate themselves with two unique factors, something they have
(the token) and something they know (the PIN). Users do not need to choose or memorise
passwords. The token will generate a unique, one-time-use password for each authentication
process, based on the PIN and other factors, granting access to protected resources.

The following are some considerations when implementing one-time-password tokens:

A token is needed for each user of the authentication process, which implies additional
investment. Users must carry the token at all times, and they will not be able to access the
system if they lose the token or forget to bring it with them. Unlike software based access
control systems, which only require a password reset, users may not be able to use the system
for hours or days if the token is lost. Users should be aware of the physical security of the
token and ensure that the token is properly protected at all times. Most of the current one-
time-password authentication schemes only authenticate the initial connection. Connections
thereafter are assumed to be authenticated, and these connections are susceptible to being
hijacked. Security tokens may not support all applications or servers.

2.3 Password manager with personal server

Password managers utilize a master password or a security token to encrypt registered login
information. Consider master password, he security of registered login information cannot be
maintained once the master password has been cracked. Namely, all stored login information
are revealed by password-cracking attacks (e.g., guessing, dictionary, brute force). Therefore,
the master password should be strong in spite of difficulty of forcing users to set the strong
passwords voluntarily. Consider the case of using a security token. In this case, the password-
cracking attacks to vulnerable passwords can be prevented because the authentication using a
security token is based on not proof-of-password but proof of-possession of the token. In
addition, the security hole attack can be prevented by separating a decryption key and the
encrypted login information physically. However, in this case, users must always have a
security token when they use a password manager. Additionally, the users should keep the
security token separate from the PC, to avoid the steal of the security token together with the
PC. Unfortunately, they tend to leave the security token around the PC for the usability.

2.4 The Password Manager with a Smartphone

It is difficult to rigorously separate encrypted data (registered login information) and a

decryption key (a security token) in the conventional password managers. This seems to be a
reason why it is difficult to achieve both the security and the usability. However, by
incorporating the personal server into this scheme, the deployability and the security have
become worse.

2.4.1 MBCCO scheme

In the MBCCO scheme, if the PC is stolen, a thief cannot obtain the login information
because the login information is not stored in the PC. On the other hand, if the smartphone is
stolen, the thief must break the encryption of the login information under the secret key. This
secret key is generated by the PC and is independent of the entire user’s information. Hence it
becomes difficult for the thief to break the encryption. Therefore, the MBCCO scheme can
achieve the security equal to the case of using a security token. On the other hand, the
MBCCO scheme avoids to not having a security token in the use of the password manager.
This is because most people tend to always have their smartphone. For the same reason,
leaving the security token around the PC also can be avoided. But some authors however
noted some remaining problems that the MBCCO scheme is unavailable from the paired
smartphone, and moreover, all login information cannot be recovered if the paired
smartphone is lost.

2.5 Proposal for Safepass password manager

SAFEPASS focused on creating a self-contained application that can be hosted semi

independently from the backend. With a self-contained application, refers to a standalone
web application in contrast to a multi-page website that is completely controlled by the
server. The backend is not aware about what is being sent to it, which is an intentional design
choice on our part. The idea is that no one, not even the people hosting the SAFEPASS server
instance, should have access to the sensitive information. This design principle helps making
SAFEPASS trustworthy. A self-contained application enables us as developers to swap out
the backend API without affecting the frontend. The web client application maintains its own
state (through the Flux architecture), allowing for a simple, stateless server thus allowing it to
offer offline-mode. Flux applications have four major parts: the dispatcher, the stores, actions
and the views which can be React components. Authentication systems used are OAuth2
protocol and sessions based authentication with cookies. In token based authentication the
client manages the token and can decide where to store it.

2.5.1 OAuth 2.0 client authentication and authorization

It is a compact URL-safe means of representing claims to be transferred between two parties.
The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web
Signature (JWS). The protocol uses basic HTTP authentication for authenticating the user,
and issues a JWT token that can be used in subsequent requests to access resources on the
server.

2.5.2 Session based authentication

Session based authentication on the other hand is managed by the server. In contrast to token
based authentication, the server keeps track of the client state which results in more memory
usage on the server (affects scalability). Token based authentication is therefore popular for
API-servers which do not require any state-tracking. Because the SAFEPASS client is a self-
contained application that manages its own internal state, and because both have more or less
the same security risks, using a token based authentication is more beneficial in this case.
SAFEPASS authenticates the client SAFEPASS has a minimal backend (as the heavy lifting
is done at the client-side) based on the ASP.NET framework 16. ASP.NET Core supports
dependency injection out-of-the-box which makes the backend dependencies reusable,
testable and readable as well as middle wares to control the HTTP pipeline. IdentityServer4 is
an authentication middleware that provides OAuth2 grants using access tokens. When
authenticating, the client must issue access token through the authentication endpoint
provided by the ASP.NET controller, and not directly to Identity Server.

This proposal lacks in following function,

 Administrative Tools: Since SAFEPASS is intended to be available as a self-hosted

service, a few administrative tools would be useful for local setups. At the very least
an administrator should be able to manage users. Other implementations, such as
statistics and metrics, storage usage inspection and server wide settings are possible
features that could be implemented as administrative tools.
 Browser Extension: Many password managers have support for browser extensions
to inject credentials into forms on the website. Essentially, this is a feature which most
users expect from a modern password manager.
 Password Changer: A password changer is an emergency feature that should be
considered implemented.
 Password recovery option is not implemented in this application.
2.6 Cloud password manager using privacy preserved biometrics

 A password manager is used to address this security-convenience dilemma by storing

and retrieving multiple existing passwords using one master password.
 It centralizes the passwords storage and shifts the risk of password leakage from
distributed services providers to a software or token authenticated by a single master
password.
 Biometrics could be used as a second factor for authentication by verifying the
ownership of the master password.
 We propose a cloud password manager scheme exploiting privacy enhanced
biometrics.
 The proposed password manager scheme relies on a cloud service to synchronize all
local password manager clients in an encrypted form.
 Several methods to implement the password manager such as storing the plain text
password , using a cipher to encrypt passwords by means of a master key , using
biometrics authentication or using two-factor leakage is unknown.
 Other hardware and biometric based password products, such as APC touch biometric
pod can offer more convenience but they are token based and not suitable for cloud
identify authentication.
 A user needs only to login to the cloud password manager using one password (called
the master key) and their freshly captured biometric data before the authentication for
a web service is automatically performed by the cloud password manager.

2.6.1 Authentication to the Cloud password manager

Before downloading the actual password records in the client end, the user shall prompt for
identity authentication. To achieve this goal, a virtual service with virtual record is
implemented.

2.6.2 Synchronization

The records in the client end are updated to the corresponding records in the cloud server end
by following identity authentication process. The synchronized data in the client database can
be decrypted by the master key to obtain the password vault element.
2.7 Multi-agent Integrated password management

Agents are computer systems with two important capabilities. Firstly, an autonomous action
that decides what needs to be done to satisfy design objectives. Secondly, communicating
with other agents by engaging in the analogues of social activity such as cooperation,
coordination, and negotiation. Each agent has its specialty to complete the tasks. There are
several characteristics of a multiagent system. First, each agent controls its task, and there is
no global system control. Second, data is distributed whereby each agent will need to
communicate with each other to obtain resources. Third, each process is independent of each
other. Last but not least, each multi-agent system is suitable to handle complex problems by
using modularity.

2.7.1 Mobile Agent

A mobile agent is an arrangement of software and data which can move from one system to
another system separately in a distributed network. It is also a software process capable of
roaming wide area networks (WANs). It is an agent because it is autonomous and cooperates,
although differently to collaborative agents. An agent does not need to be stationary, but in
certain applications, by avoiding static agents, it is in favour of their mobile counterparts. By
using this agent, several benefits can be gained. For example, reduced communication costs,
limited local resources, easier coordination, asynchronous computing, and flexible distributed
computing architecture.

2.7.2 Methodology

This paper proposes two agents directly involved in the security of user data which are
application agent and crypto agent. Application agent acts as third-party software in between
the password management application and the crypto agent during the process of encryption
and decryption. The communication between these two agents may reduce the burden of the
device on the user side in terms of processing power to process the encryption and
decryption. Therefore, the aim of this proposal is to design and develop a multi-agent
integrated password management application using encryption technique by implementing
application agent and crypto agent. In the Android platform, two main components which are
the graphical user interface (GUI) and the application agent which reside in the JADE
platform. The GUI acts an interface for the database, user and the application agent. The GUI
reads and writes from the database and displays it on the application screen. The GUI
retrieves the application agent whenever an encryption process is needed. When called by the
GUI, the application agent receives related data. The application agent’s main function is to
act as an interface between the Android platform and the Java Virtual Machine (JVM). The
agent sends data to the crypto agent in JVM using agent communication language (ACL)
message which is a method of communication between agents. The main function of the
crypto agent is to encrypt or decrypt data and send it back to the application agent. MIPM
was developed and used only for storing accounts for social media application using
encryption methods. This project was developed on the Android platform and Java Agent
Development Environment (JADE).
 CHAPTER 3
DESIGN OF PROPOSED WORK

3.1 Overall Architecture

A master account which has master username and strong master password will be created by
the user. This master password will in turn undergo a strong hash technique which will
output a 4 digit key called as lucky number. This lucky number is given to the user. This is
the only 4 digit key, which the user has to remember while entering to other websites. This
factor makes the system user friendly. For the First time when the user login to any website,
the password he enters, will be fetched only when the user gives save option in the wrapper
that appears. The Password will be fetched using password field detection technique. The
fetched password will undergo encryption and stored in cloud. For every further logins into
the particular account the users makes, the password field detection technique detects the
password field and a wrapper will pop up which asks user to enter the 4 digit pin. This pin is
validated and the password for the particular website is retrieved from the storage and given
to the user or filled automatically in the password field. And some mechanisms will be
provided to update passwords and recovery measures will be given when the user lost the
security pin.

Fig 3.1: Overall architecture diagram

3.2 Decomposition of Modules
 Module-I: Creating Master Account for the user.
 Module-II: Password encryption module and storing passwords
 Module-III: Authentication of user account and Retrieving passwords

3.2.1 Module 1 – Creating Master Account for a user

This is the starting module of the proposed system. This module includes creating a master
account and username, password of specified sites.

Fig 3.2: Module 1 – Creating Master Account

3.2.1.1 URL categorization based user context

Fig 3.3: URL Categorization

The user needs to register to the master account with some of the details like email id, mobile
number, master username and master password. This master password undergoes own
encryption algorithm which outputs a four digit pin number. This generated four digit pin is
given to the user, which will be used as a password for further logins. After the registration
process, the user needs to only remember the four digit pin number (making the system
easier). Based on URL type, authentication decision is made.

Along with these master account details, the IP address of the registering system is also
saved. Based on the IP address of the device, the authentication decision is made. If it is a
device other than the registered one, the user has to enter the master pin as first level access
and OTP verification as second level.

The logic behind four digit pin generation is explained in the below steps:

 The Master password’s alternate position letters are taken.

 The ASCII values of those letters are retrieved.
 Each ASCII value is added again and again until it becomes a single digit.
 Now all those ASCII values are combined and reversed to get a 4 digit pin.

3.2.2 Module 2 – Storing passwords for specified sites

In this module, the user would store the passwords for first time in his account. When the
user enters a password field, the password manager fetches the URL, username and
password. Now the password is encrypted and stored in cloud. The encryption used here is
MD5 encryption. Only the encrypted site password is stored in database and hence the
original passwords are hidden.

The user’s profile and saved logins for different sites are also managed to show to the user in
need. For each user separate session is maintained so that in the same device any number of
users can use their profile.

MD5 produces an output of 128-bit hash value. The working of MD5 encryption is depicted
here with following steps:

 Padding means adding extra bits to the original message. So in MD5 original
message is padded such that its length in bits is congruent to 448 modulo 512.
Padding is done such that the total bits are 64 less being a multiple of 512 bits
length.
 Padding is done even if the length of the original message is already congruent to
448 modulo 512. In padding bits, the only first bit is 1 and the rest of the bits are
0.
 After padding, 64 bits are inserted at the end which is used to record the length of
the original input. Modulo 2^64. At this point, the resulting message has a length
multiple of 512 bits.
 A four-word buffer (A, B, C, D) is used to compute the values for the message
digest. Here A, B, C, D is 32- bit registers and are initialized in the following way.

Word A 01 23 45 67
Word B 89 Ab Cd Ef
Word C Fe Dc Ba 98
Word D 76 54 32 10

Table 3.1 MD Buffer

 MD5 uses the auxiliary functions which take the input as three 32-bit numbers and
produces a 32-bit output. These functions use logical operators like OR, XOR,
NOR.

F(X,Y,Z) XY v not (X)Z

G(X,Y,Z) XZ v Y not (Z)
H(X,Y,Z) X xor Y xor Z
I(X,Y,Z) Y xor (X v not (Z))

Table 3.2 Processing message in 16-word block

 The content of four buffers is mixed with the input using this auxiliary buffer and
16 rounds are performed using 16 basic operations.
 After all, rounds have performed the buffer A, B, C, D contains the MD5 output
starting with lower bit A and ending with higher bit D.
Input: Svbp1999
Output: 7a8417edb1f239c52c074b3c10609c26
 Fig 3.4: Module 2 – Storing Passwords

3.2.3 Module 3 – Authentication of user account and retrieving passwords

This is the main module in which password is retrieved without remembering it. When the
user enters a password field, the password manager opens the wrapper. The user has to enter
his master username and lucky number which is a security check for retrieving passwords.
Based on the user context and device in which the account is logged in, the password
manager provides the multifactor authentication. Factors used for authentication are OTP
verification via SMS and email. Now the password manager auto fills the password field
based on the URL and username. System retrieves the IP address of which the account is
logged. This information is later used for providing next level authentication. Whenever the
user uses a new device for logging in into the site, the user will be authenticated via OTP.

Fig 3.5: Module 3 – Retrieving passwords

This application is a hybrid application and hence the design of the application is maintained
as per the device like android or desktop.
The Hostname of the device is identified while entering the master password and hence the
second factor authentication can be SMS or email verification. Now the password is in
encrypted form in the cloud. The decryption is done in the local device and then the original
password is retrieved to enter the application.

3.3 Detailed Description of authentication levels

When the user retrieves password, the security measures are implemented based on several
categorization of devices. The first categorization is based on IP address – if the user signed
in the device in which he is already registered then the device becomes user’s personal device
and if the user signed in the new device then it is a third-party device. The second
categorization is based on type of device – desktop or amdroid. For every categorization
different authentication levels are implemented. The different levels are:

 Level 1 – Master Pin verification

 Level 2 – OTP verification
 Level 3 – Google Authenticator

3.3.1 Categorization based on IP address

Fig 3.6: State Chart Diagram for categorization based on IP address

In this categorization, if the user signed in the personal device, Level 1 authentication is
implemented which is the Master PIN verification. The user enters the 4 digit PIN and after
successful verification the site’s original password is retrieved and the desired site is opened.
Only level 1 authentication is tested here. If it is a third party device after level 1
authentication other authentication levels are also tested based on second type of
categorization – which is the type of device.
3.3.2 Categorization based on type of device

Fig 3.7: State Chart Diagram for categorization based on type of device

In this categorization, the type of device – android or desktop is determined. If the user
signed in a desktop then level 1 master PIN verification is implemented and Google
authenticator generating TOTP is tested as second level. The Google authenticator will
generate a 30 second TOTP when the user scans the QR code generated in the webpage. If
the user enters the valid OTP the site’s original password is retrieved and the desired site is
opened. If the user signed in android device level 1 master PIN verification is done and OTP
verification is implemented as second level. If valid OTP is entered then the site’s original
password is retrieved and the desired site is opened. This categorization is done by using
browser agent on which the device is signed.
 CHAPTER 4
IMPLEMENTATION ENVIRONMENT

4.1 Software & Hardware

Requirements Hardware Requirements:

Ram: 2 GB minimum

Processor: 64 bit, 1.5 GHz minimum per core

Hard Disk: 10GB

Software Requirements:

Operating System: Windows 7, 8 or Higher Version

Front End: PHP, JavaScript, HTML, CSS

Back End: MySQL database.

4.2 PHP

Rasmus Lerdorf unleashed the first version of PHP way back in 1994. PHP is a must for
students and working professionals to become a great Software Engineer specially when they
are working in Web Development Domain. PHP is a recursive acronym for "PHP: Hypertext
Preprocessor".

It is a programming language that allows web developers to create dynamic content that
interacts with databases. PHP is a server side scripting language that is embedded in HTML.
It is used to manage dynamic content, databases, session tracking, even build entire e-
commerce sites. It is integrated with a number of popular databases, including MySQL,
PostgreSQL, Oracle, Sybase, Informix, and Microsoft SQL Server. PHP is pleasingly zippy
in its execution, especially when compiled as an Apache module on the Unix side. The
MySQL server, once started, executes even very complex queries with huge result sets in
record-setting time.

In our project, PHP plays a major role for implementing business logic like encrypting
passwords, inserting and retrieving login credentials in database. The IP address of the
system is detected by using PHP and the categorization of user’s personal or third party
device is carried out.

Some of those snippets are shared here.

Fig 4.1 Password encryption and insertion in database using PHP

Another main part done in PHP is master password encryption and Google authenticator API
implementation. Google Authenticator implementation is also shown below.

Fig 4.2 Implementation of Google Authenticator API in PHP

4.3 JavaScript

JavaScript (JS) is a lightweight, interpreted, or just-in-time compiled programming language

with first-class functions. While it is most well-known as the scripting language for Web
pages, many non-browser environments also use it, such as Node.js, Apache
CouchDB and Adobe Acrobat. JavaScript is a prototype-based, multi-paradigm, single-
threaded, dynamic language, supporting object-oriented, imperative, and declarative (e.g.
functional programming) styles.
It is designed for creating network-centric applications. It is complimentary to and integrated
with Java. It is very easy to implement because it is integrated with HTML. It is open and
cross-platform.

JavaScript plays an important role in validating inputs at front-end itself which is called
Client-Side validation. It is used to verify any user input before submitting it to the server.

In our project, JavaScript helps in scripting the content of login dashboard. The main part of
our project which is the detection of client using android or desktop is identified using
JavaScript. The browser information is used to detect the device – android or desktop.

Fig 4.3 JavaScript to detect android or desktop

The level of authentications and OTP verification is also implemented using JavaScript. The
content for sending OTP to the desired user and verification of that OTP are all done using
JavaScript.

Fig 4.4 JavaScript for sending OTP

4.4 PHTML

Files with the .phtml extension are most commonly associated with PHP Web pages. The
PHTML files contain PHP code that is parsed by a PHP engine. This allows the Web server
to generate dynamic HTML that is displayed in a Web browser. The PHTML files are often
used to access databases. The pages containing the PHTML code are usually displayed with
the .php page extension.

Web page that contains PHP code; parsed by a PHP engine on the Web server, which
dynamically generates HTML; often used for database access, such as retrieving data from a
MySQL database; can be run using Apache or Windows Server with the PHP engine
installed.

In our project, the front end which is the client page is implemented using PHTML. All that
is displayed in the website are using ordinary HTML tags. The index page, login page, user
registration page and dashboard are all displayed using PHTML.

Fig 4.5 User registration page using phtml

4.5 CSS

CSS is used to control the style of a web document in a simple and easy way.
CSS is the acronym for "Cascading Style Sheet". CSS handles the look and feel part of a
web page. Using CSS, we can control the color of the text, the style of fonts, the spacing
between paragraphs, how columns are sized and laid out, what background images or colors
are used, layout designs, variations in display for different devices and screen sizes as well
as a variety of other effects.

We can write CSS once and then reuse same sheet in multiple HTML pages. We can define
a style for each HTML element and apply it to as many Web pages as needed. To make a
global change, simply change the style, and all elements in all the web pages will be updated
automatically. CSS has a much wider array of attributes than HTML, so we can give a far
better look to our HTML page in comparison to HTML attributes. Style sheets allow content
to be optimized for more than one type of device. By using the same HTML document,
different versions of a website can be presented for handheld devices such as PDAs and cell
phones or for printing.

In our project, unique styles for every client page are added. One example is for all
authentications like master password verification, OTP verification and Google
authenticator an alert like box is rendered in webpage which is called a small modal page.
Style for such small modal pages is implemented using CSS.

Fig 4.6 Small Modal Style using CSS

4.6 MySQL

MySQL is the most popular Open Source Relational SQL Database Management System.
MySQL is one of the best RDBMS being used for developing various web-based software
applications. MySQL is developed, marketed and supported by MySQL AB, which is a
Swedish company.

MySQL is released under an open-source license. MySQL is a very powerful program in its
own right. It handles a large subset of the functionality of the most expensive and powerful
database packages. MySQL uses a standard form of the well-known SQL data language.
MySQL works on many operating systems and with many languages including PHP, PERL,
C, C++, JAVA, etc. MySQL works very quickly and works well even with large data sets.
MySQL is very friendly to PHP, the most appreciated language for web development.

MySQL supports large databases, up to 50 million rows or more in a table. The default file
size limit for a table is 4GB, but you can increase this (if your operating system can handle it)
to a theoretical limit of 8 million terabytes (TB). MySQL is customizable. The open-source
GPL license allows programmers to modify the MySQL software to fit their own specific
environments.

In Our Project, we have 3 tables in our database. The tables are adminusers, savedsites and
websites. All these tables along with structure are shown here.

Fig 4.7 Table for adminusers

 Fig 4.8 Table for savedsites

Fig 4.9 Table for websites

The overall structure of our database is represented in the following ER diagram.

Fig 4.10 ER diagram of password manager database

 CHAPTER 5
RESULT DISCUSSION

5.1 Input/ Output Snapshots of Common registration

Fig 5.1 Registration Form

Fig 5.2 Master Lock Pin generation after registration

Fig 5.3 Account Login Form

Fig 5.4 Visiting Facebook

 Fig 5.5 Profile

Fig 5.6 Saving Facebook credentials first time

5.2 Input/ Output Snapshots of password retrieval methods

Level 1 – Master Pin verification

Level 2 – OTP verification

Level 3 – Google Authenticator

Implementation Details

Third Party Device

Applications Personal Device
Android Desktop

Level 1 Level 1
Facebook Level 1
Level 2 Level 3

Level 1 Level 1
GoDaddy Level 1
Level 2 Level 3

Table 5.1 Level of authentication based on device categorization

Facebook Application

Fig 5.7 Personal device

 Fig 5.8 Level 1 – personal device

Fig 5.9 Facebook Opened – personal device

Fig 5.10 Third Party device – Android
Fig 5.11 Level 1 – android
Fig 5.12 Level 2 – android
Fig 5.13 Facebook opened – android
GoDaddy Application

Fig 5.14 Third Party Device – Desktop

Fig 5.15 Level 1 – desktop

 Fig 5.16 Level 3 – desktop

Fig 5.17 Google authenticator TOTP

 Fig 5.18 GoDaddy opened – desktop

5.3 Limitatons in Base Paper’s SplitPass Password Manager

 Impersonating attack – There is a possiblity of attacker steals the device and pretends
to be the user.
 User Experience Issue – There is lot of installation process to be held for signing in to
user’s account.

5.4 Limitations in LastPass Password manager

 Security - The LastPass password manager does not have any kind of security
measures to retrieve password.

5.5 How we overcome in our Password Manager

 Impersonating attack – Since we have provided the Master PIN verification there is
no threat even if our device is stolen. The User has to enter the master password to
retrieve information.
 User Experience Issue – There is no need of installation techniques as our password
manager is a website to be typed in any device.
 Security - We have multi factor authentication in our password manager which takes
care of security issues.
LastPass - Godaddy Application

Fig 5.19 Installing LastPass as Chrome extension

Fig 5.20 Saving Godaddy login credentials

 Fig 5.21 Signing in to Godaddy application

In the above screenshot, there is no security. Any user who have this device can open this
account and get the login credentials for Godaddy account.

Fig 5.22 Launching Godaddy Application

In the above screenshots, The application is opened and the user can type in the saved
credentials to go for his godaddy account.
5.6 Performance Analysis

The performance of our password manager is analysed by comparing all existing

password managers. The summary is presented in the below table.

Our Password
Features Others
Manager
Customizable encryption algorithm Yes Yes
Secure Master Password Yes No
Browser Compatibility Yes No
Breach alert Yes Yes
Data leaks No No
External third-party storage Yes No
Password changer Yes Yes
Privacy respecting Yes Yes
Beginner friendly Yes Yes

Table 5.2 Performance analysis

 CHAPTER 6
CONCLUSION AND FUTURE ENHANCEMENT

Password manager using multifactor authentication is a secure, usable and convenient

password manager that combines a clever design paired with modern technologies. It is
developed with the intent to resist the most common attack models for password managers.
Even with the number of password managers already out there, our analysis suggest that
existing password managers do not provide the desired level of usability as well as
sufficient trustworthiness and security. A backbone based on the JavaScript development
environments allows the solution to offer usability and security at its core by reusing well-
known design components. It offers a self-contained application that can be hosted semi-
independently from the backend and that works as a stand-alone application, in contrast to
more commonly used multipage websites that are completely controlled by the server. The
average user can appreciate a clean, sleek and intuitive user interface with notable features
such as customizable categories like authentication levels based on risk levels as user can
increase the security level as needed. Based on the applications, personal device, third
party device. Levels has been categorized which is more conveniently used for personal
devices and also secured for third party devices. The third party devices are categorized
into two parts such as android based and desktop based application. The security levels
depend upon the type of device used by the user. Level 1 contains master pin verification,
Level 2 contains OTP verification and Level 3 contains Google Authenticator.

The final part of the objective of the project is providing an easy and secured password
manager with multifactor authentication which can be easily understand by layman.
Meanwhile this password manager is secured and trustworthy for every user when
compared with other password manager as they are complicated for layman. This results in
performance gains and a highly secured datasets. The current project work focuses on
minimal approach of URL categorization. In future the same URL categorization can be
done in generous. The device identification can be done broader in different format.
 REFERENCES

[1] Bian Yang, Huiguang Chu, Guoqiang Li, Slobodan Petrovic, Christoph Busch
(2014), “Cloud Password Manager Using Privacy-Preserved Biometrics”, IEEE International
Conference on Cloud Engineering, DOI : 10.1109, ISBN : 978-1-4799-3766-0.

[2] Bui FM, Hatzinakos D (2005). “A receiver-based variable-size burst equalization

strategy for spectrally efficient wireless communications”. IEEE Transactions on Signal
Processing; 53(11): 4304–4314.

[3] Carlos Luevanos, John Elizarraras, Khai Hirschi, and Jyh-haw Yeh (Jan.2017),
“Analysis on the Security and Use of Password Managers”, in 18th International Conference
on Parallel and Distributed Computing, Application and Technologies, DOI : 10.1109,.

[4] Damousis, IG, Tzovaras,D and Bekiaris E (2008), “Unobtrusive multimodal biometric
authentication: the HUMABIO project concept”, EURASIP Journal of Advances in
Signal Processing, 2008: 1–11.

[5] Hakbilen, O., Perinparajan, P., Eikeland, M. and Ulltveit-Moe, N (Jan.2018),

“SAFEPASS – Presenting a Convenient, Portable and Secure Password Manager”, In
Proceedings of the 4th International Conference on Information Systems Security and
Privacy, SCITEPRESS, DOI: 10.5220/0006603102920303, ISBN: 978-989-758-282-0,
pp.292-303.

[6] Liu YT, Du D, Xia YB et al (Jan. 2018), “SplitPass: A mutually distrusting two-party
password manager”, Journal of Computer Science and Technology, DOI 10.1007/s11390-
018-1810-y, ISSN : 11390-018-1810, pp.98-115.

[7] Masayuki Fukumitsu, Shingo Hasegawa, Jun-ya Iwazaki, Masao Sakai, Daiki
Takahashi (2016), “A proposal of a password manager satisfying security and usability by
using the secret sharing and a personal server‖”, IEEE 30th International Conference on
Advanced Information Networking and Applications (AINA).

[8] Norkhushaini Awang, Nurul Hidayah Ahmad Zukri, Nor Aimuni Md Rashid, Zuhri
Arafah Zulkifli and Nor Afifah Mohd Nazri (October. 2017), “Multi
agent integrated password management (MIPM) application secured with encryption‖”, The
2nd International Conference on Applied Science and Technology, ISSN : 978-0-7354-1573-
7.

[9] Wang. R, Chen. S, Wang. X (2012), “Signing me onto your accounts through Facebook
and Google: a traffic-guided security study of commercially deployed single-sign-on web
services,” IEEE Symposium on Security and Privacy, pp. 365-379.
[10] Yang. B, Hartung. D, Simoens. K, Busch. C (2010), “Dynamic random projection for
biometric template protection,” Proc of the 4th IEEE International Conference on
Biometrics: Theory, applications and systems (BTAS'10).
[11] Zhiwei Li, Warren He, Devdatta Akhawe and Dawn Song (August 2014), “The
Emperor’s New Password Manager Security Analysis of Web-based Password Managers” in
proceedings of 23rd USENIX Security Symposium, ISBN: 978-1-931971-15-7.
[12] Zhou. X and Tang. X (2011), “Research and implementation of RSA algorithm for
encryption and decryption”, International Forum on Strategic Technology (IFOST), 6(2), pp.
1118-1121.