• Open Access

Robust password changing and DoS resilience for human-centric password authentication

Authors


ABSTRACT

In password-based or two-factor (password and smart card) authentications, password changing is one of common techniques used to improve the security of the systems protected by the password. However, the password-changing operations in existing password authentications either depend on the login phase or violate the common practice that an old password should not be valid for subsequent login after being updated. On the other hand, password mistyping is very common in reality, which may be random or be skewed by the adversary via technical means or social engineering manipulation [i.e., a kind of denial-of-service (DoS) attack]. In human-centric authentication mechanisms, password changing and DoS resilience are not marginal issues. The paper addresses the requirements of robust password changing in authentication and presents math formula, a password authentication scheme with robust password changing, DoS resilience, and card-compromise security. Thus, the proposal can be viewed as a suitable candidate instantiation for authentication services of human-centric security, by embedding in the computer and software systems. math formula also achieves other appealing features, such as self-healing ability and strong privacy protection, which may be useful for human-centric applications. Copyright © 2013 John Wiley & Sons, Ltd.

1 INTRODUCTION

To meet various security demands in computer networks, a number of security measures are well studied and employed [1-3]. Because smart cards are small enough, comparatively cheap, well standardized, and very tamper proof, many researchers explored smart card-based security [4, 5].

Entity authentication is the act of confirming the truth of an identity of an entity. Generally, there are three factors of authentication: something the users have (say, smart card), something the users know (say, password), or something the users are. One can use any factor of authentication alone or in combination with other authentication factors to have a stronger authentication, meaning that without any of the combined factors, authentication cannot take place successfully. The authentication process is embedded in the computer and software systems, by many different approaches. Two-factor authenticated key agreement schemes are amongst the most commonly used, where servers exchange keys with clients (or users) who use memorized short passwords and long cryptographic keys stored on smart cards to login [6-8]. Security of these authentication mechanisms relies on the assumption that no one can compromise the two factors simultaneously. The authentication should remain secure even if any one of the two factors is compromised [3, 5-8].

Motivation. One can easily find in the literature many password-based authentication schemes that provide the functionality of password-changing operation. Password changing is indeed one of the common techniques used to improve the security of the systems protected by a password. However, the password-changing operations in existing password authentications either depend on the successful run of a login phase, for example, [9, 10], or violate the common practice that an old password should not be valid for subsequent login after being updated, for example, [11]. Refer to Section 2 for more details.

On the other hand, password mistyping is very common in reality, which may be random or be skewed by the adversary via technical means or social engineering manipulation [a kind of denial-of-service (DoS) attack] [12]. When the user keys in the password, mistyping (no matter random or being skewed by the adversary) may happen, and the card reader treats some other value, as the expected one.

Therefore, for authentication services of human-centric security, we should consider the capabilities of password changing and DoS resilience at the same time. The paper addresses the requirements for updating password and presents math formula, a password authentication with DoS resilience and card-compromise security. The idea behind math formula is to combine the authenticated Diffie–Hellman technique [13] (which defeats the men-in-the-middle attack) and a variant of El Gamal encryption with provable security [14] (which preserves user privacy and prevents secret and sensitive information leakage from adversaries).

Main contributions. The proposal math formula enjoys the following advantages.

  • Explicit key confirmation: in math formula, each entity is assured that the other entity has actually computed the session key.
  • Initiator untrecability: in terms of user privacy protection, math formula provides initiator untrceability that is stronger than initiator anonymity and requires that any adversary should be not only infeasible to infer the identity of the initiator but also prevented from linking one (unknown) user interacting with the server to another transcript.
  • DoS attack resilience: math formula defeats DoS attack, meaning that anyone cannot impersonate a legal user to send information to the server who shall then reject the legal user to log in subsequently.
  • Resistance against offline attack: math formula is secure against offline password-guessing attack even when the keys stored on the card are compromised.
  • Robust password changing: math formula realizes robust password-changing operation and resists mistyping attack in the password-changing phase.

These appealing features make math formula a suitable candidate instantiation for authentication services of human-centric security, by embedding in the computer and software systems.

Roadmap. The rest of the paper is organized as follows. Section 2 addresses the requirements of robust password changing in a two-factor authentication. The proposal math formula is described in Section 3. We analyze in Section 4 the security of math formula, followed by the discussion of other functionalities in Section 5. Section 6 concludes the whole paper.

2 TOWARDS ROBUST PASSWORD CHANGING: THE REQUIREMENTS

