Identity PSK, or Multi PSK to a single SSID

Hi there, I was looking at a byo AP solution using openwrt, but not really finding answers if this is possible or supported so presuming not. That being ability to assign multiple different PSK's for different users or devices to a single SSID. This is specifically NOT using WPA-Enterprise, but still Personal, just managing use of list of many PSK's to auth endpoints differently transparently as a "feature".

I mostly play in the enterprise world, but looking for a home solution to emulate what I do for customers of mine using these features. Cisco calls it "Identity PSK or iPSK", Arista uses Roles each with a different PSK (which I use today at my house), Extreme/Aeorhive, Aruba, most all offer like these days as some "feature" of theirs, and has nothing but benefits to avoid the one psk to rule them all that gets written on the bathroom walls for a good time. These usually come with vlan or firewall assignments ala dot1x, but I'd be happy with just multiple psk's I can add and delete if/when people/things come/go.

Since it's all the same chip vendors underneath, I presume it's just a software limit, but is this something possible at all with openwrt, or something to request on a roadmap? I've seen others ask the same, but it's usually dismissed as "use wpa-enterprise for that" or it just doesn't work sort of answers, however if the mega-vendors can do so, I don't see why there can't be a solution for open source software too.

Thanks in advance!

1 Like

This is not possible with WPA Personal.

Are those other vendors actually setting up one SSID with multiple passwords using WPA personal?

The 802.11 standard is not really intended to do what you're asking, but if the answer to my above question is "yes", I can posit two possibilities:

  1. They may create multiple SSIDs with the same name, and then assign each a different password. I have no idea if this would actually work, but you could try doing the same thing (it would probably cause major problems for devices that have just one of the passwords).

  2. They could be employing 'tricks' that are chipset specific and require custom closed source firmware that is developed in partnership with the chipset manufacturers. If this is the case, such firmware/code would not be available to OpenWrt.

But the other thing to ask is "to what end" would you use this? If you want to setup different 'permissions levels' for each of these unique passwords, you would be better off with unique SSIDs that map to different subnets, and thus you can use different passwords... that works with no issue. Otherwise, I can't quite understand what value comes from multiple different passwords that all end up joining the same network.

1 Like


IPSK can be configured on any AAA serer that supports Cisco av-pair.


So, why did you fail to mention that there's other services, etc. required for this setup?

Your post implies moreso just adding a list of additional PSKs to a config - yet these directions from other vendors are describing a more complex setup, require additional servers, etc.

Yes this is possible but not exposed in uci iirc.

Google for wpa_psk_file. The MAC address 00:00:00:00:00:00 can be used as wildcard to specify device agnostic PSKs.


