OpenWifiPass – Open-Source Implementation of Apple's Wi-Fi Password Sharing

The idea that more sophisticated authentication is possible to prevent password sharing would be a surprise to most laypeople I know.

Also home internet is increasingly coming with smart routers that will alert you to new devices on the network. Tech savvy people are the only ones who BYOD.

Then they should switch their network to a more complex authentication scheme. Multiple SSIDs, run 802.1x authentication (maybe with certs), MAC filtering maybe (bypassable sure, but will foil most casual users), run their own simple portal and shunt different classes onto different VLANs with different levels of isolation and traffic shaping, etc.

Ultimately if there is one password which then gets any device on, well that's that. Sharing has always been pretty trivial. If the owner of a network wants more fine grained and powerful security, all the tools exist to do that already, but they'll have to use them.

Because I don't want the creepy neighbor kid to do something on my guest network that will get me a visit from the cops or a letter from my ISP. Sure, guests could do that, but they'd be a lot less anonymous in the process.

I used to do that for a long time. It was great for guests and also for plausible denaiblity if I every got a nastygram from my ISP.

But the liability just got to great and the plausible deniability argument got pretty weak. And also, with so many neighbors with devices that will just auto join open networks, I started seeing strange traffic a lot, most likely from neighbors connecting accidentally.

At the end of the day, making it super easy for guests inside my house without being totally open works out well.

Wi-Fi passwords aren't really that secure a thing these days, anyways. If you need your Wi-Fi to be secure, you need to be doing RADIUS authentication or similar.

It's just from a UI standpoint that it's very seamless. You don't have to see the password, you don't have to enter it anywhere, one device just shares the Wi-Fi password with another device nearby.

Your key is too simple if it's easier to spell out. :)

Seems eminently sensible, no dependency on WiFi or Bluetooth stacks and works cross-platform.

A QR also lets you force the recipient onto a guest SSID instead of your LAN

Using a shared symmetric ChaCha20 w/ Poly1305 key to encrypt and authenticate the client's sign-on Curve255 exchange, you'd get a variety of usage modes for free without adding any special cases to the access point's side of the protocol.

The basic use case is that your device knows the password, so it listens for the periodic SSID announcement with the signed short-term DH public key. Your device then performs its side of the DH key agreement, and encrypts-and-MACs the public value with the password-derived key. The access point decrypts your public DH value, completes key agreement, and uses the agreed key to encrypt your short session ID, its expiry time, and a 256-bit ChaCha20/Poly1305 key[0] for the session, and send it back to your device.

In the case of temporarily granting access to a guest, the guest's device would generate a public DH value and send it to you. You'd then encrypt-and-MAC that exchange message and send it back to your friend's device. The friend's device would then be able to forward the DH exchange to the access point and sign on once. They'd have a session ID and encryption key that's valid until expiry.

In the case of a coffee shop granting temporary access to a paying customer, the phone could put its ephemeral public DH value in a QR code, and the cash register could scan the QR code, encrypt-and-MAC the public DH parameter, and directly send the value to the access point, at which point the customer's device could sniff and decrypt the sign-on message to learn its session ID and session key.

Each device gets its own session ID and session key, so they can't eavesdrop on each other.

If Curve22519 ends up getting broken, an attacker would still need to break ChaCha20 or learn the password in order to grab session keys. The client-side DH parameter still holds 252 bits of entropy (Curve25519's cofactor is 8, so the generator generates a 2*252 subgroup), and computing an Elliptic curve logarithm on this value still requires first decrypting the ChaCha20-encrypted sign-on message.

You wouldn't get perfect forward secrecy, but you would get forward secrecy through the timed key rotation of both the short-term DH keys and rotation of any symmetric keys used to avoid storing any per-session state in the access point.

[0] The session encryption key wouldn't simply be the DH-agreed key in order to allow the access point to avoid keeping per-session state and instead derive session keys from session IDs using periodically rotating symmetric encryption keys known only to it. The access point would need to guard against session IDs rolling over faster than they expired (and expiry would need to coincide with key rotation), but it's a simple check.