Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've seen at least Chromecasts, Apple TVs etc. in quite a few corporate offices, so it's not completely unrealistic. Maybe somebody wants to use the Echo as a cheap speaker with the microphone disabled, or it's in a non-sensitive location.

That said, in a corporate network, admins would hopefully put these in a pretty isolated subnet (by SSID+PSK, since they presumably don't support WPA-EAP where you could VLAN/subnet them based on their credentials).



A better way to prevent this would be to use One Time Passwords for every device joining the network. If the password is reused from a different device it gets invalidated.

I don't know if such a mechanism exists for networks and I guess it would also be trivial to just spoof a mac address. I guess it does for something like a captive portal.


The best you can do is have a PSK per mac address.

Hostapd which manages the encryption of wifi access point in pretty much all wireless aps already supports it. You can supply a list of mac address to psk or obtain the psk from radius server. The mac address is provided as the username, all your need to do is return a different psk depending on the mac address. I have POC code lying around I should probably publish somewhere.

Like pointed in sibling comments, it is pretty trivial to clone a mac address so if you were to dump a "unique" psk, all you need is the mac address that goes with it.

What it does gain you though and that is a big plus in some situations, is the ability to revoke a single psk without having to reconfigure all your client devices. That is very useful.

The onboarding is a little bit wacky though. You need an easy way to get the client mac address, generate a unique psk for it, save that in your config, then attempt connection....

One way I would like to explore is have a "next available psk" easily available, for example in an app available to the network administrator. When hostapd asks for the psk associated with unknown/never seen before mac, return that default PSK and save it as associated with that mac on succesful connection, then regenerate a new default PSK for the next device.

This way, an admin can share the password or onboard new devices easily. You don't need to know the mac address of the client in advance.

If you need to revoke access for a device, just revoke the psk that was associated with it.


Ah, yes, PSK per MAC is an interesting option and seems to be used by some enterprise Wi-Fi solutions already as well. I didn't know that hostapd supports it as well, that's nice!

Another option comes to mind, thinking about it some more: The standard could be extended (or a proprietary extension added) to make the PMK something like Hash(PSK, SSID, client MAC), or Hash(Hash(PSK, SSID), client MAC) for a bit more backwards compatibility.

That wouldn't help against clients that just store the PSK (hash), of course, and clients would in fact need to do that to allow sharing the access, but it would offer some marginal security benefit (for other clients on the network) against attacks on clients that do implement it.


That only works in a model where you only have one AP per SSID, but many networks have multiple APs, and not all of them have a central controller.

If you have a single AP and replace that for some reason, you'd also need to enter the PSK again on all clients.

WPA-PSK seems like a pretty bare-bones protocol, but if you consider the constraints it has to operate in, it's actually not that easy to come up with something better (other than the omission of ephemeral key exchanges through something like Diffie-Hellman, which was only added in WPA3, but would not help in this threat scenario in any case).


Ruckus offers one time PSK and PSK per vlan. Very easy. I started seperating my home devices on a different vlan.

Mikrotik, you can associte PSK with mac address. it's not easy to setup but basically, PSK & mac address need to match in order to access the network. I think it also puts user in the configured vlan.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: