[stonepresto]

This also reads like an advert...

I still don't see a usecase for a unique PSK per guest, and even that can be achieved with most guest portal implementations.

What SPR seems to lack is backing and therefore trust. Pushing a product aggressively on HN is not the way to build that trust.

[transpute]

An "advert" for a BSD-licensed open-source codebase? Pointers to a comparable OSS networking project, implemented in memory-safe golang or rust, would be appreciated. There is https://router7.org, but for a narrow use case.

[spr-alex]

Hi -- this is the SPR team, we actually did not push this on ycombinator and are happy to see it being discussed. We've previously made one post about SPR here, under Show HN:

https://news.ycombinator.com/item?id=35990030

The post in the link does not pertain to the user PSK but it is about the difficult trade offs that users have when they need to chain routers together.

Imagine someone has a router that they want to put all the IOT stuff that does not get security updates and has poor code quality compared to the rest of a network.

Should that router be the first router that has access to the internet? Or should it be connected to the router that does. The answer is not so simple and that's what the blog post discusses.

In SPR we provide users a mechanism to block upstream RFC1918 addresses by default and selectively enable them.

We have also found numerous flaws in Guest WiFi systems that totally break isolation between the Guest Network and the main network. This affects many routers on the market today, in particular when a medium is bridged between wired and wireless, but also in general.

As seibol commented -- VLAN tagging per SSID is a valid approach as well if a router supports it. Thats a lot stronger than how many routers implement their guest isolation.

As for Multi-PSK -- the use case is creating micro-segmentation in a network with zero-trust, where the identity on the network is rooted in that password.

Without Multi-PSK, if it's not clear, every device that has the WiFi password can sniff encrypted traffic with WPA2, make a Rogue AP to attack WPA3 in case its in use, and can perform ARP spoofing on the network to interfere with other devices.

[amluto]

I think it’s useful for headless devices — signing up, say, a thermostat using a guest portal is ridiculous.

WPS sort of tried to cover this use case, but WPS is a disaster.

[stonepresto]

I agree WPS is a disaster.

My approach is just setting proper firewall rules on a dedicated ESSID with a dedicated VLAN. A device on a restricted VLAN shouldn't be able talk to anything. The downside is its more work, but the plus side is it can be done on trusted firmware (OpenWRT) and not something that would require an entire code audit to determine if there are any logic flaws.

[amluto]

This doesn’t isolate the devices from each other, though. (Well, maybe if you have isolation set up on the AP and the devices are all connected to the same radio or isolation happens to work across radios and no one exploits any of the myriad ways in which Ethernet, on the same broadcast domain, is not a secure protocol.)

[heyoni]

How is wps a disaster?

[amluto]

Lack of usable support from a lot of access points and management systems. Do any of the major multi-AP systems support it? UniFi has no support. I don’t think any of the Ruckus products support it.

(Also, “push the button” is a bit of an awkward concept with multiple APs.)

edit: it’s also a disaster due to a proliferation of crappy client devices that more or less require it.

[heyoni]

I see. I'm using a normal router in bridge mode as an extender and that's been working well enough and comes with WPS built in so for instance, I can turn it on there if the printer is closer but of course it would be nice to turn it on in one place and have all the extenders have it on as well.