[mannyv]

In general they work by having an allow list and by using a captive DNS. Some will also try to redirect http/https.

Once the agreement is accepted the MAC is added to the allow list.

Not sure how MAC address randomization works in these schemes, but it does. There must be some standard algorithm that everyone follows.

[zamadatix]

There are 3 main types of "random Wi-Fi MAC addresses". The most well known one is randomization of the MAC while the client is probing from SSIDs (prior to connection). This has been around for many years and doesn't change the actual connection MAC later on. Another randomization type that's slightly more common these days (e.g. iPhones default to it now) is choosing a random MAC per SSID. That way you can't be tracked by MAC across multiple networks but you still have consistency for captive portals and business networks. The third is true rotating randomization - this is relatively uncommon as it breaks captive portals (there is no well known algorithm or it'd be relatively pointless). iPhones were going to adopt this with rolling MACs but it was too broken and offered little over approach 2 in terms of privacy.

[ninkendo]

I guess different captive portals work differently, because I’ve heard of plenty of them that can be bypassed by simply statically assigning the address of someone else who’s already authenticated (ie session hijacking), but it makes sense that any “decent” captive portal system uses MAC addresses to mitigate this.

The randomization I refer to is of the outgoing IPv6 address, not the MAC address… nothing that I’m aware of randomly cycles MAC addresses (Apple’s OSes can be configured to randomly generate a MAC every time you connect to a network, but it won’t regenerate them continuously in a session. IPv6 addresses however are continuously generated, as per the RFC4941 spec.) If the system is using MAC addresses to identify users, then temporary/cycled IPv6 addresses should be no problem.