In human-centric authentication mechanism, robust password changing should be a big issue, rather than a marginal property. Previous authentications, say [9-11], took little consideration on robust password changing. To ensure the usability and the security of practical applications, these requirements of password changing are reasonable and necessary:

  1. Only the user who knows the current password for his or her smart card has the capability of changing the password.
  2. Only the user who knows the current password for his or her smart card can update the password successfully.
  3. Once the password is updated successfully, the old password (associated with the old secret information on smart card) should be invalid for subsequent login.
  4. The password-changing phase is independent from the login phase, as they are different phases with different missions.

These issues are obligated to provide a robust password-changing operation. The password-changing phases of most existing password authentications violate some of these requirements and thus may be vulnerable to some attacks or performance degradation. For example, the schemes in [9, 10] violate requirement (iv), which results in an inefficient password-changing phase, whereas the scheme in [11] violates all the aforementioned requirements but the last one.

Note that the schemes that do not satisfy the first two requirements may be vulnerable to DoS attack. The DoS attack prevents or inhibits the normal use or management of communication facilities. This attack may act on a specific user. For instance, an adversary may perform this attack to cause the server to reject the login of a specific user. Take for example the scheme in [11], where the password-changing phase consists of a single operation of replacing on the card the value V with V = V ⊕ h(PW) ⊕ h(PW), if the card owner wants to change his or her password from the old one PW to the new one PW and the keys in them. Herein, V is a value stored on the card, and h is a hash function. One subtle flaw of this noninteractive password changing results from the fact that the password cannot be expected to be read reliably into the computer or other card readers [12].

For example, password mistyping is very common in reality, which may be random or be skewed by the adversary via technical means or social engineering manipulation [12]. When the user keys in the password PW, mistyping (no matter random or being skewed by the adversary) may happen, and the card reader treats some value, say PW∗ ∗, as the expected PW. Then, V∗ ∗ = V ⊕ h(PW) ⊕ h(PW∗ ∗) would cause an authentication failure in the next session. In practice, this could happen in a malicious model. Suppose that an adversarial colleague of the user wants to make the user's card ineffective, he or she can launch the attack at the lunch time. Namely, he or she may run the password-changing program by inputting two random strings PW1 and PW2, and then the card becomes useless because the user knows neither PW1 nor PW2.

3 TOWARDS ROBUST PASSWORD CHANGING AND COMPROMISE SECURITY SIMULTANEOUSLY: THE PROPOSAL SPCA

This section describes the proposal math formula that satisfies the requirements in Section 2, besides the security properties of authentication schemes [15]. Thus, the scheme can be viewed as a suitable candidate instantiation for authentication services of human-centric security, by embedding in the computer and software systems. The proposal math formula consists of five stages: parameter generation, registration, precomputation, login, and password-changing phases.

3.1 Parameter generation

  1. Server math formula chooses a large prime p, generates an elliptic curve E: y2 = x3 + ax + b, where math formula s.t. 4a3 + 27b2modp ≠ 0, and finds a point G of large order n on the elliptic curve E.
  2. math formula selects a random number math formula and computes the public key P = x ⋅ G.
  3. math formula holds x as its secret master key and makes the parameters (p,E,G,P) public.
  4. The server also publishes hash functions h, H, math formula, math formula, and math formula, which will be used in other phases.

3.2 Registration

As showed in Table 1, the registration phase is performed between the user math formula and the server math formula.

Table 1. Registration phase of SPCA.
math formula math formula
choose random b, α  
ku = h(PW||b)  
 math formula 
  ks = h(P||x)
  choose random cu
  t = H(ks, IDu, ku, cu)
  αu = α
  append (IDu, αu, cu) to T
 math formula 
card contains (t,P,b,α)  
  1. User math formula: randomly choose b and α, compute ku = h(PW||b), and send IDu, α, and ku to math formula, where PW and IDu are the password and the identity of math formula, respectively.
  2. Server math formula: given ku and IDu from math formula, compute ks = h(P||x) and t = H(ks, IDu, ku, cu), where cu is a random number. Set αu = α, append (IDu, αu, cu) to the registration table T, and send (t,P) to math formula.

Eventually, the smart card contains (t,P,b,α), and the server holds the verification table T = {(IDu, αu, cu)} for its users.

In math formula, the server math formula need not store a password table for its users. Note that if a password table is used on the server side, the adversary may find some clever way to crack the passwords. Indeed, there are various ways to obtain the password table, for example, dumping memory at a convenient time and searching the system backup tapes.

