Revisiting Anonymous Two-Factor Authentication Schemes for IoT-Enabled Devices in Cloud Computing Environments

Investigating the security pitfalls of cryptographic protocols is crucial to understand how to improve security. At ICCCS’17,Wu and Xu proposed an efficient smart-card-based password authentication scheme for cloud computing environments to cope with the vulnerabilities in Jiang et al.’s scheme. However, we reveal that Wu-Xu’s scheme actually is subject to various security flaws, such as offline password guessing attack and replay attack. Besides security, user friendly is also another great concern. In 2017, Roy et al. found that in most previous two-factor schemes a user has to manage different credentials for different services and further suggested a user-friendly scheme which is claimed to be suitable for multiserver architecture and robust against various attacks. In this work, we show that Roy et al.’s scheme fails to achieve truly two-factor security and shows poor scalability. At FGCS’18, Amin et al. pointed out that most of existing two-factor schemes are either insecure or inefficient for mobile devices due to the use of public-key techniques and thus suggested an improved protocol by using only light-weight symmetric key techniques. Almost at the same time, Wei et al. also observed this issue and proposed a new scheme based on symmetric key techniques with formal security proofs in the random oracle model. Nevertheless, we point out that both Amin et al.’s and Wei et al.’s schemes cannot achieve the claimed security goals (including the most crucial goal of “truly two-factor security”). Our results invalidate any use of the scrutinized schemes for cloud computing environments.


Introduction
With the emerging paradigm of cloud computing and Internet of Things (IoT), various services are provided over the cloud and accessed by users from IoT-enable devices (e.g., mobile phones and smart watches). As cloud-based services can be accessed anytime and anywhere just with a connection to the Internet and IoT-enable devices are generally of resource-constrained nature, it is important and challenging to protect users and cloud servers from severe security threats, such as fraudulence, eavesdropping, and falsification, posed either by external attackers or malicious internal entities. To guarantee that the resources and services can only be accessed by legitimate parties, user authentication plays an important part in securing electronic transactions by acquiring collaborative evidence. In 2011, Hao et al. [1] suggested the first two-factor authentication scheme that is based on password and smart cards for the cloud computing environments. This initial work has brought about a number of enhanced proposals [2][3][4][5][6][7][8][9] with each different in terms of security [10], anonymity [11], usability [12], and efficiency [13].
Without loss of generality, we consider the most common client-server architecture in which two participants (i.e., a server and a user ) get involved in two-factor authentication [14]. User holds a memorable password and a smart card stored with some initial security parameters, and server only needs to keep some secret key material of the system. Since there is no need to keep a table with password-related verification information on the server side, the server is free from the threat of password dataset leaks and ameliorated from the burden of maintaining a large password dataset.

