Int. J. Internet Technology and Secured Transactions, Vol. 6, No.

1, 2015 43

A secure and efficient user authentication scheme for

the web

Yassine Sadqi*, Ahmed Asimi and

Younes Asimi
Departments of Mathematics and Computer Science,
Faculty of Science,
Information Systems and Vision Laboratory (LabSiV),
Ibn Zohr University,
B.P. 8106, City Dakhla, Agadir, Morocco
Email: yassine.sadqi@gmail.com
Email: asimiahmed2008@gmail.com
Email: asimi.younes@gmail.com
*Corresponding author

Abstract: User authentication is the ‘Achilles heel’ of modern web

applications security. Although strong schemes based on public key
cryptography have been proposed, none of them is widely adopted.
Specifically, they are difficult to use and expensive to deploy. In this paper, we
propose a new mutual authentication scheme, which is based on public key
cryptography and other cryptographic primitives. Our analysis shows that our
scheme is efficient, and improves authentication security without sacrificing
usability and depolaybility. Moreover, our scheme can be combined with
HTTPS to effectively add another layer of security to web applications. In so
doing, we demonstrate that our scheme can significantly improve the security
of web applications with minimal impact on performance.

Keywords: user authentication; mutual authentication; web application

security; strong scheme; public key cryptography; cryptographic primitives.

Reference to this paper should be made as follows: Sadqi, Y., Asimi, A. and
Asimi, Y. (2015) ‘A secure and efficient user authentication scheme for the
web’, Int. J. Internet Technology and Secured Transactions, Vol. 6, No. 1,
pp.43–63.

Biographical notes: Yassine Sadqi received his Master’s degree in the field of
Computer Science and Distributed Systems at the Ibn Zoher University, in
2012. He is currently a PhD candidate at the Ibn Zoher University, Agadir,
Morocco. His main field of research interest is web applications security,
network security and cryptography.

Ahmed Asimi received his PhD degree in Number Theory from the University
Mohammed V, Agdal, in 2001. He is a reviewer at the International Journal of
Network Security (IJNS). His research interest includes number theory, code
theory, and computer cryptology and security. He is a Full Professor of the
Faculty of Science at Agadir since 2008.

Younes Asimi received his Master’s degree in Computer Science and

Distributed Systems in the Departments of Mathematics and Computer Science,
Faculty of Science from the University Ibn Zohr, Agadir, Morocco, in 2012. He
is currently pursuing his PhD in the Departments of Mathematics and

Copyright © 2015 Inderscience Enterprises Ltd.

44 Y. Sadqi et al.

Computer Sciences, Information Systems and Vision Laboratory, Morocco. His

research interests include authentication protocols, computer and network
security and cryptography.

1 Introduction

Web applications have experienced a rapid and massive growth in popularity in the last
decade. We are able to obtain the desired services (online e-commerce, e-banking) using
mobile devices anytime anywhere. Since web applications are vulnerable, security
problems have become a more increasing concern for both webmasters and users
(Scambray et al., 2011).
Our focus is authentication on the web, a core component of any modern web
applications to prevent unauthorised access to users’ private resources (e.g., bank
accounts, users’ personal information). Our choice of web authentication as a target has
significant implications. In particular, authentication on the web differs from traditional
authentication in part, because of the web limited infrastructure for both client (web
browsers) and server sides (web applications platforms) (Fu et al., 2001). For example,
the stateless nature of the Hyper Text Transfer Protocol (HTTP) affects the overall design
of web authentication schemes. The HTTP server treats each request as an independent
transaction that is unrelated to any previous request (Sood et al., 2011). So, in each HTTP
request, the client needs to provide an authentication token to the web application.
Without this token, a user would have to reenter his/her authentication credentials (e.g.,
password) in each HTTP request. Moreover, on the web we cannot rely on technology
not widely deployed. For instance, most personal computers do not include a smart card
reader or other hardware token systems. Also, in Herley (2009) the authors concluded
that users are resistant to innovation that alters their behaviour, thus any complex or
additional steps than the conventional username/password are hard to adopt.
At first, personal websites employed the built-in ‘basic HTTP authentication
specification’ for password submission (Franks et al., 1999). The RFC 2617 defines the
‘digest’ scheme as an extension for HTTP/1.1. It is a security enhancement alternative
that avoids most serious flaws of basic HTTP authentication. However, digest does not
provide any security of the content and represents multiple security risks.
Currently due to ease of use, low cost, and flexibility, HTML-forms-over-TLS is the
widely adopted scheme used by web applications for users’ authentication (Manulis et al.,
2014). In this scheme, a typical authentication consists of three phases:
1 Login phase: First a user enters his/her identity and password in a HTML form, and
then the user’s browser sends these authentication credentials over a secure HTTPS
session.
2 Authentication phase: The web application validates the authentication credentials
(username and password). After successful authentication, the web application
associates a unique session identifier with that user, and sends it to the user’s
browser over the established server-authenticated HTTPS channel. Then the user’s
browser stores this authentication token.
 A secure and efficient user authentication scheme for the web 45

