Brain teaser: To prevent operations staff from directly viewing passwords in the database, web applications generally hash passwords once before storing them in the database. When verification is required, the frontend provides the password value, the server hashes it again, and then compares the result to determine if the password is correct. This way, even if operations staff have access to the database, they can only reset the password and cannot log in to a specific account.

So, since the final comparison is against the password hash, why not just hash the password on the frontend and send the hashed result directly to the server to verify the password?

The answer is actually quite simple. We added one hash initially to prevent operations staff from logging in. However, if the hashing is done on the frontend, the server is essentially just performing a plaintext comparison. The hash value in the database effectively becomes the password. Operations staff could then directly use that hash to call the login API and gain access to an account.

This brain teaser is quite interesting; at first glance, it seems to make sense. But to put it another way, although adding a hash on the frontend might seem foolish, historically many companies and projects have done similar things. A typical example is Tencent's QQ.

Over a decade ago, HTTPS was not widely adopted. The HTTP protocol had distinct characteristics, and its content could be easily intercepted via packet sniffing. This meant that if the password was sent in plaintext from the frontend to the backend, it was highly susceptible to man-in-the-middle attacks, leading to the theft of QQ account passwords. To address this, Tencent adopted a double-hashing approach for a period: first, the password was hashed once on the frontend and then sent to the server. After receiving the result of the first hash, the server performed a second hash and compared it against the double-hashed value stored in the database to verify the password.

This approach appeared to solve both the problem of operations staff logging in directly and the issue of man-in-the-middle attacks stealing passwords. However, in reality, it offered no significant protection against man-in-the-middle attacks. If a hacker recognized this, they could easily use the result of the first hash to call the API. Similarly, relying on hashing to prevent man-in-the-middle attacks is unreliable, and relying on symmetric encryption algorithms is also unreliable, because any packet that can be intercepted can also be forged.

The first time I learned about this was because, in that era, security considerations across the board were quite poor. Back then, Windows XP had a very common network utility called WinPCap that could be used to perform ARP spoofing. On top of that, every machine in my entire high school was on the same subnet (the whole school only had two computer labs and a few offices with computers), so during computer class alone, I could capture a large number of passwords via ARP spoofing. Many of them turned out to be QQ passwords, but when I tried to use them to log into QQ accounts, they didn’t work. At the time, I didn’t realize that the encryption wasn’t just a single pass. I vaguely remember that among the captured passwords that actually worked, email passwords were the most common. This was mainly because the SMTP protocol characteristics were too obvious, the port was easy to identify, and the packet signatures were immediately recognizable. There were also no encryption measures in place back then, so I could often grab a lot of email passwords in a single night. With those, I could go to Baidu Tieba (in 2012, Baidu Tieba was still the main community platform at our school) and try to use the email to recover the password for a Baidu account, which would then give me access to nearly all of a person’s online data.

These kinds of things were effortless in that era. Today, however, man-in-the-middle attacks are nearly impossible after the widespread adoption of the RSA algorithm. This is because even if you capture usable packets, TLS communication involves more than one packet, and your captured packets are useless until the full handshake is completed. Windows also blocks similar ARP spoofing at the underlying level. Today, when developing web applications, simply relying on TLS and sending passwords in plaintext directly to the server is already considered quite secure.

Really… is it that secure? Someone once questioned me, saying they had used interception software capable of capturing HTTPS traffic, such as Wireshark.

Software that intercepts HTTPS traffic actually relies on the reverse proxy concept I mentioned earlier. While the attacker believes they are establishing a direct TLS connection with the target server, they are actually establishing a TLS connection with Wireshark. Once Wireshark, acting as the server, captures the request, it forwards the plaintext back to the actual target server, thereby capturing the plaintext content.

In a complete TLS communication, not only is the validity of the certificate itself verified, but the legitimacy of the issuing authority is also checked. When installed, Wireshark registers itself as a trusted authority, allowing it to reasonably bypass this verification process. Therefore, besides intercepting HTTPS traffic on your own computer, intercepting others’ traffic is even more difficult, and ARP spoofing is also much harder to achieve today.

Of course, today we still cannot fully trust HTTPS. Protection against interception at the communication layer often gives rise to more naive yet effective attack methods. For instance, Chrome browser extensions have the authority to directly read web page forms, bypassing any other security measures at the communication layer. Installing a fake extension can pose a real threat, especially given the immature extension ecosystem in the new Edge, where the risk of blindly installing extensions is quite high. (I almost installed a scam version of Dark Reader just a few days ago.) And even more frustratingly: creating web pages that look exactly like QQ allows scammers to harvest large numbers of QQ account credentials and passwords daily. Truly solving these problems is far from enough with just security measures and algorithms. It is fundamental to raise the vigilance and judgment of ordinary users, as well as their common sense regarding basic security.