Security and Communication Networks
This feature that makes this type of schemes rather desirable, considering that there are incessant leakages of password databases from large websites [15]. The most important security goal of this kind of schemes is the so-called "two-factor security" [16]. This security concept essentially means that only the user who has the smart card and knows the correct password can be verified by the server.
Most of existing two-factor schemes (e.g, [5,8,23]) for cloud computing are built on the basis of generic two-factor schemes like [3,24]. Nevertheless, past research [20,[25][26][27] have, again and again, proved that designing a smartcard-based password authentication scheme that can attain "two-factor security" is a tough task. In 2009, Xu et al. [28] developed a smart-card-based password authentication scheme relying on the intractability of computational Diffie-Hellman problem, and stated that their scheme is able to support "two-factor security" under the hypothesis that smart cards can be tampered. In addition, their scheme was "proved secure" in the random oracle model. However, later on Sood et al. [29] found that Xu et al. 's scheme cannot resist against user impersonation attack if the parameters kept in the smart cards can be extracted, invalidating Xu et al.'s claim of ensuring "two-factor security". In 2010, Song [30] independently found this severe flaw in Xu et al.'s scheme. Furthermore, Song presented an improvement to counter the problem emerged in Xu et al.'s scheme.
In 2012, Chen et al. [31] pointed out that various security drawbacks still existed in both Sood et al. 's [29] and Song's [30] schemes. More specifically, Sood et al.'s scheme is susceptible to server impersonation attack and Song's scheme suffers from offline password guessing attack, in case the attacker can obtain those sensitive information kept in the smart card. Chen et al. [31] also put forward an improved scheme and argued that their scheme is robust under the condition that the sensitive data in smart card has been revealed by the attacker. It should be noted that recent rapid developments in side-channel attacks have proved that the sensitive information stored in general commercial smart cards could be extracted by power analysis or reverse engineering [32,33]. Based on a weak yet realistic assumption, Chen et al. 's scheme [31] appears very practical.
However, soon after Chen et al. 's scheme [31] was presented, Ma et al. [20] figured out that it is susceptible to exactly the same problem (i.e., prone to offline password guessing attack and no supply of forward secrecy) with the original scheme (i.e., Song's scheme [30]). Based on their past experience of protocol design and analysis, for the first time Ma et al. [20] suggested three generic principles for designing a secure and efficient two-factor protocol, namely, the public-key principle, the forward secrecy principle, and the security-usability balance principle. Unfortunately, none of the two-factor authentication protocols mentioned above can satisfy all these three design principles and, moreover, as we illustrate, all the schemes studied in this work fail to comply with at least one of these principles.
In 2017, Wu and Xu [17] also observed that previous schemes (e.g., [30,31]) are vulnerable to various security loopholes (e.g., user impersonation attack and insider attack) and also suggested an enhanced scheme. Wu-Xu argued that their new scheme not only eradicates the security pitfalls being overlooked in previous schemes but also maintains strengths of previous schemes. Notwithstanding their claims, we will show that this scheme still has several serious defects being overlooked: (1) it cannot withstand offline password guessing attack if the data in smart card can be revealed, which means that the primary goal of "truly two-factor security" cannot be satisfying; (2) it is subject to replay attack; (3) it ensures no timely typo detection.
Later on, Roy et al. [19] found that, in Tsai-Lo's scheme [34], a user has to manage different credentials for different services and further suggested a user-friendly scheme which is claimed to be suitable for multiserver architecture and robust against various attacks. Therefore, this protocol shows a good application potential in multiserver cloud computing environments. In this work, we show that Roy et al. 's scheme fails to achieve truly two-factor security and cannot preserve user untraceability. We observe that the first failure of Roy et al.'s scheme is due in large part to the noncompliance with Ma et al. 's [20] security-usability tradeoff principle. Our attacks highlight the necessity of being aware of basic protocol design principles.
In 2018, Amin et al. [21] pointed out that previous schemes (e.g., [35][36][37]) are vulnerable to various security loopholes (e.g., off-line password guessing attack, insider attack and user impersonation attack) and also developed a new scheme for distributed cloud computing environments. Amin et al. argued that their new scheme not only eradicates the security pitfalls being overlooked in previous schemes but also maintains strengths of previous schemes. Notwithstanding their claims, we will show that this scheme still has several serious defects being overlooked: (1) it cannot withstand offline password guessing attack if the data in smart card can be revealed, which means that the primary goal of "truly twofactor security" cannot be satisfied with; (2) it provides no forward secrecy; (3) it ensures no user untraceability.
Very recently, Wei et al. [23] observed that most of previous schemes (e.g., [36][37][38][39][40]) only provided some heuristic security arguments and little attention has been paid to the formal treatment of protocol security. Unsurprisingly, most of them are vulnerable to various security loopholes. Thus, they suggested an enhanced scheme for cloud computing without using computation-expensive public key operations. They employed a new cryptographic primitive called authenticated encryption scheme which can guarantee both message confidentiality and integrity, and showed that their new scheme can be provably secure in the random oracle model. Though this scheme is armed with a formal proof, we will show that this scheme still has several serious defects being overlooked: (1) it cannot achieve the primary goal of "truly two-factor security"; (2) it provides no forward secrecy; (3) it ensures no user untraceability.
The remainder of the paper is organized as follows: we revisit Wu-Xu's scheme in Section 2; we describe the security loopholes of Roy et al. 's scheme in Section 3; Amin et al. 's scheme is scrutinized in Section 4 and Wei et al. 's scheme is cryptanalyzed in Section 5. Finally, we conclude the paper in Section 6.  [17] in ICCCS 2017. Their scheme consists of four phases: initialization, registration, authentication, and password change. For ease of presentation, we will follow the notations in Wu-Xu's scheme as closely as possible and summarize the notations in Table 1.