3 Subsequent-requests: The user’s browser includes the stored session identifier with
each request to the web application.
Although this ubiquitous scheme relies on a secure channel to submit passwords and
authentication tokens, the scheme is still always vulnerable:
• Client side: We can include a wide range of identity thief attacks that target the client
(the user or the user’s browser) from the most basic such as guessing (e.g., brute
force and dictionary attacks) to more sophisticated methods such as phishing, session
credential theft, session fixation, and cross-site request forgery.
• Server side: This contains all problems with passwords storage and server
compromise attacks.
In theory, a straightforward alternative solution to the above problems is public key
cryptography rather than a shared secret (Czeskis et al., 2012). This class of cryptography
requires two different keys: one is public and the other is private. In the authentication
process, a client signs a message using its private key. The validation of this digital
signature via the associated client public key gives the server a strong reason to believe
that the login request was created by a legitimate client (Schneier, 1996). This is possible,
because public key cryptography assumes that the private key is only known to
its owner. In practice, while strong web authentication schemes based on public key
cryptography have been proposed, web applications continue to use the conventional
HTML-forms-over-TLS design, regardless of its known weaknesses. Recently, Bonneau
et al. (2012) demonstrated in a large study that most of these secure schemes are difficult
to use, and expensive to deploy (e.g., additional infrastructure requirements, poor user
experience). Web authentication experts acknowledge that the challenge is not how to
design more secure authentication scheme, but the real challenge is how to design secure
scheme that does not sacrifice usability and deployability (Bonneau et al. 2012; Czeskis
et al., 2012).
In this paper, we propose a new mutual authentication scheme that is efficient, and
strengthen authentication without sacrificing usability and depolaybility. The proposed
scheme spans the full authentication lifecycle, consisting of initial authentication, the
subsequent HTTP requests authentication, and the renewal phases. In that, we build
HTTP session management on a secure initial mutual authentication. This allows both an
efficient, consistent design as well as robust end-to-end security guarantees. The
reminder of this paper is organised as follows: Section 2 presents related work and their
shortcomings. Section 3 proposes our scheme. Section 4 provides comparative evaluation
and performance analysis of the proposed scheme. Section 5 concludes the paper.
In the rest of this paper, we denoted by:
Ui ith user
IDi unique identifier of user Ui
Pi password of user Ui
Salti cryptographic salt of user Ui
d web application domain name
46 Y. Sadqi et al.

RWi random value used at most once within the scope of a given session
generated by the web application for Ui
RBi random value used at most once within the scope of a given session
generated by the browser for Ui
USKi, UPKi asymmetric key pair for user Ui generated by the browser using a secure
asymmetric key generation algorithm
SSK web application private key
SPK web application public key certificate
PSKi pre-session key shared between Ui and the web application using HTTPS
SKi session key
X inew renewal of the parameter X

PBKDF( ) password-based key derivation function

MKi the master key that is output from an execution of PBKDF by the
browser
SE(k, b) encryption of b by k using a secure symmetric encryption algorithm
AE(k, b) encryption of b by k using a secure asymmetric encryption algorithm
SD(k, b) decryption of b by k using a secure symmetric decryption algorithm
AD(k, b) decryption of b by k using a secure asymmetric decryption algorithm
H( ) cryptographic one way hash function
HMAC(K, m) compute the keyed-hash message authentication code of message m
using the secret key K
A || B the concatenation of binary strings A and B
⊕ XOR operation
== comparison
url URL of the resource requested by Ui browser
NIST National Institute of Standards and Technology.

2 Related work

As we’ve discussed, authentication on the web differ from traditional authentication.

Hence in this section, we do not include schemes that were not originally design for web
applications. Moreover, we focus on schemes that rely on asymmetric cryptography in
some sort as a way to replace password-based authentication. Until, the writing of this
paper, only four main schemes, replace passwords with asymmetric digital signatures:
 A secure and efficient user authentication scheme for the web 47

1 Microsoft CardSpace (Microsoft, n.d.)

2 SSL/TLS client authentication (IETF, 2008)
3 PhoneAuth (Czeskis et al., 2012)
4 Mozilla Persona (Mozilla, 2011).
In this section, we overview these schemes and present their limits. Then we use the
lessons learned to motivate and inform our design goals in Section 4. Microsoft
CardSpace was not widely adopted, and on February 15th 2011 Microsoft abandoned the
project (Dietz et al., 2012), thus we do not present it in this paper.

2.1 SSL/TLS client authentication

SSL/TLS provides an optional mechanism to authenticate clients based on public key
certificate and asymmetric digital signatures (IETF, 2008). This scheme presupposes that
the client maintains a public key certificate and its associated private key. In the
authentication process, the server requests the client to provide its public key certificate,
so that the connection can be mutually authenticated. The client responds with a message
containing the client’s certificate, and a certificate verification message, which is a
signature over the previous messages using the client’s certificate’s private key. The
server then verifies the client’s certificate and digital signature. While SSL/TLS offers a
secure alternative for web users, this scheme has several usability and deployability
challenges, which have impeded its adoption across the web (Fu et al., 2001; Czeskis
et al., 2012; Marchesini et al., 2005).

2.2 Mozilla persona

Learning from Microsft CardSpace and SSL/TLS client authentication failures, recently
two main schemes based on public key cryptography have been proposed; Mozilla
Persona (Mozilla 2011) and PhoneAuth (Czeskis et al., 2012). Persona was first released
in 2011 and fully deployed in 2012 by Mozilla on its own web applications. Unlike
SSL/TLS client authentication, Persona aims to allow users to log into different web
applications without the centralised authentication services such as public key
infrastructure (PKI). While Persona improves usability and deployability of users’
authentication, the scheme scores poorly in the security arena in Bonneau et al. (2012)
framework. Persona relies on the identity provider authentication mechanism, which
represents a single point of failure; if the user identity provider account is compromised,
all other accounts that are based on this identity provider will be also compromised. Also,
persona is vulnerable to phishing attacks.

