[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.

[heyoni]

How is wps a disaster?