PAKE is awesome, yet not very well-known :-( In a nutshell a PAKE scheme guarantees that (1) a passive attacker has no way to brute force passwords at all, and (2) that an active attacker can at most test one candidate password per authentication attempt.
PAKE is used by Thread (IOT protocol built on top of IEEE 802.15.4: https://threadgroup.org/ and it's precisely its use of PAKE that makes it one of the most secure wireless protocols IMHO. Disclosure: I helped security-review it during its design.) Various PAKE schemes exist but a simple one based on Diffie-Hellman works like this (called DH-EKE):
1. Client selects random priv, pub key pair: a, g^a
2. Server selects random priv, pub key pair: b, g^b
3. Client sends its pub key encrypted with client's password: E(g^a, passwd)
4. Server sends its pub key encrypted with client's password: E(g^b, passwd)
5. Client and server each decrypts the packets (with the password that they both know) and get each other's pub keys: g^a, g^b
6. Client and server proceed with standard Diffie-Hellman: they compute g^ab use this value as an encryption key
7. Client and server do a message exchange encrypted with g^ab, to verify they both derived the same key.
Note: I demonstrate the scheme DH-EKE because it's simple. But please know this scheme is flawed when naively implemented. In theory it should be safe when used with an elliptic curve variant using Elligator https://elligator.cr.yp.to/ but I haven't seen much research and peer reviews of Elligator... Other PAKE schemes are considered perfectly secure (but their complexity makes them unsuitable to be explained in an HN comment, eg: J-PAKE.)
What can an "offline" attacker do? He can passively sniff the packets and get E(g^a, passwd) and E(g^b, passwd) but there is no way for him to bruteforce the password. He can try to decrypt the packet with candidate passwords, but he does not know when he guesses the right one, because a successful decryption will reveal g^a or g^b however these value are indistinguishable from random data (when using Elligator because that's exactly what it guarantees: that a pub key is indistinguishable from random data.) And even if he guessed right, he would obtain g^a and g^b, but would not be able to decrypt any further communications as the use of Diffie-Hellman makes it imposible to calculate the encryption key g^ab.
What can an "online" attacker do? If he actively MiTM the connection and pretends to be the legitimate server, he can send his own E(g^b, passwd) to the client using one guessed candidate password. If he guessed wrong, then the client will decrypt to an incorrect g^b, will not calculate the right g^ab, and step 7 will fail. Good. At least the client can detect a (failed) password guess attempt. And that's all the attacker can do. Each authentication attempt gives him only 1 chance to test 1 password. If, out of frustration, the client tries to retype the password and re-auth 3 times, then the attacker can at most try to guess 3 candidate passwords. He can't bruteforce many passwords.
An effort is ongoing to standardize one of the PAKE schemes, called J-PAKE, in TLS: https://www.ietf.org/archive/id/draft-cragie-tls-ecjpake-01.... TLS with J-PAKE is what Thread uses.