2.3 PhoneAuth
PhoneAuth relies on the user’s Smartphone in order to provide a second authentication
factor, and on the concept of origin bound certificate in order to detect and withstand man
in the middle attacks (Czeskis et al., 2012; Dietz et al., 2012). Unlike Persona that uses
the browser to generate a private/public key pair, PhoneAuth adds an additional device
(the user’s mobile phone) to provide secure user authentication. However, the reliance on
48 Y. Sadqi et al.

Bluetooth connection impacts the performance. Specifically, adding a new device to

process of authentication, automatically increase the number of cryptographic operations.
The security of both schemes is based on a full HTTPS deployment for all the exchange
messages. Unfortunately, it is known that a full HTTPS deployment imposes a significant
performance overhead relative to HTTP transaction on the same platform.

3 Our proposed scheme

As discussed above, previous solutions are helpful to build strong authentication on the
web, but expose several shortcomings. In this section, we first overview the proposed
scheme, then we present the registration, login, initial mutual authentication,
subsequent-requests authentication, and renewal phases.

3.1 Overview
We propose a novel scheme that provides secure mutual authentication on the web,
without sacrificing usability and deployability. Our work leverages the following key
insights. First, learning from previous propositions failures, we conclude that any kind of
complexity in the process of authentication should be transparent from users. Second,
secure mutual and authentication on the web needs to rely on cryptographic primitives
(e.g., asymmetric/symmetric encryption, hash function, HMAC), which offer strong
mechanisms to guaranty data confidentiality, authenticity, and data integrity (Schneier,
1996).
The scheme of our proposal is composed of a client and server components. The
client component includes:
• Browser: A modern web browser that support HTTPS.
• Client cryptographic services: It must provide the following features:
a the asymmetric cryptography primitives
b the symmetric cryptography primitives
c the hash and HMAC functions primitives
d the key derivation function primitive such as PBKDF, which is specified in the
RFC 2898 (RSA Laboratories, 2000)
e the regeneration of random sequences.
• Client-side database: In the registration phase, Ui browser stores the following
authentication settings, which is used in the authentication phase:
a UIDi: It contains a unique identifier for a specific Ui account. For each Ui a
unique IDi exists in a specific web application. But a user can use the same IDi to
register in other web applications. We therefore choose to store the IDi hash value
concatenated with the web application’s domain name as the unique identifier:
UIDi = H(IDi || d).
 A secure and efficient user authentication scheme for the web 49

• Salti: In the registration phase, the web application handles to regenerate Salti. We
can rely the generator of a Safe Cryptographic Salt presented in Asimi et al. (2015).
This salt is used with Pi to regenerate a symmetric encryption key MKi.
• ESKi: It represents the encrypted format of USKi to protect its confidently:
ESKi = SE(MKi, USKi).
• EPKi: It contains UPKi encrypted format: EPKi = SE(MKi, UPKi).
Table 1 Client-side Ui authentication settings

UIDi Salti ESKi EPKi

The server component contains:

• The web application: It is an application placed on a web server.
• Server cryptographic services: It must provide the same primitives as the client
cryptographic services and the regeneration of random salts specific to each user Ui.
• Server-side database: The web application characterised each user Ui by three
authentication settings, which will be created during the registration phase. These
settings are used to identify users during the authentication phase:
a IDi: It represents a unique representation of Ui within the web application.
b SUPKi: Instead of storing UPKi in cleartext, the web application stores
SUPKi = UPKi ⊕ SSK ⊕ RWi to preserve UPKi secrecy.
c SRi: It is stored as SRi = RWi ⊕ H(SSK) and used to compute UPKi from SUPKi.
Table 2 Server-side Ui authentication settings

IDi SUPKi SRi

Our scheme consists of four phases, implemented as sub-protocols: A registration

protocol, login and initial mutual authentication protocol, subsequent-requests
authentication, and renewal protocol. In the following sub-sections, we give details on the
realisation of the four sub-protocols.

3.2 Registration phase

This phase is invoked whenever a new user Ui wants to register within the web
application. This registration process does not ask from Ui more than choosing an IDi and
Pi. It is know that password-based authentication presents several security problems. For
this, the browser transparently from Ui integrates other cryptographic parameters
(Table 1) that are used to strengthen users’ authentication. Also in this phase, we rely on
HTTPS to protect UPKi confidentiality and integrity. This phase proceeds as follows:
50 Y. Sadqi et al.

Figure 1 Registration phase

• Ui chooses an IDi.
• The browser:
a Computes UIDi = H(IDi || d).
b Verifies the existence of UIDi in its database. If it exists, the browser informs Ui
that he/she already has an account within this web application. If not sends IDi
to the web application.
• The web application verifies the existence of IDi. If it exists, the web application
sends an error message informing Ui to choose another identifier. Otherwise the web
application generates Salti and sends it to the browser.
• The browser provides Ui with a built-in password entry, because in our scheme the
browser does not need to send Pi to the web application. Pi is only used to compute
MKi.
• Ui enters his/her Pi.
• The browser:
a generates the pair USKi and UPKi
b sends UPKi over HTTPS to the web application
c computes MKi = PBKDF(Pi, Salti)
d encrypts both USKi and UPKi with MKi using a secure symmetric encryption
algorithm: ESKi = SE(MKi, USKi), EPKi = SE(MKi, UPKi).
e saves the authentication parameters associated to Ui: UIDi, ESKi, EPKi, and
Salti.
• The web application:
a generates RWi
b calculates SPKi as SUPKi = UPKi ⊕ SSK ⊕ RWi and SRi as SRi = RWi ⊕ H(SSK).
c saves Ui associated parameters: IDi, SDKi, and SRi.
 A secure and efficient user authentication scheme for the web 51

