3.2 Server Response

I. Introduction to Wi-Fi Authentication

The understanding of Wi-Fi authentication can be simplified into two stages: obtaining the PMK, and then through four handshakes, derive the PTK from the PMK to establish an encrypted channel, and the keys used subsequently are split from the PTK.
The key generation and distribution process for Wi-Fi authentication is consistent for both individuals and enterprises, the difference lies in the PMK generation logic. Taking WPA2 as an example, the PMK for WPA2-PSK (personal) is a deterministic algorithm (PBKDF2-SHA1) calculated from the password, while WPA2-Enterprise calculates the PMK through the context information in the EAP protocol authentication process. After obtaining the PMK, the subsequent process is completely the same.

1、personal

Personal version authentication methods, the usual form of use is to set a Wi-Fi password, set one on the router, and when the terminal needs to connect, the same password also needs to be provided. This type of Wi-Fi access method is usually provided in homes or some small public places. The mainstream authentication protocols currently are WPA2-PSK/WPA3-SAE. The WPA2-PSK authentication can directly calculate the PMK by both parties, while WPA3-SAE calculates the PMK through the SAE key negotiation algorithm. SAE belongs to the PAKE (Password-authenticated key exchange) algorithm, which is a variant of the Dragonfly algorithm. SAE is a secure PAKE algorithm that can have forward security, and the negotiation process can prevent man-in-the-middle attacks. After obtaining the PMK, both WPA2 and WPA3 use the same four-handshake process, but WPA3 requires stronger cryptographic algorithms.

2、Enterprise

The primary purpose of enterprise-level authentication is to support multi-user access, with each user having an independent account. Account authentication is performed using the EAP protocol. Common authentication methods include: EAP-PEAP, EAP-TLS, EAP-TTLS, and there are also various less commonly used authentication methods. EAP-PEAP and EAP-TTLS only establish an encrypted tunnel, where actual authentication takes place within the encrypted tunnel.

3. Other

The most common method is open + Web authentication, providing an open network. After the terminal connects to the network, it will try to access an address to detect whether it can access the Internet. If the terminal has not been authenticated, it will be redirected to the authentication address. Such methods are very insecure and cannot be used for enterprise-level authentication. It is not within the scope of this discussion.

Part Two: Enterprise Authentication Protocol

1. EAP-TLS

EAP-TLS is currently the most secure and simplest authentication protocol, essentially a two-way authentication of TLS. As shown in the figure

In the figure above, the EAP Server is just an abstraction for simplification, which could actually be a device, or the authentication service within it might be split into a separate server. Commonly, the actual authentication is performed by RADIUS service. The abstraction of EAP Server does not affect the security discussion, and in fact, the protocol also uses the same abstraction method later.

The main problem with EAP-TLS is that the enterprise needs to have its own PKI, issuing a separate certificate for each employee who needs to log in. For enterprises that are unable to build their own PKI, this solution cannot be used, and for enterprises that can build their own PKI, maintaining and operating a PKI also involves a significant cost.

2. EAP-PEAP

PEAP itself is not just a one-way authentication; the Supplicant authenticates the EAP Server to establish a TLS tunnel, and then uses the inner authentication protocol within the tunnel to authenticate the EAP Server to the Supplicant. EAP-PEAP supports EAP-MSCHAPv2 and EAP-TLS as inner authentication protocols. The EAP-MSCHAPv2 protocol is a user password authentication, and it seems to have little significance to wrap an EAP-TLS inside PEAP, so it is better to use EAP-TLS directly. There is no need to wrap EAP-TLS with a less secure EAP-PEAP, so the built-in authentication algorithm of EAP-PEAP is almost exclusively EAP-MSCHAPv2. MSCHAPv2 is an insecure authentication algorithm, although an encrypted tunnel is constructed in advance using EAP-PEAP, the algorithm used by MSCHAPv2 itself can cause some security issues in password storage, which will be elaborated later. In the EAP-PEAP specification, the TLS tunnel establishment uses TLS1.0, which is relatively insecure. In Microsoft's latest protocol document from 24 years ago, it still explicitly states that TLS1.0 should be used to establish the tunnel. Therefore, it is not recommended to use EAP-PEAP at present.

3. EAP-TTLS