3.3 Precomputation

Before math formula and math formula take part in the login protocol, they execute the following computations to enhance the performance.

  • User math formula: randomly choose ru and compute M1 = ru ⋅ G and M2 = ru ⋅ P.
  • Server math formula: randomly choose rs and compute M3 = rs ⋅ G.

These precomputed points are only valid for one login session.

3.4 Login

After the precomputation, math formula holds M1 = ru ⋅ G, M2 = ru ⋅ P, and math formula holds M3 = rs ⋅ G, ks = h(P||x). These quantities may be used in the following login protocol initiated by the user. Table 2 shows the interactions between math formula and math formula.

Table 2. Login phase of SPCA.
math formula math formula
A = M1  
α = α + 1  
math formula  
 math formula 
  math formula
  If ∃ (IDu, αu, cu) ∈ T s.t.
  α > αu
  σ = H(A, IDu, α, ku, H(ks, IDu, ku, cu))
  then αu = α
  M4 = rs ⋅ A
  math formula
  C = M3,  X = H(K,  C)
 math formula 
math formula  
math formula  
Y = H(K,X)  
 math formula 
  math formula
  1. User math formula: let A = M1, update α = α + 1, and then compute
    display math(1)
    where ku = h(PW||b), on input PW, b, t, α and the precomputed M1, M2. Send (A,B) to math formula.
  2. Server math formula: on receiving (A,B), parse math formula as IDu||α||ku||σ. If there exists in T a record (IDu, αu, cu) starting with IDu s.t. α > αu and
    display math(2)
    execute the following (otherwise abort):
    1. Update αu = α in T and compute M4 = rs ⋅ A, math formula.
    2. Let C = M3, X = H(K,C) and send (C,X) to math formula.
  3. User math formula: on receiving (C,X), compute math formula and then check math formula: if not, abort; otherwise, set K as the session key and send Y = H(K,X) to math formula.
  4. Server math formula: if Y = H(K,X), set K as the session key; otherwise, abort.

The login protocol uses αu the counter maintained by the server. This ensures the freshness of each login session and protects math formula from the replay attack. Given a valid login transcript, the adversary cannot mount offline dictionary attack as ku, the only quantity contains knowledge about PW, and its related hash value are encrypted by a variant of El Gamal encryption with provable security [14]. Meanwhile, the authenticated Diffie–Hellman [13] embedded in the protocol is responsible for the session key's security to defeat the men-in-the-middle attack.

3.5 Password-changing operation

This phase is invoked whenever math formula wants to update his or her password from PW (and the nonce b) to PW′ (and the nonce b′). Table 3 shows the interactions between math formula and math formula.

Table 3. Password-changing phase of SPCA.
math formula math formula
A = M1  
α = α + 1  
B = (IDu||α||ku||ku||H(A, IDu, α, ku, ku, t))  
math formula  
 math formula 
  math formula
  If ∃ (IDu, αu, cu) ∈ T s.t.
  α > αu
  σ = H(A, IDu, α, ku, ku, H(ks, IDu, ku, cu))
  Then
  αu = α
  math formula
  choose random cu
  t′ = H(ks, IDu, ku, cu)
  math formula
 math formula 
math formula  
math formula  
math formula  
b = b  
math formula  
 math formula 
  If Y = H(Kc,X) then cu = cu
  else replace the record (IDu, αu, cu)
  with (IDu, αu, cu, cu)
  1. User math formula: let A = M1, update α = α + 1, and then compute
    display math(3)
    where ku = h(PW||b) and ku = h(PW′||b′), on input PW, b, PW′, b′, t, α and the precomputed M1, M2. Send (A,B) to math formula.
  2. Server math formula: on receiving (A,B), parse math formula as IDu||α||ku||ku||σ. If there exists in T a record (IDu, αu, cu) containing IDu s.t. α > αu and
    display math(4)
    where ks = h(P||x), execute the following (otherwise abort):
    1. Update αu = α in T and compute math formula.
    2. Randomly choose cu and compute t′ = H(ks, IDu, ku, cu), where ks = h(P||x).
    3. Compute math formula, X = H(Kc,C) and send (C,X) to U.
  3. User math formula: on receiving (C,X), compute
    display math
    check math formula: if not, abort; otherwise, obtain t′ = H(ks, IDu, kucu) by decrypting C with math formula, update t = t′ and b = b′, and send math formula to math formula.
  4. Server math formula: given Y, check math formula; if not, replace (IDu, αu, cu) by (IDu, αu, cu, cu); else, update cu = cu.