Figure 2 Login and initial mutual authentication phase

3.3 Login and initial mutual authentication phase

Currently, users on the web are familiar with entering a username and password to login.
We therefore does not require from users more than entering an identifier and password.
The additional steps in our scheme are performed in the background by the user’s
browser. Specifically, the browser relies on the client cryptographic services to integrate
cryptographic authentication credentials (PSKi, USKi, UPKi and RBi) to assure strong
authentication for users. In that way instead of relying on weak authentication such as
simple text passwords, the web application needs to confirm the identity of Ui using
cryptographic operations. In this phase (Figure 2), we have to make sure on:
52 Y. Sadqi et al.

• the users’ identity

• the asymmetric and symmetric cryptography operations
• the regeneration of PSKi
• the regeneration of random nonce (RBi and RWi)
• the mutual authentication
• the computation of SKi.
The login and initial mutual authentication phase primarily aims to provide:
1 strong mutual authentication between communicating entities without disclosure of
the originals parameters of authentication
2 the agreement on a session key (SKi) that is used later to build secure
subsequent-requests authentication.
The following steps describe the proposed scheme login and initial mutual authentication
phase.
• The user Ui enters his/her IDi.
• The browser computes UIDi = H(IDi || d) checks the existence of UIDi in its
client-side database:
a If it exits, then the browser:
1 retrieves for its local store the matching user credentials in case of a correct
IDi
2 sends IDi over HTTPS to the web application.
b Otherwise, the operation is aborted with an error message indicating that this IDi
does not have an account in this web application.
• The web applications checks the existence of IDi:
a If it exits, then the web application:
1 recognises the user Ui and retrieves form its database Ui corresponding RWi
as RWi = SRi ⊕ H(SSK) and UPKi as UPKi = SUPKi ⊕ SSK ⊕ RWi.
2 sends its SPK over HTTPS to the browser.
b Otherwise, it returns an error message.
• The browser provides Ui with a private password entry, because in our scheme the
browser does not send Pi to the web application. Pi is only used to compute MKi.
• The user Ui enters his/her Pi.
• The browser:
a Generates PSKi.
b Encrypts PSKi using SPK as Ki = AE (SPK, PSKi).
c Computes MKi = PBKDF(Pi, Salti).
d Decrypts ESKi and EPKi using MKi: USKi = SD(MKi, ESKi), and
UPKi = SD(MKi, EPKi).
 A secure and efficient user authentication scheme for the web 53

e Computes M2i = RBi ⊕ PSKi ⊕ UPKi.

f Calculates in two steps an identity cryptographic assertion:
1 The message digest MDi of Ui: MDi = H(IDi ||d|| UPKi || RBi || PSKi)
2 The hash-value of the message MDi is encrypted with USKi and thus an
encrypted hash-value, also called identity assertion about the user’s identity,
is obtained: IAi = AE(USKi, MDi).
g Sends over HTTP Ki, M2i, IAi to the web application.
• The web application:
a Decrypts Ki with SSK: PSKi = AD(Ki, SSK).
b Computes RWi = SRi ⊕ H(SSK), UPKi = SUPKi ⊕ SSK ⊕ RWi, and
RBi = M2i ⊕ PSKi ⊕ UPKi.
c Decrypts the received cryptographic identity assertion using UPKi:
MDi = AD(UPKi, IAi).
d Computes MDi′ = H ( IDi || UPK i || d || RBi || PSK i ).
e Compares MDi′ == MDi
1 If comparison is successful, then the login request was created by a legitimate
user:
• generates RWi new
• calculates M 3i = RWi new ⊕ SSi ⊕ UPKi and
M 4i = H ( RBi || RWi new || PSK i || UPK i ), and sends both M3i and M4i to
the browser
• computes SKi = H ( IDi || d || UPK i || RBi || RWi new || PSK i ).
3 Otherwise, the web application returns an error message: failed user
authentication.
• The browser:
a Computes M 4i′ as M 4i′ = H ( RBi || RWi new || SSi || UPKi )
b Compares M 4′i and the received M4i.
c If the comparison is successful:
1 mutual authentication is assured between the browser and the web application
2 computes the session key SKi = H ( IDi || d || UPK i || RBi || RWi new || PSK i ).

3.4 Subsequent-requests authentication phase

As we’ve discussed in Introduction section, HTTP treats each request as an independent
transaction that is unrelated to any previous request. HTTP cookie authentication is the
widely adopted mechanism for subsequence-requests authentication (Sadqi et al., 2014).
HTTP cookie authentication security flaws discussed in details in Dacosta et al. (2012),
Liu et al. (2012) and Sadqi et al. (2014).
54 Y. Sadqi et al.

In our scheme, we propose a secure replacement that is built on a shared session key
SKi agreed upon in the initial mutual authentication phase. The session key concept is a
compromise between the symmetric and asymmetric encryption to combine the two
techniques. Asymmetric algorithms allow overcoming the problems associated with key
exchange via a secure channel. However, these algorithms are much less efficient in
terms of computation time than symmetric algorithms (Schneier, 1996). The aim of this
phase is to include in each HTTP request from Ui browser to the web application after a
successful initial authentication with an HMAC digital signature based on SKi.