The difference between EAP-TTLS and EAP-PEAP is quite small, and the principle is also exactly the same. The main difference is caused by different designers. The biggest difference between the two is that EAP-TTLS supports more inner authentication protocols than EAP-PEAP (such as PAP, CHAP, MSCHAP, MSCHAPv2), including non-EAP protocols, and also includes EAP protocols (such as EAP-MSCHAv2, EAP-TLS). Overall, there is little difference between EAP-TTLS and EAP-PEAP, but EAP-PEAP has not updated the TLS version and is still using TLS1.0, and only has the draft version of RFC, which leads to insufficient security. EAP-TTLS has been updated, and the latest specification has abandoned TLS1.0 and TLS1.1, supporting TLS1.2 and TLS1.3. Currently, using EAP-TTLS with TLS1.2 and TLS1.3 versions can suggest a secure TLS tunnel. If username and password authentication is used, using EAP-TTLS+EAP-MSCHAPv2 will be more secure than EAP-PEAP+EAP-MSCHAPv2.

4. Common problems

All of the above protocols have a common problem, that is, the name of the certificate authenticated by the Supplicant for the EAP Server is not mandatory. Most enterprises will not require users to configure this information, and whether the Supplicant is configured or not will not affect the authentication result when the certificate is correct. The Supplicant does not authenticate the certificate name of the EAP Server, which makes Man-in-the-Middle (MITM) and fake wifi hotspots theoretically possible.

Third, username and password authentication protocol

1. PAP protocol

It is a simple authentication protocol using plaintext username + password

2. CHAP protocol

The CHAP protocol can be simplified to the following three steps:

• The authentication server sends a challenge (Challenge, also known as a challenge) with an id + random number to the Supplicant
• The Supplicant calculates the response by computing the MD5 of (id + password + random number)
• The authentication server uses the same algorithm as the Supplicant to calculate the response and compare it with the response sent by the Supplicant

It can be seen that the authentication server needs to maintain all the plaintext passwords of the Supplicants in its own database, which puts high requirements on the security of the authentication server.

3. MSCHAPv2

Description of related algorithms:

3.1 Peer Response

PaddedPasswordHash=MD4(Password)||\0x00\0x00\0x00\0x00\0x00

ChallengeHash=SHA1(PeerChallenge || ServerChallenge|| UserName)[0..7]

PeerResponse=DesEncrypt(ChallengeHash,Key=PaddedPasswordHash[0..6])||DesEncrypt(ChallengeHash,Key=PaddedPasswordHash[7..13])||DesEncrypt(ChallengeHash,Key=PaddedPasswordHash[14..20])

3.2 Server Response

Magic2[41] = {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B, 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F, 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E, 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F, 0x6E}

Magic1[39] = {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65, 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67, 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74}

ServerResponse =

"S=" || Hex(SHA1(SHA1(PasswordHashHash||PeerResponse||Magic1)||ChallengeHash||Magic2))

ChallengeHash is the same as 3.1

According to the above algorithm, it can be found that the attacker can crack the password as long as they obtain the ChallengeHash, or PeerChallenge, ServerChallenge, and UserName, as well as PeerResponse. Moreover, the third Des encryption part actually has an effective key length of 2 bytes, which is very easy to calculate the last two bytes of the PasswordHash, which adds a lot of convenience for subsequent cracking. Therefore, MSCHAPv2 is also an insecure algorithm that cannot be used on an insecure channel.

It can also be seen that the authentication server must save all the usernames and passwords (in plain text or MD4 of the password) of the Supplicant. Although the database can save the MD4 of the password, it cannot be salted back, and if the data is leaked, it is very easy to be cracked. It is similar to CHAP and also puts high requirements on the security of the authentication server.

4. Streamline

The most secure enterprise authentication is EAP-TLS, but it requires the enterprise to build PKI facilities, which is expensive. If EAP-TLS cannot be used, EAP-TTLS+EAP-MSCHAPv2 can be used instead, but the server-side database needs to be strengthened with high specifications. EAP-PEAP is not recommended because its specification is too old and has not been updated. At the same time, enterprises need to require through processes that the terminal configuration needs to verify the certificate name.

Author of this article: Yile @ Tuya Smart Security Lab

Bug Bounty Program: Tuya Smart Security Response Center (https://src.tuya.com) welcomes white-hat hackers to explore.