In the login or the password-changing phases, once a user submits to the server the tuple (A,B) containing IDu identical to that of (IDu, αu, cu, cu), math formula deletes the one of cu, and cu that cannot pass the verification equation (2) or (4) in Steps 2 maintains a valid triple in the registration table T and continues the remaining steps as usual. Therefore, the user can use only one of (PW,  b,  t) and (PW′,  b′,  t′) to login or change the password later.

The password-changing mechanism is independent from the proposed login protocol. In some existing authentications (e.g., [9, 10]), it is required that the user and the server first run the login protocol to obtain session key, which is then used to encrypt secret information for updating the password. Therefore, the computation and communication costs are much higher than those of math formula (which does not need such a session key and thus reduces the overload of computation and communication). In some other authentications (e.g., [11]), although these two phases are independent, the password-changing operation is vulnerable to mistyping attack that leads to authentication failure in the subsequent session (refer to Section 2 for more details). In the proposed password-changing phase, the adversary without the knowledge of the correct password cannot succeed in running the password-changing phase, as will be analyzed in the coming section.

4 SECURITY ANALYSIS OF THE PROPOSAL

This section gives the security analysis of math formula in terms of authentication and checks whether math formula satisfies the requirements of robust password changing described in Section 2. In the succeeding text, we first give security model under which the proposal math formula is analyzed.

4.1 Security model

According to different resources that the adversary has, we consider the adversary's ability. For the user in the system, an adversary might utilize the following resources to launch its attack:

  • Card compromise: the adversary can compromise the user's card including its secret data.
  • User compromise: the adversary can compromise the user's passwords.
  • General case: the adversary has neither the user's card nor the password.

The adversary might also compromise the server and thus obtain the master key of the server. However, most of existing authentication schemes assume that the server's master key is well protected and therefore ignore this case, whereas, if the server is compromised, the adversary can do anything without the user's permission. It is desirable that given the transcript of the session, the adversary cannot infer any session key exchanged before the server is compromised. We call it as forward secrecy under the server-compromise attack. The schemes in [9, 10] pay no attention to and are thus vulnerable to this attack.

Generally, the adversaries are classified into two types: static and adaptive. An adversary is static if it can just eavesdrop over the channel and adaptive if it can modify, delete, and insert the messages on the public channel. Hereafter, we focus on adaptive adversary for security analysis as it is more powerful than static one.

4.2 Authentication security of SPCA

The security results are stated in the following claims. Herein, we say that a scheme is secure if there exists no adversary can impersonate either the server or the user or deduce useful information about the session keys in the login phase.

Claim 1. SPCA is secure against adaptive adversary under card-compromise attack.

Proof. If the smart card is compromised, the last protection for the user is the password PW. Without PW, the adversary cannot generate a valid (A,B) that can pass the verification of Step 2 in the login phase with probability greater than math formula for the password dictionary math formula. Moreover, a used valid (A,B) generated by the user cannot be used later as the server already updated αu, making the used (A,B) invalid in the verification to be executed.

From a valid transcript of the login phase, the adversary cannot mount offline dictionary attack because ku, the only information that contains knowledge about PW, and its related hash value are encrypted by a variant of El Gamal encryption with provable security [14]. Therefore, the login phase does not leak any information for PW. Meanwhile, the session key's security is also achieved by embedding a fresh Diffie–Hellman problem [13] in the protocol.

The adversary cannot impersonate the server either if the smart card is compromised. This is due to the design trick that in Step 2, the server should compute x ⋅ A to generate the session key K. Without the knowledge of the master key x, the adversary cannot do this because of the difficulty of computing Diffie–Hellman problem [16].

Therefore, math formula is secure against adaptive adversary under card-compromise attack.

Claim 2. math formula is secure against adaptive adversary under user-compromise attack.

Proof. Without the smart card that contains (t,b,P,α), the adversary knowing the password PW cannot generate a valid (A,B) to initialize the session talk because the server uses t to verify (A,B) that should be generated with t. Moreover, previously used (A,B) cannot pass the verification because αu was updated. Therefore, no adversary can impersonate the server and deduce any useful information on the session key, given the corresponding transcript of interaction because of the hardness of the Diffie–Hellman problem [16] and security protection of El Gamal encryption [14]. □

Claim 3. math formula is secure against adaptive adversary in the general case.

This claim sounds naturally because an adversary breaking math formula in the general case can also break math formula under card-compromise attack and user-compromise attack. □