Figure 3 Subsequent-requests authentication phase

• After successful initial mutual authentication and the creation of SKi, in any
subsequent request to the web application, the browser:
a generates RBinew
b computes M 5i = RBinew ⊕ PSKi ⊕ UPK i , the HMAC digital signature of the
HTTP request: M 6i = HMAC ( SK i , url || RBinew || RWi new ), and sends then M5i,
M6i to the web application.
• The web application:
a computes RBinew = M 5i ⊕ PSK i ⊕ UPKi and
M 6′i = HMACs ( SK i , url || RBinew || RWi new )
b Compares M6i and M 6′i :
1 If the comparison is successful:
• The request is considered valid. Specifically, the authenticity and integrity
of the received requests are ensured.
• Sends the requested resource to Ui browser.
2 Otherwise, the request is cancelled and the web application redirects the
browser to the login phase.

3.5 Renewal phase

In password-based authentication it is recommended to change the password regularly.
Similarly, cryptographic keys should have a definite lifetime (Schneier, 1996). In the
proposed scheme, the process from Ui perspective is similar to changing his/her
password. The browser takes charge of the cryptographic additional steps. In particular,
the user should be authenticated in the previous phase, and the session key is created
 A secure and efficient user authentication scheme for the web 55

(SKi). The goal is to open a secure communication channel allowing the renewal of all the
authentication settings in a secure environment. This phase proceeds as follows:

Figure 4 Renewal phase

• The user Ui authenticates to the web application.

• After successful mutual authentication between Ui and the web application, Ui
chooses a new Pi new .

• The browser:
a Generates new user credentials UPK inew , USK inew
b Sends to the web application X i = SK ⊕ UPK i ⊕ UPKinew and
Yi = H ( SK || UPK i || UPK inew ).

• The web applications:

a Computes UPKinew from Xi as UPK inew = X i ⊕ SK ⊕ UPK i .
b Verifies if Yi′ = H ( SK || UPK i || UPK inew ) value equals the received Yi value.
1 If both values are equal, the web application is assured that the request is sent
by the legitimate user and the message is not tampered during transmission.
Otherwise, the request is rejected.
c Generates Saltinew and RWi new , and sends Saltinew to the browser.
56 Y. Sadqi et al.

d Updates Ui authentication settings: SUPK inew = UPK inew ⊕ SSK ⊕ RWi new ,
SRinew = RWi new ⊕ H ( SSK ).

• The browser:
a computes MKinew = PBKDF ( Pi new , Saltinew )
b encrypts both USK inew and UPK inew with MK inew : ESKi = SE ( MK inew , USK inew ),
EPK i = SE ( MK inew , UPKinew )
c updates the authentication parameters associated to Ui: ESK inew , EPK inew , and
Saltinew .

4 Evaluation and analysis of our scheme

4.1 Comparative evaluation

We are going to evaluate our scheme by using Bonneau et al.’s (2012) framework of 25
different usability, deployability and security benefits.
We include the two modes of using our scheme – mobile and desktop. In mobile
mode, we assume that the user accesses his/her web account from a mobile phone. In
desktop mode, we suppose that the user authenticates to the web application from his/her
personal desktop computer. We also evaluate the legacy password and related work
presented in Section 3; we reproduce the same scores reported for passwords and
PhoneAuth in Czeskis et al. (2012) and Bonneau et al. (2012), but we slightly disagree
with Czeskis et al. scores reported in Czeskis et al. (2012). Table 3 shows the results of
our evaluation. The Quasi-prefix is used in case where a scheme almost offers the benefit.
Usability. A clear result in the usability arena is that no scheme provides all usability
properties, and learning from Microsoft CardSpace (Cameron and Jones, 2007) and
SSL/TLS client certificate authentication (IETF, 2008) failures, all other evaluated
schemes improve usability with the same or more security scores. In particular, similar to
passwords, Persona (Mozilla, 2011), PhoneAuth (Czeskis et al., 2012), and our scheme
(in both modes) provide U5 and U6, since neither schemes require the user to do anything
beyond entering a username/password. Both modes of the proposed scheme and Persona
satisfy U2 and Quasi-U1, in that most users will still have to remember one password. As
we’ve shown our scheme relies on random salt that helps PBKDF to generate a different
MKi even with the usage of the same password. The desktop mode of our scheme does
not provide U3 and U8, since users won’t be able to authenticate without the stored user
credentials (see section 6 for details). The mobile mode of the proposed scheme assures
U3 and U8, which are two usability benefits where passwords excel. Hence, our scheme
in this mode is able to authenticate users, anytime anywhere, with no additional physical
object to carry.
 Persona
Password

certificates

PhoneAuth

Our scheme
Our scheme

mobile mode
desktop mode
SSL/TLS client

S
S
S
N
N
N

U1: Memorywise-effortless
S
S

Y
Y
Y
N

U2: Scalable-for-users
S
S

Y
N
Y
Y

U3: Nothing-to-carry
N
N
N
Y
N
N

U4: Physically-effortless
Y
Y
Y
Y
N
Y
Usability

U5: Easy-to-learn
Y
Y
Y
Y
N
Y

U6: Easy-to-use
S
S
S
S
S
S

U7: Infrequent-errors
S
S

Y
Y
N
Y

U8: Easy-recovery-from-loss
S

Y
Y
Y
N
Y

D1: Accessible
S

Y
Y
Y
N
Y