Registration Phase.
At the very start, the server generates a random positive integer ∈ * and a symmetric key cryptosystem with (.) and (.) and then selects a secret key , and two one-way hash functions ℎ(.) and ℎ 1 (.).

Login and Mutual Authentication Phase.
When wants to login, the following operations will be performed: Step 1.
inserts the smart card into card reader and inputs and .

Cryptanalysis of Wu-Xu's Scheme.
In this section, the security loopholes of Wu-Xu's scheme [17] will be pointed out. More specifically, it is prone to offline password guessing attack and suffers from replay attack, which makes this scheme unpractical for real use. Before giving the detailed security analysis, we first define the various adversary models for smart-card-based password authentication.

Adversary Models.
To analyze the security provisions of password-based authentication schemes using smart cards, generally three assumptions about the attacker's capabilities are made since the landmark work of Yang et al. [24], and we summarize them as follows: Assumption 1. The malicious attacker M is able to eavesdrop, delete, insert, modify, or block any transcripts communicated in the public channel. That is to say, the communication channel between the common users and the server can be completely manipulated by M. This well complies with the standard adversary model that is widely accepted for distributed computing [41].
Assumption 2. The malicious attacker M can somehow get the victim user's smart card and use side-channel attack techniques to acquire sensitive security parameters from the card memory, which is reasonable according to the recent research developments in side-channel attacks [32,33].
Assumption 3. User's password space is very constrained and the malicious attacker M can offline enumerate it. To be user-friendly, most protocols (e.g., the ones in [3,24,[42][43][44]) enable the users to select their own password at will in the initial process of registration or later process of password change. Because human beings are incapable of memorizing random strings, instead they are likely to choose passwords that relate to their personal lives or short strings for convenience. As a result, these human-generated passwords are often very weak and belong to a small dictionary [45][46][47].
Note that the nontamper resistant assumption about smart cards are conditional, i.e., under the conditions that (1) smart cards have somehow been in the possession of the attacker for a relatively long time (e.g., at least a few days), which should be sufficient for launching a side-channel attack; (2) the user is not on the scene; otherwise the user will observe the attack, for side-channel attacks generally need special instruments and professional/particular operations. This is why smart cards are superior to memory sticks, even though nontamper assumption about smart cards has been made: memory sticks are nontamper resistant unconditional. See more explications in [48].
Obviously, if both Assumptions 2 and 3 hold simultaneously, then an attacker (without any other assumptions/abilities) can successfully impersonate a victim user and any scheme is trivially insecure. Therefore, it is widely regarded that attackers should not be granted to obtain a victim user's smart card as well as his password [3,24,49].
In [17], Wu and Xu reported that their scheme is secure under the above three assumptions. For example, they stated that their scheme can withstand offline password guessing attacks even if the security parameters in smart card have been extracted. However, contrary to their claims, we will illustrate that this scheme is still vulnerable to offline guessing as well as other pitfalls. Based on the above listed assumptions, we cryptanalyze the security provisions of Wu-Xu's scheme in the following and assume that M can extract the secret data { 1 , 2 , ℎ(⋅), (⋅), (⋅)} stored in 's smart card, and M can also eavesdrop the messages { 4 , , 5 } exchanged between the parties.

