The Ginger: Another Spice to Hinder Attacks on Password Files

Francesco Buccafurri

, Vincenzo De Angelis

and Sara Lazzaro

Department of Information Engineering, Infrastructure and Sustainable Energy (DIIES),

Universit

a Mediterranea di Reggio Calabria, Via dell’Universit

a 25, 89122 Reggio Calabria, Italy

Keywords:

Passwords, Authentication, Salt, Dictionary Attacks.

Abstract:

One of the threats to password-based authentication is that the attacker is able to steal the password ﬁle from the

server. Despite the fact that, thanks to the currently adopted security mechanisms such as salt, pepper, and key

derivation functions, it is very hard for the attacker to reverse the password ﬁle, dedicated hardware is available

that can make this attack feasible. Therefore, there is still a need to better counter password-ﬁle reversing. In

this paper, we propose a new mechanism, called ginger, which can be combined with the above mechanisms,

to increase the robustness of password-based authentication against password-ﬁle reversing. Unlike pepper

and salt, ginger is stored client-side, and enables a stateful authentication process. A careful security analysis

shows the beneﬁts of the proposed innovation.

1 INTRODUCTION

Password-based authentication is the most widely

used authentication method for web applications.

However, over the years, several studies in the liter-

ature have shown that it suffers from many security

problems (Bonneau et al., 2012). The main issue lies

in how users choose their passwords. Ideally, pass-

words should be long random strings so that they can-

not be easily guessed. However, since humans have

poor memory capacity, they tend to choose short and

mnemonic passwords (NordPass, 2022). Among oth-

ers, an important factor threatening password-based

authentication is represented by the compromises of

password ﬁles stored server-side. As a matter of fact,

over the past decades, several compromises have oc-

curred thus leading to the leakage of billions of lo-

gin credentials (Shadow, 2022). Unfortunately, these

attacks do not concern compromised websites alone

but might increase the risk of account takeover at

other websites. This is due to password reuse, in-

duced by the proliferation of accounts per user (25

accounts on average (Das et al., 2014)). Obviously,

password ﬁles cannot trivially store passwords in the

clear, since a simple server-side compromise would

immediately reveal all the users’ passwords. There-

fore, best-known security practices suggest storing

https://orcid.org/0000-0003-0448-8464

https://orcid.org/0000-0001-9731-3641

https://orcid.org/0000-0002-0846-4980

the hashes of each password combined with a ran-

dom string called salt. This way, the precomputa-

tion of possible password ﬁles (to build the so-called

rainbow tables (Kumar et al., 2013)) is not possi-

ble, and the only possibility for the attacker is to

perform a dictionary-based attack once both pass-

word ﬁle and salt have been stolen from the server.

To further hinder dictionary attacks additional secu-

rity mechanisms, such as pepper (Manber, 1996) and

key derivation functions (Yao and Yin, 2005), can be

adopted with the aim of increasing the time needed

for a dictionary attack. Nevertheless, dictionary at-

tacks are still feasible, since attackers can leverage

dedicated hardware platforms, ranging from tradi-

tional application-speciﬁc integrated circuits (ASICs)

and ﬁeld-programmable gate arrays (FPGAs) to mod-

ern graphic process units (GPUs) and hybrid CPU-

FPGA chips (Zhang et al., 2020). Moreover, dic-

tionary attacks have also become more sophisticated

across the years. Attackers typically build their dic-

tionaries aggregating passwords leaked from past data

breaches and plain-word dictionaries. Then such dic-

tionaries can be virtually extended through mangling

rules (Pasquini et al., 2021) that consist of a series of

transformations that can be applied to a basic dictio-

nary to produce multiple candidate passwords from

each word of the dictionary. Mangling rules are in-

cluded in many popular password-cracking software

such as Hashcat (Jens ’atom’ Steube, Gabriele ’ma-

trix’ Gristina, 2015) and John the Ripper (OpenWall,

166

Buccafurri, F., De Angelis, V. and Lazzaro, S.

The Ginger: Another Spice to Hinder Attacks on Password Files.

DOI: 10.5220/0011576200003318

In Proceedings of the 18th International Conference on Web Information Systems and Technologies (WEBIST 2022), pages 166-173

ISBN: 978-989-758-613-2; ISSN: 2184-3252

1996). The problem is therefore still open.

In this paper, we propose a new mechanism, called

ginger, which can be combined with existing tech-

niques, to make dictionary attacks even more imprac-

tical. The core of our proposal consists in moving

from a stateless authentication mechanism to a state-