D2: Negligible-cost-per-user
S
S
S
S
N
Y

D3: Server-compatible
S
S
S
S
Y
Y

D4: Browser-compatible
Deployability

N
N
N
Y
Y

D5: Mature
Y
Y
Y
Y
Y
Y

Y D6: Non-proprietary
Y
Y
Y
Y
N

S1: Resilient-to-Physical-observation
S
S

Y
Y
Y
Y
S2: Resilient-to-targeted-impersonation
S

Y
Y
Y
Y
N S3: Resilient-to-throttled-guessing

Y
Y
Y
Y
N
S4: Resilient-to-unthrottled-guessing

Y
Y
Y
N
Y
N
S5: Resilient-to-internal-observation

Y
Y
Y
Y
N
Y
S6: Resilient-to-leaks-from-other-verifiers
Security

Y
Y
Y
N
N
Y
S7: Resilient-to-phishing

Y
Y
Y
Y
Y
Y
S8: Resilient-to-theft

Notes: ‘Y’ means the benefit is provided, ‘N’ means not provided, while ‘S’ means the benefit is somewhat provided. For some scores, we disagree with the Czeskis et al. scoring.
Y
Y
N
N
Y
N
S9: No-trusted-third-party

Y
Y
Y
Y
Y
N
S10: Requiring-explicit-consent

Y
Y
N
N
Y
N
S11: Unlinkable
PhoneAuth, and Persona using Bonneau et al.’s evaluation framework
Comparative evaluation of our scheme against passwords, SSL/TLS client certificates, Table 3
57 A secure and efficient user authentication scheme for the web
58 Y. Sadqi et al.

Deployability. The essential part of depolyability assessment is to figure out how much
change would be required in current web infrastructure in order to widely adopt our
scheme. Passwords achieve all deployability benefits. And from Table 3, we can see that
all other schemes provide more deployability properties than SSL/TLS client certificate
authentication. This explains why this scheme is rarely used on the web, even after years
of its existence. We also note that in both modes our scheme is fairly deployable. One of
our main design goals was to develop an authentication scheme that allows most web
existing infrastructure to remain unchanged, while at the same time strengthening
authentication. Specifically, the proposed scheme somewhat satisfies D3 and D4, since it
requires minimum changes on the user’s browser and the web application. Similarly, our
scheme provides D1 and D2 in that our scheme is intended to be implemented using
existing technologies and standards.
Security. From Table 3, we can see that only our scheme (in both modes) satisfies all
the security requirements. While Czeskis et al. (2012) indicated that PhoneAuth provides
S9, we do not believe that this is the case. S9 requires no dependency over a third party
other than the user and the verifier. PhoneAuth depends on the user’s phone security,
which is a third party. In details the proposed scheme provides S1, S2, S3, S4, and S5
because, even after observing or guessing the correct Pi, the attacker cannot authenticate
unless he/she also steals Ui browser store, which holds: IDi, ESKi, EPKi, Salti. Our
scheme is resilient-to-leaks-from-other-verifiers (S6) because Ui has a key pair (USKi,
UPKi) and Salti per web application, so credentials are not recycled. Our scheme provides
S7 because the user’s browser never transmits on the clear UPKi, and Pi. Also, USKi is
never transmitted on the network nor stored on the clear (see Section 4 for details). It is
resilient-to-theft (S8) because possession of information stored in Ui browser’s
credentials store is insufficient (ESKi, EPKi, and Salti): the user Ui still needs to type
his/her IDi and Pi in the browser. Unlike PhoneAuth (Czeskis et al., 2012) that relies on
the user’s phone, our scheme is no-trusted-third-party (S9) as the security does not
depend on a third party other than the user’s browser and the web application. Our
scheme also offers S10 as Ui cannot be logged in automatically without entering his/her
account corresponding IDi and Pi. Our scheme is unlinkable (S11) because a specific user
Ui has a different authentication credentials for each web application. We note also that
all evaluated schemes improve security in comparison with passwords authentication. In
particular, the involvement of asymmetric cryptography and other cryptographic
primitives (such as hash functions, cryptographic salt, and symmetric/asymmetric
cryptography), which have the benefit of not exposing secrets to the eavesdropper which
could be used to impersonate the client to the web application. Also, when asymmetric
cryptography is used, the private key can be moved out of reach of thieving malware on
the client, perhaps using a hardware trusted platform module (TPM) (Yang et al., 2012).
However, our scheme is different compared to others. HTTPS is only used in the
registration phase. In our threat model we assume that no SSL/TLS man-in-the-middle
attack between the user’s browser and the web server during user’s registration. But the
security of our scheme is not depended on this assumption. The user’s Ui asymmetric key
pairs USKi, UPKi, and Pi, can all be considered as secret authentication parameters
(authentication credentials). These credentials are never transmitted nor stored as plain
text. The proposed scheme aims to provide authentication credentials (PWi, USKi, SKi,
RBi, RWi, and UPKi) with the following security services:
 A secure and efficient user authentication scheme for the web 59

1 Confidentiality: Our scheme preserves the secrecy of authentication credentials