Offline Password Guessing Attack.
It is known that password-based authentication schemes are apt to be subject to two kinds of attacks regarding guessing [16,25], i.e., offline password guessing and online password guessing, due to the limited size of the password space. Among them, the online guessing is relatively easy to detect due to the abnormal, large number of login requests issued by the attacker against the victim account within a short duration, and thus it can be countered by rate-limiting [50].
It is worth noting that when targeted online password guessing [47] is considered, attackers will no longer need to launch a large number of login attempts to try candidate passwords. Instead, targeted online password guessing attacks are rather effective and, as reported by Wang et al. [47], the attacker M can have an over 20% of success rate within 100 login attempts against normal users, if M has obtained some personal information (e.g., name, birthday) of the victim user.
As a quick response to the results of [47], the US Digital identity guideline NIST 800-63B [51] has been revised and the following sentence was removed: "online guessing can be readily addressed by throttling the rate of login attempts permitted" (see more details in [52,53]). Further, NIST 800-63B proposed four countermeasures such as CAPTCHA, exponential time delay, and risk-based authentication (see Section 5.2.2 of [51]).
In contrast, offline password guessing attack cannot be easily detected. In this attack, the attacker M first attempts to look for some pieces of information that can be exploited as the comparison target of his password guesses and then locally determines the exactly correct password by repeatedly testing all the candidates. Since this attack is executed without online communication with the server, there is no means for the server to detect and thwart. In all, no matter in trawling or targeted online guessing, M needs to interact with the server and there is the possibility that M may be detected, but in offline password guessing there is no such possibility. Consequently, offline password guessing is a more serious threat if password-related information has been leaked.
Wu and Xu [17] claimed that an attacker is unable to, in an offline manner, determine a user's password even if the sensitive data 1 has been revealed from user's smart card. However, the following attacking procedure illustrates that this claim is not tenable. Suppose that 's smart card is lost/stolen and the attacker M obtains it. Then M extracts the content { 1 , 2 , ℎ(⋅)} by using the methods introduced in [33]. The following procedure describes our proposed offline password guessing attack: Step 1. M choose a pair ( * , * ) from the identity space D and dictionary space D , respectively.
Step 5. M decrypts 5 by using * 3 to obtain ⊕ 1 ⊕ , where 5 is eavesdropped from the open channel. Step Step 7. M examines the authenticity of ( * , * ) pair by Step 8. M returns to Step 1 of this procedure until the right pair of ( , ) is obtained or all pairs in D × D are exhausted.
It is obvious that the above procedure is with a time complexity of {O(|D | * |D |)} * ( + 4 + 7 ), where , , and denote the execution time of modular exponentiation, hash, and XOR operation, respectively. Based on the results reported in [16,54], the offline password guessing attack is able to be carried out in seconds on a common computer, for in practice the size of identity space D and the size of dictionary space D are rather limited and M could try all the possible passwords through an offline method [20,49]. All in all, an type II attacker M can guess ( , ) within polynomial time bound; it follows that our suggested attack is indeed effective.

Replay Attack.
Resistance to replay attack is a very basic security goal of any cryptographic protocol [16,24]. However, Wu-Xu's scheme fails to achieve this goal. More specifically, Wu-Xu's scheme employs random numbers but not timestamps to achieve the freshness of messages. Yet, this scheme has only two protocol flows, making it inherently vulnerable to replay attack. As is well known, any two-flow random number based scheme is unable to achieve explicit authentication while resisting replay attack, because M can simply replay the first message of a successful protocol run to impersonate the legitimate user, and the server can never know whether the replayed message is fresh or not unless the server maintains a table of all received messages. However, maintaining a table of all received messages is practically undesirable. In all, replay attack is quite realistic against Wu-Xu's scheme.

Review of Roy Et Al. 's Scheme.
In this section, we first concisely review Roy et al. 's scheme [19] proposed in 2017. This scheme is an improvement over Tsai-Lo's scheme [34] and aims to attain forward secrecy that is lacked in Tsai-Lo's scheme. Roy et al. 's protocol involves three participants, i.e., the mobile user ( ), the cloud server ( ), and registration center ( ). There are five phases in their scheme: registration, login, authentication and key establishment, password change, and revocation of mobile device. The notations and initial system parameters employed in Roy et al. 's scheme are same as employed in the scheme of Wu-Xu (see Table 1).