Claim 4. math formula achieves forward security against adaptive adversary under user-compromise and server-compromise attacks.

Proof. The session key K of math formula roots in a Diffie–Hellman tuple (G,P,M1,M2) and an authenticated fresh Diffie–Hellman tuple (G,M2,M3,M4) [16]. Therefore, once K is generated, no one can obtain its useful information, thanks to the security of the fresh Diffie–Hellman problem. Actually, even if the server's master key, the smart card, and the password are all compromised, the adversary cannot obtain any information about the session keys previously generated. □

Claim 5. math formula can defend DoS attack in the login phase and password-changing phase.

Proof. In the two phases of math formula, the messages sent in each move are authenticated with hash value (which can be viewed as a hash message authentication code). In the login phase, (A,B) contains the authenticator of A, IDu, ku, and α; (C,X) is an authenticated encryption ciphertext; and Y is to confirm the received messages. Therefore, it is difficult for an adversary to initialize a DoS attack without being detected. The password-changing phase is designed via the same idea that leads to the immunity of DoS attack as well. □

4.3 Robust password changing

Obviously, the proposed password-changing mechanism is independent from the proposed login protocol. Besides, it also satisfies other requirements in Section 2.

Claim 6. The password-changing protocol of math formula achieves all the requirements of robust password changing.

Proof. In math formula, the password-changing phase is independent from the login phase; therefore, the security of password changing does not rely on that of session key agreement. (A,B) sent in the first move of the password-changing protocol is a ciphertext of a variant of El Gamal encryption that encrypts IDu, α, ku, ku and the authenticator that authenticates these data and the token t issued by the server. Without knowing PW and t, anyone cannot generate (A,B) that could pass the subsequent verifications of the server. Resending or replaying (A,B) is useless as we use a one-time counter αu (unknown to outsiders) embedded in (A,B). Moreover, without (PW′, b′) and (PW, b), anyone cannot update the token t and b. Therefore, the password-changing protocol achieves security requirements (i) and (ii) in Section 2.

On the other hand, once the user ends the password-changing protocol successfully, the data on the old card and the old password PW become invalid as t, issued by and only by the server, has changed. This token also contains the new password and a random number cu chosen by the server. Thus, the password-changing protocol achieves security requirement (iii) in Section 2.

As the password-changing mechanism itself provides authentication service, authentication-related properties of the password-changing mechanism are similar to those of the login protocol. □

5 OTHER FUNCTIONALITIES

As noted in [10, 17-19], protection of personal information is very important in public communication networks.

Claim 7. math formula provides strong privacy protection for the user, achieving initiator anonymity and initiator untraceability.

Proof. In the login phase, the user sends (A,B) to the server to initialize the login session, where math formula is a ciphertext of a variant of El Gamal encryption [14] that encrypts IDu, ku, the authenticator H(A, IDu, α, ku, t), and other related information. Note that (C,X) and Y transmitted during the session are independent from IDu. Under the assumption that math formula is a random oracle, B and any random string of the same length are indistinguishable if M2 is unknown to the adversary. Thus, the variant of El Gamal encryption leads to initiator untraceability, and no one can distinguish between two users in which one is the real initiator. □

Another important feature of math formula is self-healing under card-compromise attack. Recall that smart cards are vulnerable to theft/card-compromise attack. math formula provides self-healing service for the user even if the smart card is compromised.

Claim 8. math formula provides self-healing functionality.

Proof. When a smart card is compromised, a backup of the card can be used to run the password-changing protocol. After the user successfully updates the password, the data on the backup are fresh as well. Then, any adversary that uses the original data cannot login to the server successfully. Note that if the users periodically change the passwords, they need not care about the card-compromise attack, thanks to the self-healing functionality of math formula.

It is clear that math formula also provides some other appealing features such as no password table, no time-synchronization problem, adaptively chosen password, conveniently revoking lost card [11], and mutual authentication.

6 CONCLUSION

The paper focuses on human-centric authentication services: password changing, DoS resilience, and self-healing. With smart card, we present a password authentication scheme that strengthens the requirements of robust password changing in existing authentication schemes. The proposal not only offers robust password changing, card-compromise security, and immunity to DoS attack but also achieves additional functionalities such as strong anonymity protection and self-healing ability under card-compromise attack.

ACKNOWLEDGEMENTS

This work has been supported by the National Natural Science Foundation of China (Grant Nos. 60703031, 61172085, 61103221, 61021004, 61070249, U1135004, 61170080 and 11061130539).

Ancillary