throughout their lifecycle: while they are at rest (on database), and while they are in
transit.
2 Integrity: Our scheme allows both the web application and the browser to detect
whether a message has been modified.
3 Anti-replay: In the case that an attacker replays a stolen authenticator, the proposed
scheme is able to detect that the authenticator is invalid. Otherwise, the attacker
would be authenticated as the client that the replayed authenticator was issued to.
Table 4 shows the cryptographic primitives used to provide these core security services.
As we showed in Section 4, Pi is neither stored in the web application nor in the user’s
browser.
And as we’ve discussed in Section 4, Pi is only used to generate MKi. Similarly, the
USK is never transmitted over the network and it is stored in the user’s
browser in an encrypted format using a secure symmetric encryption algorithm:
ESKi = SE(MKi, USKi). The UPKi is transmitted to the web application over a secure
HTTPS session. In the client side UPKi is stored as: ESKi = SE(MKi, USKi). And in the
other side, the web application relies on the server private SSK and random RWi to store
the encryption key as SUPKi = UPKi ⊕ SSK ⊕ RWi.
Table 4 Cryptographic primitives used to assure core security services of our scheme
authentication credentials

Confidentiality
Integrity Anti-replay
Over the network At rest
HTTPS, symmetric Symmetric One way hash Random nonce
and asymmetric cryptography, one way functions,
cryptography hash functions, asymmetric
cryptographic salt cryptography

In subsequent-requests phase, our scheme relies on the secure initial mutual

authentication phase to generate an HMAC signature that will guarantee
subsequent HTTP requests authenticity and integrity. In addition RBinew and RWi new
are never transmitted in the clear. Instead, the web application
sends M 3i = RWi new ⊕ PSK i ⊕ UPK i and the browser computes RWi new as
RWi new = M 3i ⊕ PSK i ⊕ UPK i . The browser sends M 5i = RBinew ⊕ PSK i ⊕ UPK i and
the web applications computes RBinew = M 5i ⊕ PSK i ⊕ UPKi . Both the
browser and the web applications relies on random nonce (RBi, RWi)
with SKi = H ( IDi || d || UPK i || RBi || RWi new || PSK i ) and computes
M 6i = HMAC ( SK i , url || RBinew || RWi new ).
 60

Table 5
Y. Sadqi et al.

Schemes
Phase Mozilla Persona SSL/TLS client PhoneAuth
Our scheme
(Mozilla, 2011) certificate (IETF, 2008) (Czeskis et al., 2012)
Registration - 1TAKG + 1TCG 1THTTPS + + 2TAKG + 1TCG + 1TCV 1THTTPS + 1TAKG + 1TPPBKDF + 1TH
3TX + 2TSE + 1TS + 1TR
Login 1THTTPS + 1TAKG+ 2TCG 1TAE + 1TH 1THTTPS + 1TAKG + 1TCG + 1TCV + 4THMAC + 2TSE + 2TSD+ 2TH 2TAE + 2TSD + 2TH + 1TPBKDF + 1TK
+ 1TAE + 1TAD + 1TR + 2TX
Mutual and subsequent-requests 1THTTPS + 2TCV 1TAD + 1TH + 1TCV 1THTTPS + 1TSD + 1TAD + 1TH + 2THMAC + 2TX 2TAD + 2THMAC + 5TH + 2TR + 13TX
authentication
Notes: * TH: the time for performing a one-way hash function computation, THTTPS: the time for performing HTTPS computation, TX: the time for performing a exclusive-OR computation,
TAKG: the time for performing asymmetric key generation, TSE: the time for performing a symmetric encryption computation, TSD: the time for performing a symmetric
decryption computation, TAE: the time for performing a asymmetric encryption computation, TAD: the time for performing a asymmetric decryption computation,
THMAC: the time for performing a HMAC computation, TPBKDF: the time for performing a password based key derivation computation, TCG: the time for performing a
certification generation computation, TCV: the time for performing a certification verification computation, TS: the time for performing a salt generation, TR: the time for
performing a random nonce generation, TK: the time for performing a pre-session key generation.
Comparison of computational complexity among the schemes
 A secure and efficient user authentication scheme for the web 61

4.2 Performance analysis

Next, we evaluate the efficiency of the proposed scheme in terms of the computational
complexities by comparing it with related schemes. Table 5 summarises the computation
comparison between our scheme and these related schemes. Note that we ignore the
computational complexity of operations that require very limited computation such as
concatenation.
A clear result of our analysis is that all other schemes require HTTPS in all phases.
Although HTTPS provide content confidentiality, it highly impacts the user’s browser
and web server performance. Our scheme only relies on HTTPS in the registration phase,
after that all subsequent messages are exchanged without using the HTTPS protocol.
Hence, our scheme’s computation cost is lower than the evaluated schemes.
In details, from Table 5 it is obvious to see that our scheme’s computation cost in the
registration phase is lower than that of PhoneAuth. The total time complexity of
PhoneAuth in this phase is 1THTTPS + 2TAKG + 1TCG + 1TCV. The proposed scheme only
needs 1THTTPS + 1TAKG + 1TPBKDF + 1TH + 3TX + 2TSE + 1TS + 1TR. Instead of using an
additional device (mobile phone), our scheme includes the complex cryptographic tasks
into the client cryptographic services. In the SSL/TLS RFC (IETF, 2008), the authors do
not include details on the registration process in client authentication. But primary this
process has to involve asymmetric key and certificate generation: 1TAKG + 1TCG. Hence,
the simplicity of users’ registration in scheme makes it more efficient than SSL/TLS
client certificate. In the login phase, while SSL/TLS client certificate authentication
requires less computation in comparison with other schemes including ours, the increased
time complexity in the proposed scheme is needed to share a temporary session secret
key that will be used instead of HTTPS to guaranty the authenticity integrity of
subsequent messages. The increased time complexity in the beginning of this phase
provides less computation in subsequent-requests authentication. It is evident from
Table 5 that the addition operations in the login and initial mutual authentication are
justified in less computation offered by our scheme in subsequent-requests
authentication. In particular, as we’ve discussed in Section 3.5 the subsequent-requests
authentication phase of the proposed scheme relies on HMAC and the required time
complexity is only 4TX + 2THMAC + 1TR.