Mobile User Registration
Step 1.
chooses her identity , password , biometrics , and two 128-bit random numbers and .
Step 4. selects an 1024-bit master secret key for server .
also selects an 1024-bit random number for each and pair.
selects a unique and random temporary identity for and saves server key-plus-id combinations { , ( , , ) | 1 ≤ ≤ } in mobile device of .
Finally, stores , 1 , 2 , s, s, and s into her own mobile device, and deletes s, , and s from the mobile device.

Cloud Server Registration
Step 1.
chooses her identity .
Step 3. provides the master secret key to each .
Step 4. For all s, the saves the credentials { , ( , )} (for 1 ≤ ≤ ) in database of , and also stores { , } in the database of .
Finally, saves pair ( , ) in its own database, where is the serial number of 's mobile device.

Login Phase.
When wants to login to , the following operations shall be executed: Step L1.
inputs her identity , password , and biometrics into her own mobile device. computes = ( , ) with through the fuzzy extractor reproduction procedure and generates = 1 ⊕ ( ‖ ) with the stored parameter 1 , .
also generates = ⊕ using the device parameter .

Authentication Phase.
In this phase, and mutually authenticate each other and establish a session key.
Since this phase is unrelated to our discussions, we omit it.

Flaws in Roy Et Al.'s Scheme.
Recall that the three assumptions listed in Section 3 are also clearly made in Roy et al. 's scheme. However, we observe that this scheme still remains feasible for an attacker to offline guess a user's password. This means that the primary goal of "truly twofactor security" cannot be satisfied. In addition, the scheme cannot provide forward secrecy and sound scalability.

Offline Password Guessing Attack.
Noting that Roy et al. 's scheme [19] is originally a three-factor one, here we are only interested in its two-factor version by assuming that the third factor (i.e., the biometric) has been known to A. This is realistic as users' biometrics are constant during their lives, and how to protect user biometric template is still an open issue [55]. We find that this scheme cannot achieve truly twofactor security: it is subject to two types of offline password guessing attack. This in turn indicates that it cannot achieve truly three-factor security.
Type-I Attack. Suppose 's biometric and the secret parameters { 1 , 2 , , ℎ(⋅)} stored in the smart card are somehow obtained by A. At this point, A can find out 's identity and password as follows: Step 1. Guesses 's identity * and password * from dictionary space D and D .
Step 4. Checks the validity of ( * , * ) by comparing the calculated 2 * with the extracted 2 .
The time complexity of this attack is O(|D | * |D | * 2 + ) [3,16]. Generally, it is only needed to calculate the biohashing function once; thus can be ignored in practice. According to the running time in [16], A may complete the above attacking procedure within 17.6 days on a Laptop. This issue arises due to the inherent "usability-security tension": to achieve local password change (i.e., C-2 in [3]) and timely typo detection (i.e., C-9 in [3]); there is an explicit password verifier 2 = ( ‖ ‖ ‖ ) stored in 's smart card, yet this verifier leads to a Type-I offline password attack.
To eliminate this security issue without loss of usability, a promising countermeasure is to adopt the "fuzzy-verifier" technique [20] and store 2 = ℎ(( ( ‖ ‖ ‖ )) mod ) in 's smart card, where specifies/confines the capacity of ( , ) pair, 2 4 ≤ ≤ 2 8 . As a result, even if A gets 2 , she can not figure out the correct ( , ) from the above attack, because there will be |D * D |/ ≈ 2 32 candidate ( , ) pairs that make 2 * = 2 in Step 4. To further identify the exactly correct ( , ) pair, A needs to interact with the server, and we can adopt the "honeywords" technique [3,56] to confine A's advantage to a very limited value.
Type-II Attack. In the above attack, A does not need the protocol messages. In this attack, we assume that A can somehow obtain user's smart card and extract its secret parameters { 1 , 2 , , , ℎ(⋅)} and also can eavesdrop the login messages { * , 1 , 1 , } from the public channel. Now, A can offline guess 's password and identity simultaneously as follows: Step 1. Guesses the value of * , * from dictionary space D and D .
Step 6. Checks the correctness of ( * , * ) by comparing if the computed * 1 equals the intercepted 1 .
Step 7. Repeats Steps 1∼6 of the above procedure until find the correct value of ( * , * ).
The time complexity of the above attacking procedure is O(|D | * |D | * (5 + )), and A may complete the procedure within 44 days on a Laptop. In comparison, the Type-I attack is more practical.

