SAE: Multiple default password iteration

[jmszuch]

Curious if anyone at Alta Labs had caught this commit for multiple passwords with SAE in hostap:

SAE: Multiple default password iteration - hostap - hostapd/wpa_supplicant

Seemed like a workaround for multiple passwords in WPA3 SAE from my understanding, but feel free to ignore me if that’s inaccurate!

[Alta-Jeff]

Thank you for pointing this out! I didn’t realize this made it into mainline hostapd.

We did actually try out something very similar years ago, but the user experience was very poor, and even with a very small count of passwords, i.e. 2-3, the user was informed that the password was incorrect, and the UI asked for the password again (requiring the user to change it).

I can see how this might work well on IOT devices where the password is forced and statically set, but in our experience, it provides a poor user experience for mobile devices. In my opinion, technologies like GitHub - DistriNet/decoyauth will provide a much better pathway towards multiple passwords in WPA3. Only issue with decoyauth is that a unique payload is required to be sent from the AP for every single password, so it does not scale well beyond hundreds of passwords.

[jmszuch]

You’re welcome and thank you very much for elaborating a bit! I spotted it a little while ago and today’s ALL reminded me that I meant to ask about it just out of curiosity.

I kinda gathered it was a bit clunky since the commit calls out how it needs to scale based on the number of STAs that are expected to be on the network

Allow hostapd to be configured to iterate over a small number of default
SAE passwords (i.e., passwords that do not use a password identifier and
that are allowed for any STA MAC address). This allows more than a
single SAE password to be used in a network. However, this comes with
risk of STAs delaying connection attempts since they might consider this
type of behavior to be an active attack (which it strictly speaking is).
In any case, this seems to be the only realistic method for SAE
deployment with multiple passwords today and it seems to work with up to
five SAE passwords at least with STAs that use wpa_supplicant.

This functionality can be enabled by setting the new configuration
parameter sae_track_password to a nonzero value. It should be set based
on how many active STAs are expected to be used the network. Larger
values use a bit more memory (12 bytes for each additional tracked STA
for each configuured default SAE password) and slightly increased
processing steps. The actual default passwords are set with
sae_password.

I’ll have to read up on decoyauth more, thanks! Would scaling involve how it scales on the controller as a whole? Or more of a per network per access point thing, if you don’t mind me asking?

I’m sure there’s been a bunch of internal discussions about it since as kinda mentioned in the live tream, WPA3 is kinda needed in conjection with 6GHz as I recall. So I imagine some type of non-standard step might need to be implimented.

Not that you have to get into the nitty gritty of it here! At least I haven’t seen any big chatter about PPSK being worked on from a standards perspective when I last checked in on that sort of thing.

[Alta-Jeff]

Decoyauth is one of the potential official solutions for WPA3 multi-password. It doesn’t have to do anything with the controller - just the fact that every single potential password requires its own bit of payload to be sent from the AP to the STA before authentication can occur. This not only lets the STA know how many passwords there are (unless you add some more decoy passwords, which solves that problem, but takes up even more space), but imagine trying to send metadata for 100k passwords (that would be multiple megabytes) to a STA during authentication when both sides only really care about one password. There are other proposals, but nothing has come as a clear winner. In my opinion, the lack of PPSK is one of the biggest things holding back 6 GHz, because WPA3 is required there.