5 Conclusions

Finally as we’ve discussed above, authentication on the web remains a challenging

security problem for both users and web applications. However, in this paper, we tried to
tackle this serious problem by proposing a new secure mutual authentication scheme for
web applications based on public key cryptography and other cryptographic primitives,
without sacrificing usability and deployability. Compared to related schemes, not only
does our scheme strengthen web authentication, but also allows most of the web
infrastructure to remain unchanged. Furthermore, the security analysis and performance
evaluation of the proposed scheme is more efficient and secure than any other schemes
cited in Tables 3 and 5.
62 Y. Sadqi et al.

References
Asimi, Y. et al. (2015) ‘New random generator of a safe cryptographic salt per session (RGSCS)’,
International Journal of Network Security, Vol. 18, No. 6, pp.1–11.
Bonneau, J. et al. (2012) ‘The quest to replace passwords: a framework for comparative evaluation
of web authentication schemes’, IEEE Symposium on Security and Privacy: Proceedings of
IEEE Symposium on Security and Privacy, pp.553–567, IEEE Computer Society, Washington,
DC, USA.
Cameron, K. and Jones, M.B. (2007) ‘Design rationale behind the identity metasystem
architecture’, ISSE/SECURE 2007 Securing Electronic Business Processes, pp.117–129,
Springer.
Czeskis, A. et al. (2012) ‘Strengthening user authentication through opportunistic cryptographic
identity assertions’, CCS’12: Proceedings of the 2012 ACM Conference on Computer and
Communications Security, pp.404–414, ACM, New York, USA.
Dacosta, I. et al. (2012) ‘One-time cookies: preventing session hijacking attacks with stateless
authentication tokens’, ACM Transactions on Internet Technology, Vol. 12, No. 1, pp.1–31.
Dietz, M. et al. (2012) ‘Origin-bound certificates: a fresh approach to strong client authentication
for the web’, The 21st USENIX Security Symposium: Proceedings of the 21st USENIX
conference on Security Symposium, pp.6–16, USENIX Association, Berkeley, CA, USA.
Franks, J. et al. (1999) ‘RFC 2617 – HTTP authentication: basic and digest access authentication’
[online] https://tools.ietf.org/html/rfc2617 (accessed 12 December 2014).
Fu, K. et al. (2001) ‘Dos and don’ts of client authentication on the web’, The 10th USENIX Security
Symposium: Proceedings of the 10th Conference on USENIX Security Symposium,
pp.251–268, USENIX Association.
Herley, C. (2009) ‘So long, and no thanks for the externalities: the rational rejection of security
advice by users’, NSPW’09: Proceedings of the 2009 Workshop on New Security Paradigms
Workshop, pp.133–144, ACM, New York, USA.
IETF (2008) RFC 5246 – The Transport Layer Security (TLS) Protocol Version 1.2 [online]
http://tools.ietf.org/html/rfc5246 (accessed 27 October 2014).
Liu, A.X., Kovacs, J.M. and Gouda, M.G. (2012) ‘A secure cookie scheme’, The International
Journal of Computer and Telecommunications Networking, Vol. 56, No. 6, pp.1723–1730.
Manulis, M., Stebila, D. and Denham, N. (2014) ‘Secure modular password authentication for the
web using channel bindings’, SSR 2014’: Proceedings of the 1st International Conference on
Research in Security Standardisation (SSR), pp.167–189, Springer , London, UK.
Marchesini, J., Smith, S.W. and Zhao, M. (2005) ‘Keyjacking: the surprising insecurity of
client-side SSL’, Computers & Security, Vol. 24, No. 2, pp.109–123.
Microsoft (n.d.) Introducing Windows CardSpace [online] http://msdn.microsoft.com/
en-us/library/aa480189.aspx (accessed 14 December 2014).
Mozilla (2011) Mozilla Persona [online] https://developer.mozilla.org/en-US/Persona
(accessed 26 October 2014).
RSA Laboratories (2000) RFC 2898 – PKCS #5: Password-Based Cryptography Specification
Version 2.0 [online] http://tools.ietf.org/html/rfc2898 (accessed 13 December 2014).
Sadqi, Y., Asimi, A. and Asimi, Y. (2014) ‘A lightweight and secure session management
protocol’, Lecture Notes in Computer Science (LNCS), Vol. 8593, pp.319–323.
Scambray, J., Liu, V. and Sima, C. (2011) Hacking Exposed Web Applications: Web Application
Security Secrets And Solutions, McGraw-Hill, New York.
 A secure and efficient user authentication scheme for the web 63

Schneier, B. (1996) Applied Cryptography, 2nd ed., John Wiley & Sons, Hoboken.
Sood, S.K., Sarje, A.K. and Singh, K. (2011) ‘Inverse cookie-based virtual password authentication
protocol’, International Journal of Network Security, Vol. 13, No. 2, pp.98–108.
Yang, L., Ma, J-F. and Jiang, Q. (2012) ‘Mutual authentication scheme with smart cards and
password under trusted computing’, International Journal of Network Security, Vol. 14, No. 3,
pp.156–163.