ful process. In fact, we require the client to maintain

the state of each authentication. As we will show in

the rest of the paper, there are no technical issues lim-

iting the implementation of our approach. Moreover,

our approach does not require extensive server-side

changes. On the contrary, it can be used in conjunc-

tion with the commonly used approaches for server-

side password storage (salt, pepper, and key deriva-

tion functions), hence strengthening the protection

they offer against dictionary attacks.

Commonly, to minimize the impact of such at-

tacks, it is suggested that users should adopt pass-

word managers or enable multi-factor authentication

(Shadow, 2022). Hence, we also perform a security

comparison between our solution and password man-

ager and OTP-based authentication. As for password

managers, their main vulnerability is that they are a

single-point-of-failure. Indeed, they base their secu-

rity on a mnemonic password (the so-called master

password) which, in principle, might be weak. Hence

the security of the random-generated passwords de-

pends on the security of the master password. On the

other hand, concerning OTP-based mechanisms, they

act as a second factor for the authentication but do

not offer any protection of the password. All these

aspects are carefully analyzed in this paper. In partic-

ular, our analysis shows that our solution outperforms

both the two above-mentioned approaches in terms of

protection offered against a dictionary attack.

This paper is organized as follows. In Section

3, we provide some background notions about the

best security practice to protect password ﬁles stored

server-side. Then, in Section 4, we describe in detail

our proposal. Practical aspects concerning our pro-

posal are discussed in Section 5. In Section 6 we

evaluate the security of our approach. In Section 2,

we investigate the related literature. Finally, in Sec-

tion 7, we draw our conclusions.

2 RELATED WORK

In the last 30 years, several web authentication

schemes have been proposed in the literature. For a

comprehensive overview, the reader can refer to (Bon-

neau et al., 2012). In the paper, the authors also

provide a comparative framework for web authenti-

cation scheme taking into account usability, deploya-

bility, and security aspects. Even with alternative pro-

posals, password-based authentication represents the

predominant approach in real life (Mohammed et al.,

2017; Andrews et al., 2020). As a matter of fact, alter-

native proposals (e.g., biometrics and OTP) are used

as a second factor to passwords. An attempt to replace

textual passwords is represented by graphical pass-

words (Chiasson et al., 2011; Tao, 2006), in which the

users have to remember images in place of text. How-

ever, they lack in usability (Bonneau et al., 2012) and

are not largely adopted.

In the following, we report the main approach to

strengthen password-based authentication.

We start from password managers (Li et al., 2014),

whose description is also provided in Section 6.2.

They store users’ passwords in encrypted form, that

are decrypted locally through a single master pass-

word. The problem with password managers is that

they are vulnerable to data leaks (Last Pass, 2022)

leading to dictionary attacks on the master password.

Recent approaches to solving this problem are pre-

sented in (Shirvanian et al., 2021; Shirvanian et al.,

2017), in which the password manager does not store

the passwords of the user (even in encrypted form),

but they are computed using an oblivious pseudo-

random function password hardening approach that

receives the master password from the user and a se-

cret key from the password manager server.

Another approach allowing the user to authenti-

cate with several web services by remembering just a

password is federated authentication (Boehm et al.,

2008; Lenz and Zwattendorfer, 2015). Therein, a

trusted identity provider attests the identity of the user

and allows them to authenticate with a web service.

From the point of view of the security of the pass-

words, federated authentication suffers from the same

drawback as password manager since the effort of the

attacker moves from compromising the web service

in which the user authenticates to compromising the

identity provider.

In many real-life applications, password-based au-

thentication is often strengthened by introducing an

OTP as a second factor (Buccafurri et al., 2020; Elde-

frawy et al., 2011). However, as highlighted in Sec-

tion 6.3, this second factor is not included in the hash

stored server-side, so it protects the authentication of

the user but does not prevent password discovery.

We conclude this section, by discussing FIDO2

(Chakraborty and Bugiel, 2019), a new password-less

authentication framework. It is based on a challenge-

response mechanism and public-key cryptography.

However, to achieve strong security features, dedi-

cated hardware (e.g., the Yubikey) is needed.

The Ginger: Another Spice to Hinder Attacks on Password Files

167

3 EVOLUTION OF

PASSWORD-BASED

AUTHENTICATION SCHEMES

The basic idea underlying a password-based scheme

is the following. Suppose a user U is registered at

the server S with a password pw

. S locally stores a

function of the password pw

, say F(pw

). When

U wants to authenticate at the server S, they send

S the string pw