No Forward Secrecy.
A scheme that supports forward secrecy ensures that even after the long-term private key(s) of one or more participants were leaked, previously agreed session keys remain secure [27]. This is important, especially when considering the serious situations of today's clouds like the compromise of cloud servers (e.g., [15]).
If an attacker M has obtained the server 's longterm key from the breached server and intercepted the messages { * , 1 , 1 , } that are exchanged between and 's authentication process from the public channel. M is able to figure out the session key using the following method: Step 1. M computes = ( ‖ ) and = * ⊕ ( ‖ ) Step 2. M computes Step 3. M calculates the session key = ( ‖ ‖ ‖ 1 ‖ ‖ ‖ ).

Security and Communication
With the session key computed, the entire session will be no secret to M.

Revisiting Amin Et Al.'s Scheme
In 2018, Amin et al. [21] pointed out that previous schemes (e.g., [35][36][37]) are vulnerable to various security loopholes and developed a new scheme for distributed cloud computing environments. However, here we show that this scheme still has several serious defects being overlooked (i.e., offline password guessing attack, no forward secrecy, and no user untraceability).

Cloud Server Registration Phase.
The registration phase is partitioned into two parts: cloud server registration and user registration. When the cloud server registers, chooses her identity , a random nonce , and sends ⟨ , ⟩ to . Upon getting 's registration request, the control server computes = ℎ⟨ ‖ ⟩, = ℎ( ‖ ), and sends ⟨ ⟩ to over a secure channel. Finally, keeps the secret data ⟨ , ⟩ in a secure place (e.g., a usb-key).

Login Phase.
first inputs the smartcard into a card reader and keys * and * on the reader. Then, calculates * (2) Then, the card reader checks whether ( * ? = ). If ( * == ), it means that ( * = ) and ( * = ). Then, produces a 128 bit random nonce and computes where is the identity of the cloud server from which by wants to login. Then, sends the login request ⟨ , , , , ⟩ to publicly.

Authentication Phase.
This phase is to achieve mutual authentication and key agreement among , , and .
Step 1. first verifies whether ( − < △ ), where is the cloud server's current timestamp and △ is the allowed transmission delay time. If the equality is not true, rejects the connection; otherwise, generates a 128 bit random nonce and computes Then, sends ⟨ , , , , , , , , ⟩ to the over a public channel.

Security and Communication Networks
Once again, checks ( * ? = ). If ( * == ), deems as legal; otherwise, it rejects the connection. Then, selects a 128 bit random nonce and computes where is the agreed session key. Then, sends ⟨ , , , ⟩ to .
Step 3. On getting the reply from , calculates Then, verifies * ? = or not and if * ̸ = , rejects the connection, and then sends ⟨ , ⟩ to publicly.
Step 4. On getting , calculates = ℎ ( ‖ ) Then, verifies ( * ? = ) and if ( * == ), it demonstrates the authenticity of and . Finally, mutual authentication are attained among , and . Now, and share the same session key = , and they can exchange sensitive information subsequently using = .

Password Change Phase.
This phase is performed locally: not interacting with the server. When wants to update her password, she provides and after inputting the smartcard. Then, executes the operations: * The smartcard verifies ( * ? = ). If ( * == ), user is asked to enter a new password and calculates Finally, substitutes ⟨ , , , ⟩ with ⟨ , , * , ⟩, respectively, in the card.