I want to underline that I have submitted a patch which was accepted in February that with WPA radius can be used to assign vlans to clients without wpa2 enterprise (
What I have not tested but should be doable is even to offload the password check to radius in WPA Mode...

Perhaps Cisco was a bad example there, of course they really want to sell you ISE (probably Aruba with clearpass too), but I am doing this today in my house with an Arista AP that does not require an external radius server, rather it has its own internal database of creds, and same with Extreme last time I set it up (~5-6yr ago now, they were still Aerohive then). And yes, this is using WPA-Personal, so any random crap-gadget with wifi works still.

I'd actually be ok with radius fort that that, Arista just happens to offer a local db, which is nice if you don't have or want to run a radius server or 10 which is mighty convenient too...

1 Like

Did you already digged and poked in the wpad documentation?

I've always known wpad as Web Proxy Auto-Discovery (cringe) and never wifi, so no... Looking now at the other wpad - thank you for that.

I'm somewhat abusing enterprise features for my house, as I want different psk's for things like my light switches, thermostats, media players, random chinese gadgets, etc. In my head I'm thinking who wouldn't want that? I applauded finding my arista could do that, I certainly don't trust these crap-gadget vendors, but they are a necessary evil, and not only do I not want them to know my psk permanently, I'd like to remove them without having to do whack-a-mole at a mac-level or reset the rest of the devices around it.

I realize it's probably a big ask if net-new, there's a reason those vendors that offer it all charge for devices to pay for developing said features. I'm more surprised by now someone else hasn't replicated it yet out of necessity as all the vendors copied each other eventually (aerohive was the first to offer it I'd ever seen years ago), but seemed not at least for openwrt. Unless hidden behind bad naming like, erm wpad that isn't that wpad... :slight_smile:

Thanks again!

“wpad” is just a name OpenWrt gave to it’s hostapd + wpa_supplicant multicall executable. For all intents and purposes refer to the hostapd documentation.

Can be implemented using hostapd’s wpa_psk_file option. It does not require wpa enterprise or radius elements.

It should be something like:

uci del wireless.@wifi-iface[0].key
uci set wireless.@wifi-iface[0].wpa_psk_file=/etc/psk.list
uci commit wireless 

echo "02:00:11:22:33:44 secret123" > /etc/psk.list
echo "00:00:00:00:00:00 hunter42" >> /etc/psk.list

wifi up

Thanks for highlighting the psk file again! I probably skimmed your post to fast :confused: and yes this sounds like what the OP is looking for. (And the static Vlan file of hostapd can be used too to move the clients to dedicated vlans...)

Thank you Jow, I was just doing so working through these and stuck on that wpad thing.

That does seem exactly what I need here, so that's awesome! The only thing missing is a ui element to manage them it seems. Arista and Aerohive that I've used are/were nice that you could assign a description (ie name) to a group, add an individual psk, and even tag them for a certain vlan (which is my next project), but I'm good with cli too as I intend to use it as a virtual appliance with some hardware attached.

It seems like an undervalued/undersold feature, digging around for "multi psk" sorts of things didn't yield much related to openwrt, and could be far more useful related to security.

Doing IT consulting for 20 years, I've run into lots of orgs (government too) still using one psk to rule them all that could have been better off with this feature the whole time. Most are too lazy/ignorant to do a proper radius/cert solution still, where this is probably all they really needed to add and remove users manually that they can slap someone harder to work longer to do still.

Cisco seems had only recently begun doing this vs. seeing this in Aerohive half a decade or more ago, and only betrothed to their ISE solution. Arista has at least since acquiring Mojo, so seems something people indeed want, and only see this as a plus for home consumers too.

From the discussion thus far, it looks like I may have been wrong about multiple PSK on a single SSID.

That said, in the case of IoT devices and other "untrusted" hosts, I personally don't see why the multi-password option is more desirable than using multiple subnets with associated SSIDs.

To me, the risk is not: "will the untrusted device potentially compromise my network password"... instead, I think more about "will the untrusted device potentially compromise my network". The password for my wifi network is only useful if an attacker is in wifi range (i.e. really close to my home).

On the other hand, a device that might contain malware or other exploits could allow an attacker from anywhere in the world a vector into the trusted network if I've allowed that device on my trusted lan.

Therefore, IMO, if you're worried about the potential for an untrusted device to go rogue and compromise your network password, the bigger concern should be the damage to, or compromised of the network to which it is connected.

I do see value in the multi PSK in other contexts... for example, maybe a cafe or other public network where the 'customer' password might be rotated periodically. Or maybe as a method of revoking access to a certain group (i.e. the kids) while keeping everything else online normally (i.e. the parents and the household devices). This latter case could also use additional subnets as a method, but multi-password solutions might be more straight forward for some.

1 Like

I won't argue this is a perfect solution, but far easier in theory to offer some differentiated access between users or devices for layfolk. At the most basic sense, if I have 3 users/devices, each with a different psk for the same network, and I fire one of them, I simply remove the one credential vs. having to yell at everyone globally to change their key suddenly.

This also easily allows for a grace period and cycle even if everyone is still using the same password for again those organizations too lazy to do this properly, and I have worked for many in this case. I can think of a lot of use cases why someone would, far more than any absolute reasons not to, short of baking in a local radius user and pki management solution in its stead.

Consider also most of these vendors doing this feature couples in vlan and acl assignments based upon the credential hit mapping that user/device at that point ala dacl/tunnel-id push emulating radius/802.1x. If psk matches, map identity/vlan/acl, all in a potentially lightweight managed local db.

Look ma, no radius! Seems this would be a win for the kiss principal for a large number of users as a basic rbac mechanism. Ultimately I am not a developer to write my own widgets, so take it for what you will as the overlords here, but if someone gets bored or ever envisions a need, I don't think I'd be alone in welcoming such a feature ultimately.

1 Like