(hopefully, coinciding with pw

Then, S simply checks if F(pw

) = F(pw

) to de-

cide whether or not the user is who claims to be.

A naive way for S to handle passwords is to mem-

orize, for each user U, F(pw

) = pw

. Clearly, if the

attacker is able to steal the password ﬁle, then all the

passwords stored at S are exposed in the clear.

This is clearly unacceptable. A step ahead to im-

prove the protocol, is to implement F as a crypto-

graphic hash H. Indeed, H being a one-way function,

the password ﬁle cannot be trivially reversed.

An attacker can still mount an ofﬂine brute force

attack to ﬁnd all possible passwords matching the

hashes stored by S. Such an attack tries all possi-

ble passwords in a systematic way, thus it might re-

quire a signiﬁcant amount of time. However, taking

into account how users choose passwords, a more ef-

ﬁcient attack can be performed. Indeed users tend

to build their passwords by using common words,

possibly combining them in a predictable way. The

list resulting from this combination, including all the

commonly adopted passwords, is named dictionary.

Many tools allowing password cracking based on dic-

tionaries are available (John the Ripper is the most

famous (OpenWall, 1996)) and many dictionaries can

be found on the Internet. Consider that, the above at-

tack, can be also performed by pre-computing all pos-

sible hashes (by obtaining the rainbow tables (Kumar

et al., 2013)), so that passwords can be later found

once the password ﬁle is stolen.

To prevent rainbow-table-based attacks, the server

S, for each user U , should store a string s

(called

salt), chosen at random, along with the hash of the

user’s password computed as H(pw

||s

). This also

makes unlikable password ﬁles stolen from different

servers even in case of password reuse. Observe that,

despite the use of salted hashes, an attacker, able to

steal the password ﬁle and the salts stored in S, is still

able to perform a dictionary attack.

Another mechanism to further increase the at-

tacker’s workload is to include in the hash computa-

tion a short string, say p

, chosen at random for each

user U, called pepper. Thus, the server S, for each

user U, stores the hash computed as H(pw

||s

||p

However, differently from salts, peppers are not lo-

cally saved, but they must be guessed every time users

need to authenticate. Hence, a pepper should be short

enough (a typical choice is 12 bits (Boneh and Shoup,

2020)), so that it can be easily brute-forced by the

server when a user needs to authenticate, without in-

troducing relevant delays. However, a 12-bit string

used as pepper slows down an ofﬂine dictionary attack

by a factor of 4096, thus increasing the time needed

to perform such an attack.

We have also to point out that hash algorithms

are designed to be quickly computed, thus making

the dictionary attack less computationally expensive.

To increase the computational effort of an attacker,

servers might replace hash functions with key deriva-

tion functions, such as PBKDF2 or BCrypt, which are

cryptographic one-way functions whose computation

is much slower than standard hash functions. The ba-

sic idea is the following. Suppose a hash function

takes x milliseconds to be computed on a single in-

put. The adoption of slower functions requiring, for

instance, 10, 000 times the time x, would not signiﬁ-

cantly impact the user experience during the authen-

tication process. However, it would increase the time

to perform a dictionary attack by a factor of 10, 000,

thus increasing the attacker’s workload.

Observe that the effect of key derivation functions

is the same as the pepper. The only difference is that

the delay introduced by the former is deterministic.

To conclude, we want to highlight that there exists

another deﬁnition of pepper that is a string stored in

a more secure and different location with respect to

the password ﬁle. However, this secure location is

not always available and if it is available we might

store directly the password ﬁle on it. Then, we do not

consider this deﬁnition.

4 THE PROPOSED APPROACH

Consider a password-based authentication scheme

adopting both salt and pepper (see Section 3). The

idea of our approach is to strengthen the robustness

of the scheme against off-line dictionary attacks by

adding a new value, called ginger, which is concate-

nated with the password along with the salt and the

pepper, when applying the key derivation function.

However, the idea of the ginger is not a trivial exten-

sion of salt/pepper, because it incorporates a number

of relevant differences, which make the scheme deﬁ-

nitely more robust against off-line dictionary attacks,

as we extensively prove in Section 6.

The main difference is that, while the salt is kept

server-side, the ginger is stored client-side and sent,

on the ﬂy, during the authentication process. This

WEBIST 2022 - 18th International Conference on Web Information Systems and Technologies

168

way, the sole data exﬁltration from the server is not

enough for the attacker to gain success. Moreover, a

refresh mechanism (described in more detail below),

results in an expected considerable reduction of the

time window in which the attacker should success-

fully complete the dictionary attack. A nice feature

of our scheme is that, unlike the pepper, the ginger

does not introduce additional workload server-side,

thus scalability is preserved. Moreover, the adoption

of the ginger does not conﬂict with salt and pepper.

Therefore, all these mechanisms can be combined to

obtain a net increase of security.

From a formal point of view, the ginger introduces

a signiﬁcant change of authentication. Indeed, au-

thentication becomes stateful, while password-based

authentication even with salt and pepper is stateless.

Speciﬁcally, the ginger represents a sort of safe state

from which the client moves towards another safe

state at the next authentication. This involves the fact

that the client must store state information and, thus,

a number of practical implications, which we will dis-

cuss in Section 5. However, as shown in that section,

these implications do not represent actual limitations

or technological obstacles.

Now, we focus on the detailed description of the

proposed protocol. Our protocol involves two actors,

a client C and a server S, and is composed of two

phases, the registration phase and the authentication

phase.

4.1 Registration Phase

This phase starts with the generation by C of a random

value g

, called ginger. Then, C sends it along with

the password pw

to the server S. The value g

stored locally by the client, while the password is not

(as usual, password is required to be mnemonic, even

if robust).

When S receives pw

and g

, it generates a ran-

dom salt s

and a random (in a small domain) pepper

. At this point, it stores h

= F(pw

||s

||p

||g

)

in the password ﬁle, where F is the chosen key deriva-

tion function. The salt s

is stored along with h

while the pepper p

and the ginger g

are not stored

by S.

4.2 Authentication Phase

To authenticate with S, C selects the current ginger g

to use for the current authentication. In addition, it

generates a new ginger ¯g

to use for the next authen-

tication. Both the gingers g

and ¯g

are provided,

along with the password pw

, to server S. Finally, the

client removes the old ginger g

from the local mem-

ory and maintains the new ginger ¯g

At this point, S uses the ginger g

and the pass-

word pw

to compute h

= F(pw

||s

||p

||g

) and

checks that this value is equal to the value of h

cur-

rently stored. To do this, as explained in Section 3,

the server computes h

for all the possible values of

. If the check passes, the authentication performs

successfully. Then, the value of h

is updated with

= F(pw

||s

|| ¯p

|| ¯g

) where ¯p

is a new random

pepper. The gingers g

and ¯g

, and the pepper ¯p

are

discarded by S.

5 PRACTICAL ASPECTS

The protocol presented in Section 4 is discussed at

an abstract level and does not include technological

aspects. As usual for abstract deﬁnitions of authen-

tication schemes, it considers a single client. In this

section, we deal with some practical aspects of the

authentication process, starting by considering that,

nowadays, the user owns multiple devices (e.g., a

smartphone, a tablet, a laptop, a PC).

As our solution is stateful, we have to face the

problem of storing the safe state (i.e., the ginger use-

ful for the next authentication) in all the devices of the

user.

From a conceptual point of view, this is obviously

not an issue, as the devices belong to the same entity

(i.e., the user). However, from a practical point of

view, we have to design a feasible and secure solution

for the device state synchronization.

This can be done by simply considering the fact

that, nowadays, the smartphone can be considered

as an extension of our identity over the digital do-

main. The practical counterpart of this fact is that we

are forced to keep the smartphone always close to us

and/or under control.

Therefore, it is quite natural to consider the smart-

phone as the master storing point of the ginger. This

means that, when the user wants to authenticate with

another device, they must keep the smartphone in

proximity, so that the ginger value can be synchro-

nized manually or by any machine-to-machine pro-

tocol, such as Bluetooth (or other options, discussed

below).

Clearly, possible apps or browser extensions could

be installed in every device to implement the features

of our protocol.

In more detail, we show how the two phases of

Section 4 are instantiated to deal with this scenario.

The Ginger: Another Spice to Hinder Attacks on Password Files

169

5.1 Registration Phase

When U wants to register with S, preliminary, they

the app generates the ginger g

and associates it with

the domain of S.

At this point, g

is transferred from the smart-

phone to the laptop. We consider three options ac-

cording to the capabilities of the smartphone and the

laptop.

Option 1: Typed Ginger. This is the basic and less

usable option but compatible also with legacy devices.

In this case, the ginger is generated on the smartphone

as a string and typed by the user in a registration form.

Option 2: Camera-based Ginger. In this case, the

ginger is encoded on the smartphone app through a

QR code. This QR code is then scanned by the camera

of the laptop and automatically provided to the server.

Option 3: Bluetooth-based Ginger. The last option

is to use a compatible browser on the laptop that re-

ceives the ginger by the app through Bluetooth.

The ginger g

along with the password pw

typed

by the user on the laptop are provided to the server.

At this point, the protocol performs exactly as

in Section 4.1, i.e., S generates a random salt s

and a random pepper p

. Then, it stores h

F(pw

||s

||p

||g

) and the salt s

, and discards the

pepper p

and the ginger g

5.2 Authentication Phase

The authentication phase follows the trace of the reg-

istration phase. First, U selects on the smartphone

app the domain of S to obtain the current ginger g

use for this authentication. In addition, the app gen-

erates a new ginger ¯g

to use for the next authentica-

tion. Both the gingers g

and ¯g

are sent to the laptop

through one of the three options described in Section

5.1. Finally, the app removes the ginger g

from the

smartphone and maintains the new ginger ¯g

At this point, both the gingers are provided along

with the password pw

by the laptop to the server S

through the login form. S uses the ginger g

to com-

pute F(pw

||s

||p

||g

) and checks that this value

is equal to the value of h

currently stored.

If the check passes, the authentication performs

successfully. Then, the value of h

is updated with

= F(pw

||s

|| ¯p

|| ¯g

Due to the statefulness of our protocol, the other

practical aspect we have to face is what happens if

the user loses the current state. This may happen for

example in case of crash of the smartphone. The so-

lution to this problem is trivial. Indeed, in this case,

the user is required to perform the registration phase

again.

6 SECURITY ANALYSIS

Through this section, we evaluate the security of the

proposed approach by comparing it with three state-

of-the-art password-based authentication schemes.

The three approaches we analyze represent the most

widely adopted for authentication in web applications

(Shadow, 2022). The results of our analysis are sum-

marized in Table 1.

6.1 Standard Password-based

Authentication

In the following, we compare our solution with a stan-

dard password-based authentication scheme.

For the latter, we assume that, for each user U,

the server stores F(pw

||s

||p

), along with the salt

in the clear (as described in Section 3). On the

other hand, in our solution, for each user U, the server

stores F(pw

||s

||p

||g

) (along with the salt s

Concerning the password pw

, being it a memo-

rized secret, it is common to assume that it is not a

random string (with high entropy (Taha et al., 2013)).

Therefore, we assume that there is a non-negligible

probability that pw

can be found within the at-

tacker’s dictionary. As for the salt s

, additional

assumptions are not needed for our purposes. As

for the pepper p

and the ginger g

, we consider

∈ {0, 1}

and g

∈ {0, 1}

, denoting with d

and

the length of their bit-strings.

As highlighted in the previous sections, the pepper

is neither stored server-side nor client-side, while the

ginger is stored only client-side. Indeed, the pepper

must be brute-forced by the server at each authentica-

tion, while the ginger is provided by the user to the

server at each authentication. Therefore, for usabil-

ity reasons, the pepper search space should be sufﬁ-

ciently small, while, in principle, no such constraints

are needed for the ginger. Hence, it is fair to assume

that d

 d

Given the above assumptions, we analyze the se-

curity of the two considered protocols in two cases:

(i) against an attacker able to compromise the server

and thus able to steal the list of the hashed passwords

of all the users, (ii) against an attacker as powerful

as the previous one, with the additional capability to

compromise the personal device belonging to a user,

whose password is in the stolen list.

Consider now case (i). Once an attacker has ob-

tained a list of hashed passwords, they can mount a

WEBIST 2022 - 18th International Conference on Web Information Systems and Technologies

170

Table 1: Search space dimension to guess the password.

Approach Server-side

Server and Client-side

(single client)

Our proposal n · d

· d

Worst timeline attack: d

· d

Best timeline attack: d

· d

Standard password-based authentication n · d

· d

Authentication with password manager

(attack on master password)

n · d

· d

OTP-based authentication n · d

· d

dictionary attack to attemp to obtain the memorized

passwords. We denote by n the length of the above

list, and by d

the length of the dictionary used by

the attacker. In case the server implements a stan-

dard password-based authentication scheme, the di-

mension of the search space is given by n · d

· d

. In-

stead, with our approach, the dimension of the search

space is given by n · d

· d

. Thus the computa-

tional effort made by the attacker is increased by a

multiplicative factor d

. Moreover, the ginger dimen-

sion d

can be chosen in such a way that a dictionary

attack is not feasible.

To be fair, we have to point out that, even adopting

a standard password-based authentication scheme, a

dictionary attack may be made unfeasible by forcing

each user to change their password periodically. This,

in principle, limits the time available to the attacker

to carry out the attack. However, in practice, this

is never the case. In fact, when users are forced to

change their passwords, they tend not to change them

radically but to keep the old ones, changing at most a

few characters in a predictable manner (Zhang et al.,

2010). Hence an attacker can easily ﬁnd out the new

password from the old one, just by doing a few online

attempts.

Consider now case (ii). As argued in the previ-

ous case, if our approach is adopted, for an attacker

to be able to succeed in a dictionary attack, it is nec-

essary to brute-force g

for each of the n users in the

list. Alternatively, an attacker could compromise the

personal devices belonging to n users in order to steal

their gingers. However, this is still an unfeasible at-

tack. Hence the probability for an attacker to succeed

in a massive dictionary attack is negligible.

Nevertheless, it is interesting to analyze the secu-

rity of our solution compared to a standard password-

based approach against an attacker at least as pow-

erful as the attacker in case (i), but with the addi-

tional capability of compromising a user’s personal

device. Different from the previous case, here we as-

sume the attacker is interested in discovering a single

user’s password. Hence the search space dimension

for both the approaches is the same as in the previous

case, except for a multiplicative factor n.

Considering the standard password-based ap-

proach, an attacker cannot gain any additional infor-

mation compromising the client and thus the search

space dimension remains unchanged (i.e. d

·d

). On

the contrary, considering our approach, two cases may

occur. Suppose the attacker is able to compromise the

server in the instant T1 and subsequently, the attacker

is able to compromise the user’s personal device at

the instant T 2, where T 1 < T 2. We denote by g

the ginger used server-side at the instant T 1, and by

the ginger stored client-side at the instant T 2. Sup-

pose the ﬁrst user authentication, after T 1, takes place

at the instant T 3. As explained in Section 4, a new

authentication implies that the user’s personal device

stores a new ginger in place of the old one.

If T1 < T 3 < T 2, then the ginger g

stolen by the

attacker at the instant T 2 differs from the ginger g

since the victim has authenticated in between T 1 and

T 2. Hence, the search space dimension for a dictio-

nary attack remains equal to d

· d

If T1 < T 2 < T 3, then the ginger g

stolen by the

attacker at the instant T 2 coincides with the ginger

, since the victim did not authenticate in between

T 1 and T 2. Therefore, the search space dimension

for a dictionary attack is narrowed down to d

· d

Observe that, in this case, we obtain the same search

space dimension the attacker would have by attacking

a standard password-based approach.

The above reasoning holds for T 2 > T 1. However,

it is easy to realize that it applies also when T 1 > T 2

with the same results.

6.2 Authentication with Password

Manager

The second approach we consider to be compared

with our solution is based on password managers.

A password manager is a repository in which users

store, in encrypted form, the passwords of their ac-

counts of different websites. All these passwords

are encrypted and decrypted locally through a master

password. In this way, users have to remember just a

single password to authenticate with all the websites.

Furthermore, modern password managers auto-ﬁll the

The Ginger: Another Spice to Hinder Attacks on Password Files

171

type their passwords, they can be chosen randomly

with high entropy. This makes dictionary attacks in-

effective even if the servers of the websites are com-

promised. However, this is not enough since the effort

of the attacker moves from compromising the website

servers to compromising the password manager. In-

deed, in case the encrypted passwords (stored in the

password manager) are stolen by the attacker, a dic-

tionary attack can be performed on the master pass-

word. We observe that several data breaches on com-

mercial password managers occurred in recent years

(Last Pass, 2022).

Observe that, since the encryptions/decryptions

are performed client-side, typically, in real-life appli-

cations, no salt or pepper mechanism is introduced

to avoid an excessive burden. However, in favor of

security, we assume that they are enabled. Then, by

considering a server-side attack (case (i) of Section

6.1), the size of the search space is the size of the dic-

tionary n · d

· d

. No further advantage is obtained

by compromising also the client (case (ii) of Section

6.1), so that the size of the search space is d

· d

(by considering the compromise of a single client).

Therefore, our approach outperforms the authentica-

tion with password manager in both cases (i) and (ii).

6.3 OTP-based Authentication

Finally, we compare our solution with the OTP-based

authentication. An OTP (One-Time password) is a

secret value used as a second factor during the au-

thentication phase. We consider two versions of OTP,

which are the main ones adopted in real life: SMS-

based or app-based. In the ﬁrst version, the user per-

forms a ﬁrst authentication with the server through a

standard password. The server generates a random

code and sends it to the user through an SMS. The

user provides this code to the server and the authenti-

cation concludes. This second factor proves the own-

ership of a given phone number provided by the user

to the server during a registration phase. In the sec-

ond version, during the registration phase, the server

provides a seed (secret) to the user (typically, through

a QR code that is scanned by the smartphone) to be

stored in a dedicated app. Then, through this seed, the

user generates pseudo-random codes to be provided,

along with the password, during the authentication.

Since the server owns the same seed, the codes can be

veriﬁed.

To be fair, in our comparison, we assume that

along with the OTP, the server applies the standard

salt and pepper approaches as in Section 6.1.

The problem with the OTP, in both versions, is that

it does not protect the password. Indeed, by consid-

ering the case (i) of Section 6.1, if the attacker com-

promises the server, the size of the search space is

again n · d

· d

and does not depend on the OTP it-

self. Even though the attacker is not able to authen-

ticate without the OTP, this represents a critical vul-

nerability since, commonly, passwords are re-used for

different services (Das et al., 2014).

Considering the case (ii) of Section 6.1 (i.e., a

compromise both client and server side), the attacker

is also able to authenticate with the server with the

same effort of case (i) by stealing the OTP. By consid-

ering a compromise of a single client (as in Sections

6.1 and 6.2), the size of the search space is d

· d

To enrich the discussion, we report some attacks

that can be performed client-side to steal the OTP.

Concerning the app-based version, the attacks can

be performed through malware installed on the smart-

phone (as with our solution). On the other hand, re-

garding the SMS-version, several SIM-swapping at-

tacks (Jover, 2020), in which the adversary is able to

obtain the control of the phone number of a victim,

are shown to be effective.

7 CONCLUSIONS

Despite new promising attempts (Chakraborty and

Bugiel, 2019) to introduce password-less authentica-

tion, password-based authentication schemes remain

the most widely used authentication method. How-

ever, the growth of data breaches combined with the

fact that users do not follow the best security practices

when selecting their passwords, makes password-

based authentication vulnerable to dictionary attacks.

To mitigate the problem, traditional solutions con-

sist in the introduction of salts and peppers possibly

combined with key derivation functions. However,

this is not conclusive since by employing dedicated

hardware, it is still possible to discover users’ pass-

words. Then, in this paper we propose a new authen-

tication approach (i.e., the introduction of a ginger)

to strengthen password-based authentication schemes

that can be used in combination with salts and pep-

pers. An important point is that our solution does not

introduce a relevant overhead neither client-side nor

server-side. From the security point of view, we ob-

served, in Section 6, that we outperform state-of-the-

art authentication schemes in case of server-side com-

promise. Furthermore, if the client, along with the

server, is compromised, we obtain an improvement

with respect to traditional schemes in the best case

and we have the same robustness as other schemes

WEBIST 2022 - 18th International Conference on Web Information Systems and Technologies

172

in the worst case. Currently, we are implementing a

prototype of our solution by relying on the Web Blue-

tooth API supported by Google Chrome.

REFERENCES

Andrews, R., Hahn, D. A., and Bardas, A. G. (2020). Mea-

suring the prevalence of the password authentication

vulnerability in ssh. In ICC 2020 - 2020 IEEE Inter-

national Conf. on Communications (ICC), pages 1–7.

Boehm, O., Caumanns, J., Franke, M., and Pfaff, O.

(2008). Federated authentication and authorization:

A case study. In 2008 12th International IEEE En-

terprise Distributed Object Computing Conference,

pages 356–362. IEEE.

Boneh, D. and Shoup, V. (2020). A graduate course in ap-

plied cryptography. Draft 0.5.

Bonneau, J., Herley, C., Oorschot, P. C. v., and Stajano, F.

(2012). The quest to replace passwords: A frame-

work for comparative evaluation of web authentica-

tion schemes. In 2012 IEEE Symposium on Security

and Privacy, pages 553–567.

Buccafurri, F., De Angelis, V., and Nardone, R. (2020). Se-

curing mqtt by blockchain-based otp authentication.

Sensors, 20(7):2002.

Chakraborty, D. and Bugiel, S. (2019). Simﬁdo: Fido2

user authentication with simtpm. In Proceedings of

the 2019 ACM SIGSAC Conference on Computer and

Communications Security, pages 2569–2571.

Chiasson, S., Stobert, E., Forget, A., Biddle, R., and

Van Oorschot, P. C. (2011). Persuasive cued click-

points: Design, implementation, and evaluation of a

knowledge-based authentication mechanism. IEEE

Transactions on Dependable and Secure Computing,

9(2):222–235.

Das, A., Bonneau, J., Caesar, M., Borisov, N., and Wang, X.

(2014). The tangled web of password reuse. In NDSS,

volume 14, pages 23–26.

Eldefrawy, M. H., Alghathbar, K., and Khan, M. K.

(2011). Otp-based two-factor authentication using

mobile phones. In 2011 eighth international con-

ference on information technology: new generations,

pages 327–331. IEEE.

Jens ’atom’ Steube, Gabriele ’matrix’ Gristina (2015).

Hashcat advanced password recovery. https://hashcat.

net/hashcat/. Last checked on Aug 01, 2022.

Jover, R. P. (2020). Security analysis of sms as a second

factor of authentication. Communications of the ACM,

63(12):46–52.

Kumar, H., Kumar, S., Joseph, R., Kumar, D., Singh, S.

K. S., Kumar, A., and Kumar, P. (2013). Rainbow ta-

ble to crack password using md5 hashing algorithm.

In 2013 IEEE Conference on Information & Commu-

nication Technologies, pages 433–439. IEEE.

Last Pass (2022). Lastpass security his-

tory. https://www.lastpass.com/it/security/

what-if-lastpass-gets-hacked/. Last checked on

Aug 01, 2022.

Lenz, T. and Zwattendorfer, B. (2015). Enhancing the mod-

ularity and ﬂexibility of identity management archi-

tectures for national and cross-border eid applications.

In 11th International Conference on Web Information

Systems and Technologies, pages 123–143. Springer.

Li, Z., He, W., Akhawe, D., and Song, D. (2014). The

{Emperor’s} new password manager: Security anal-

ysis of web-based password managers. In 23rd

USENIX Security Symposium (USENIX Security 14),

pages 465–479.

Manber, U. (1996). A simple scheme to make passwords

based on one-way functions much harder to crack.

Computers & Security, 15(2):171–176.

Mohammed, S., Ramkumar, L., and Rajasekar, V. (2017).

Password-based authentication in computer security:

Why is it still there. SIJ Trans. Comput. Sci. Eng. Its

Appl, 5:33–36.

NordPass (2022). Top 200 most common passwords. https:

//nordpass.com/it/most-common-passwords-list/.

Last checked on Aug 01, 2022.

OpenWall (1996). John the ripper. https://www.openwall.

com/john/. Last checked on Aug 01, 2022.

Pasquini, D., Cianfriglia, M., Ateniese, G., and Bernaschi,

M. (2021). Reducing bias in modeling real-world

password strength via deep learning and dynamic

dictionaries. In 30th USENIX Security Symposium

(USENIX Security 21), pages 821–838.

Shadow, D. (2022). Account Takeover in 2022. Technical

report.

Shirvanian, M., Jareckiy, S., Krawczykz, H., and Saxena, N.

(2017). Sphinx: A password store that perfectly hides

passwords from itself. In 2017 IEEE 37th Interna-

tional Conference on Distributed Computing Systems

(ICDCS), pages 1094–1104. IEEE.

Shirvanian, M., Price, C. R., Jubur, M., Saxena, N., Jarecki,

S., and Krawczyk, H. (2021). A hidden-password on-

line password manager. In Proceedings of the 36th An-

nual ACM Symposium on Applied Computing, pages

1683–1686.

Taha, M. M., Alhaj, T. A., Moktar, A. E., Salim, A. H., and

Abdullah, S. M. (2013). On password strength mea-

surements: Password entropy and password quality. In

2013 International Conference on Computing, Elec-

trical and Electronic Engineering (ICCEEE), pages

497–501. IEEE.

Tao, H. (2006). Pass-Go, a new graphical password

scheme. PhD thesis, University of Ottawa (Canada).

Yao, F. F. and Yin, Y. L. (2005). Design and analysis of

password-based key derivation functions. In Cryp-

tographers’ Track at the RSA Conference, pages 245–

261. Springer.

Zhang, Y., Monrose, F., and Reiter, M. K. (2010). The se-

curity of modern password expiration: An algorithmic

framework and empirical analysis. In Proceedings of

the 17th ACM conference on Computer and communi-

cations security, pages 176–186.

Zhang, Z., Liu, P., Wang, W., Li, S., Wang, P., and Jiang, Y.

(2020). High-performance password recovery hard-

ware going from gpu to hybrid cpu-fpga platform.

IEEE Consumer Electronics Magazine, 11(1):80–87.

The Ginger: Another Spice to Hinder Attacks on Password Files

173