Cryptanalysis of Amin Et Al. 's Scheme.
Recall that the three assumptions listed in Section 2.2.1 are also clearly made in Amin et al. 's scheme [21]. However, we observe that this scheme still remains feasible for an attacker to offline guess a user's password. This means that the primary goal of "truly two-factor security" cannot be satisfying. In addition, the scheme cannot provide forward secrecy and user untraceability.

Offline Password Guessing Attack.
We find Amin et al.'s scheme cannot achieve truly two-factor security: it is subject to two types of offline password guessing attack when the smart card factor is compromised.
Type-I Attack. Suppose the secret parameters { , , , , ℎ(⋅)} stored in 's smart card are somehow obtained by A. At this point, A can find out 's identity and password as follows: Step 1. Guesses 's identity * and password * from dictionary space D and D .
The time complexity of this attack is O(|D | * |D | * 4 ) [3,16]. According to the running time in [16], A may complete the above attacking procedure within 35.2 days on a Laptop. This issue arises due to the inherent "usabilitysecurity tension": to achieve local password change (i.e., C-2 in [3]) and timely typo detection (i.e., C-9 in [3]); there is an Security and Communication Networks 9 explicit password verifier = ℎ( ‖ ) = ℎ(ℎ( ‖ 1 ) ‖ ℎ( ‖ 2 )) stored in 's smart card, yet this verifier leads to a Type-I offline password attack.
To tackle this security issue while not losing usability, a viable countermeasure is to adopt the "fuzzy-verifier" technique [20] and keep = ℎ(ℎ( ‖ 1 ) ‖ ℎ( ‖ 2 ) mod ) in 's smart card, where confines the capacity of ( , ) pair, 2 4 ≤ ≤ 2 8 . As a result, even if A obtains 2 , she can not identify the correct ( , ) from the above attack, because there will be |D * D |/ ≈ 2 32 candidate ( , ) pairs that make 2 * = 2 in Step 4. To further identify the exactly correct ( , ) pair, A needs to interact with the server, and we can adopt the "honeywords" technique [3,56] to confine A's advantage to a very limited value.
Type-II Attack. In the above attack, A does not need the protocol messages. In this attack, we assume that A can somehow obtain user's smart card and extract its secret parameters { , , , , ℎ(⋅)} and can also eavesdrop the login messages { , , } from the public channel. Now, A can offline guess 's password and identity simultaneously as follows: Step 1. Guesses the value of * , * from dictionary space D and D .
Step 8. Repeats Steps 1∼7 of the above procedure until the correct value of ( * , * ) is found.
The time complexity of the above attacking procedure is O(|D | * |D | * 3 ), and A may complete the procedure within 26.4 days on a Laptop. In comparison, the Type-I attack is more practical. Amin et al. noted that user's mobile devices and IoT sensors are generally of "low memory, low power, and battery and network limitations" [21], and thus they prefer to only use lightweight symmetric key techniques to achieve robust security. It is just this motivation that makes their scheme vulnerable to the Type-II offline password guessing attack. And the rationales can be found in [20,57].

No Forward Secrecy.
A scheme that supports forward secrecy ensures that even after the long-term private key(s) of one or more participants was(were) leaked, previously agreed session keys remain secure [27]. This is important, especially when considering the serious situations of today's clouds like the compromise of cloud servers (e.g., [15]).
If an attacker M has obtained the cloud server 's longterm key from the breached server and intercepted the messages { ; , , , } that are exchanged between and 's authentication process from the public channel. M is able to figure out the session key using the following method: Step 1. M computes = ⊕ ; Step 2. M computes = ℎ( ‖ ); Step 3. M computes ⊕ = ⊕ ; Step 4. M calculates the session key = ℎ( ⊕ ⊕ ).
With the session key computed, the entire session will be no secret to M. This vulnerability is due to a result of violating the "forward secrecy principle" given in [20]: publickey technique is necessary to attain forward secrecy and at least two exponential operations (or point multiplications in ECC) are needed at the server side.

No User Untraceability.
As revealed in [22], in the context of user authentication, there are two types of user anonymity: (1) the basic one, i.e., user identity-protection which requires that the attacker is unable to get the target user's real identity from eavesdropping the protocol messages; (2) the advanced one, i.e., user untraceability which guarantees that the attacker is unable to neither figure out the target user's identity nor determine whether two conversations are come from the same (unknown) user from eavesdropping the protocol messages. Therefore, most schemes (e.g., [4,35,39,[58][59][60][61][62]) that aim to preserve user anonymity attempt to fulfil the latter advanced notion of user anonymity. However, in Amin et al.'s scheme [21], the pseudoidentity is sent in every login request. Thus, the attacker can track all the login activities through this static pesudoidentity .

Revisiting Wei Et Al.'s Scheme
In 2018, Wei et al. [23] observed that most of previous schemes (e.g., [36][37][38][39][40]) only provided some heuristic security arguments and little attention has been to the formal treatment of protocol security. Accordingly, they employed an authenticated encryption scheme to construct a new twofactor scheme that can provide provable security in the random oracle model. Though this scheme is armed with a formal proof, we will show that this scheme still has several serious defects being overlooked: (1) it cannot achieve the primary goal of "truly two-factor security"; (2) it provides no forward secrecy; (3) it ensures no user untraceability.  ). also selects 's pseudoidentity and keeps the item ( , ) in its database. Finally, produces a smart card with security parameters ( , , ℎ(⋅)) and sends to the card via a trusted channel. Then, adds the random number into the card.

Authentication and Key Exchange Phase.
aims to access the service from the cloud server , executes the authentication and key exchange phase with and as follows.

Password Updating
Phase. This phase is executed when aims to update her password with a new one. Because this phase has little relevance with the following cryptanalysis, we omit it.

Cryptanalysis of Amin Et Al.'s Scheme.
Recall that the three assumptions listed in Section 2.2.1 are also clearly made in Wei et al. 's scheme [23]. Though this scheme enjoys many desirable attributes such as rigorous security model and the introduction of an authenticated encryption scheme (i.e., Hoang  Step 1. Guesses the value of , from dictionary space D and D . Step 2. Computes * = ℎ( ‖ ), where is extracted from the smart card.
Step 7. Repeats Steps 1∼5 of the above procedure until find the correct value of ( , ).
The time complexity of the above attacking procedure is O(|D | * |D | * 3 ), and A may finish the attack within 26.4 days on a common PC. In comparison, the Type-I attack is more realistic. Wei et al. noted that user's mobile devices and IoT sensors are generally resource-constrained and made an attempt to design a secure and efficient scheme "without using computation-expensive public key operations" [23]. It is just this motivation that makes their scheme vulnerable to the Type-II offline password guessing attack. And the rationales are referred to [20,57].

No Forward Secrecy.
As with Amin et al. 's scheme [21], Wei et al. 's scheme also only employs symmetric key techniques and thus violates the "forward secrecy principle" proposed in [20], and see more in Section 4.2.2. We now show the details.

No User Un-Traceability.
As with Amin et al. 's scheme [21], Wei et al. 's scheme also only employs the pseudo-identity technique to preserve user anonymity, and this breaches the "anonymity principle" proposed in [22]: under the nontamper resistant assumption of smart cards, public-key primitives are necessary for achieving user un-traceability for twofactor user authentication schemes. In Wei et al.'s scheme [21], the static pseudo-identity is sent in every login request. Thus, the attacker can track all the login activities through this static pesudo-identity .  Table 2), and most these drawbacks are due to violation of basic protocols design principles (e.g., [3,20]). Taking our attacks in mind, we are considering designing an efficient two-factor scheme with provable security.

Data Availability
Data sharing is not applicable to this article as no new data was created or analyzed in this study.

Disclosure
Part of this paper was presented at the 4th International Conference on Cloud Computing and Security (ICCCS 2018) [14].

Conflicts of Interest
The authors declare that no conflicts of interest exist.