Isn't there a proper 802.whatever standard for "inviting" devices into the network? Android does it with QR codes, but Bluetooth can also be used. Is this that, or did Apple reinvent the wheel again?
WPS was kinda close, but you needed to set up the router (most home users won't figure this out), and actually press a button on it to invite a user.
Apple's protocol is super user friendly, when someone tries to connect to my wifi at home, I get a popup offering to share my wifi password.
I'm glad this sort of protocol is being reverse engineered and FLOSS alternatives pop up, since it'll allow better interaction with Linux desktop and iOS guests.
What Android does is slightly more complicated than that, but it's good to know Apple supports at least something standardized. The main advantage of DPP/EasyConnect (what Android uses with QR codes) is that the key isn't actually stored in the code. It creates a temporary key that allows both devices to communicate securely, then transfers the credentials securely over that connection.
The key is only useful to the first device that gets it. It's generated for each transaction and only valid once. The devices (let's say two phones) communicate directly and once that's done, the connection closes. To add another device, the phone weill generate a new key and a new QR code.
I can't get this to work, because my SSID is the poo emoji. I'm not sure what character encoding QR codes use, and I haven't really bothered trying to debug this.
QR codes, like SMS messages, can use multiple encodings. This avoids wasting space. Unfortunately utf8 is not one of the encodings so although there are tricks to encode utf8 anyway they are not supported by all scanners.
Whatever issue you mean, it cannot be worse than the issues these "Wireless Password Sharing" systems have. Or at least the WPS-Button system cannot be worse than any of these systems, which seem very prone to MITM attacks.
I believe the problem with the WPS button is that it comes with a WPS PIN (might be optional, but enabled by default in most cases) which means brute-force attacks are possible even without having to press the button, where as the solution described in the repo would at least require you to eavesdrop on an active key exchange between 2 users.
Oh no it was far worse: the WPS PIN implementations led to straight up non-interactive wifi hacks. That hasn’t happened with these sharing systems (yet) so far as I know.
WPS was a disaster and Android has removed it in favor of the WFA's official replacement: "Wi-Fi Easy Connect". My point is that there is a new and perfectly good standard for this that Apple should really be following (although I doubt they will).
As for the iMessage thing, holy shit that is such a bad idea and I'm really glad I never gave any iPhone users access to my network!
What if the owner of the WiFi network wants you to connect but not your friends?
Scenario: people come to my home, I give the password to a friend of mine that never visited me before or changed phone and asks me for the password. I don't know the other people and they don't ask for the password, but they get on the network anyway? Principle of most surprise and least security.
>What if the owner of the WiFi network wants you to connect but not your friends?
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.
Even my least tech savvy friends understand that their wifi password is like a traditional front door key: anyone with a copy can unlock the door. I'd call that very unsurprising to most people.
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.
How is this scenario any different when you tell your friend the password or show them a QR code? They can still get and share that password with anyone else...
The QR codes are standard and old. I have a sign at my front door with the QR code for my wifi so people don't have to ask me, and I've had that for years.
Why not just have an open WiFi network? I stubbornly have kept my network open since my very first
Linksys WRT54G router. Am I some kind of internet hippy for feeling like networks should be open and we'd all be better off if we shared with our neighbors? Over the years, I've probably wasted an hours of my life searching for and struggling to correctly enter complex WiFi passwords.
Although truth be told, I think it's primarily that I don't want to bothered giving WiFi passwords to my guests:)
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.
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.
> the creepy neighbor kid to do something on my guest network that will get me a visit from the cops
Think about it. Honestly, what are the odds of that? I'm sure the last time I got in my car (to get a coffee) it was 100x more risky than that (actually it was snowing, make it 1000x). And so what? They show up, I'd tell pull open their phones and connect to my network. I did nothing wrong, have at it wasting my tax dollars. After all is said and done in that 1-in-a-million incident, still less of my life wasted with than if I bothered with annoying WiFi passwords over these decades.
Your comment reminds me of my friends and family who keep their kids locked up (pre-COVID), depriving them of the opportunity to learn independence that I had growing up. Just like when I was a kid, there is no crime in my neighbor and yet people act like their kid will have a 10% chance of being kidnapped if they let him go to the local convenience store, when in reality the odds are closer to 1 in 100 million. Social media or local news has screwed up our society's ability to calculate risk/rewards.
That's a bit extreme. I wouldn't operate open WiFi if I lived in USA, because law enforcement is notoriously over zealous and they are big on saving the children.
Here in Canada, I'm comfortable knowing the cops won't show up in military surplus and shoot me before I can explain.
Nope, those are not the same QR codes. What you're thinking is a QR code with the credentials encodes in it that anyone can read and use. New versions of Android instead implement WiFi Easy Connect (technically called Device Provisioning Protocol) that makes one-time codes to create a secure P2P connection betweem two devices, then transmits the credentials securely. It's pretty much exactly what Apple's thing seems to be doing, only they're doing it over Bluetooth instead of ad-hoc WiFi.
What versions of Android do this? I just tried it on my Pixel 4a and the QR code it generates just contains the network name and password in plain text.
Yes, quite sure. They implemented an existing protocol called DPP (Device Provisioning Protocol), more commonly branded as "Wi-Fi Easy Connect", that is a part of the 802.11 standard and implemented by more than just Google.
If Apple isn't using that, then it's them who are ignoring the standards and doing their own thing.
Now if it could work on non apple devices (like when pressing the button on your router) I'd certainly code something with it too!
Usecase: you are at your desk with a new laptop (or a friend), the router is in the other room and the password is long, and you can't find where you put the QR code the last time.
On linux, it could get the active wifi network from iwconfig and the password currently used from either wpa agent, seahorse or others.
It should present the password in a window, in case it contains an identifier.
I send WiFi credentials and contact info to my smart watch as QR codes (as well as phone). Convenient medium for this use case, always present and on my person, invisible when not needed.
You connect to wifi in my house (or anywhere where I am connected to a password protected netwrok). If we both have BT enabled and are in each others contact list, I am given an option to share the password with you. If I click yes, your UI will not show the password, but connect directly to the wifi. Pretty solid UX. https://support.apple.com/en-us/HT209368
It's like magic. You're about to ask somebody if they know the password, and then all of the sudden your phone fills it in for you and says that your friend shared it with you.
It's like magic when it works. But in my experience a bunch of times it doesn't work and it's really not clear why. A shame because as you say, when it works, it works great.
I used to have this with airdrop all the time, and handoff too. So much potential but never really worked well. When it works it feels magical, but most of the time I just ended up being frustrated and copying things up and down via dropbox.
To piggyback off afavour's comment: I do wish they would provide a button to prompt the sharing if for some, unexplainable (yet not uncommon) reason it doesn't automatically trigger the sharing tray
Interesting. Does it actually delegate the authentication to your phone, or does it send the password?
My Android allows to share the password with a QR code, which is certainly not as ergonomic... in fact it's slower than spelling it out, even to 1 friend.
It sends the password, not really reasonable for it to only be able to authenticate one Wi-Fi device if another Wi-Fi device is still present.
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.
It sends the password, if you have your Apple Keychain synced in iCloud, you can then go on your Mac and access the password in the list of saved wifi password.
Sorry but this is incorrect - they can't be hashed because the password needs to be used as-is for the wireless authentication procedure, at least for PSK-based auth (EAP can indeed use certificates and the private key is never revealed).
The key is probably stored in some hex format (I think wpa_supplicant in Linux also supports this format) but it's not hashing per-se as it's reversible.
In my case, searching for my network name in Keychain Access brings up 2 items, one in my System keychain and one in the iCloud one.
Both of them end up displaying the raw password on the detail view now, though I do indeed remember that a year ago I saw some wireless passwords being in hex instead.
I'm not denying they might be reversibly-encrypted (although this doesn't happen to me anymore for some reason), but in any case for a WPA(2)-PSK network the key cannot be hashed using a one-way irreversible hash because it is needed as-is to actually complete the authentication. What you're seeing is encryption and not hashing.
I wonder if there’s a standardized URL to encode SSID and Password or if they just had to make one up.
Presumably Apple doesn’t support this QR method?
QR of course requires a screen and a camera, whereas Bluetooth can work on, for example, an Apple TV type device, or a smart speaker.
EDIT: So then the trick is being able to generate the QR code easily and securely (without having to send your WiFi password to the cloud). Presumably free apps exist to do this.
You can have as many PSKs for your network as you want, and then since eventually all WiFi originated traffic will travel through a CPU first, implement as complicated schemes as you want (e.g. only allow internet access, not local network if a specific key is used).
These days, even a very cheap ARM core has enough horsepower to run ChaCha20 w/ Poly1305 over every packet plus one Curve25519 multiplication per subscriber every 24 hours, plus generating and signing one Curve25519 short-term Diffie-Hellman key every hour.
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.
I think the main use-case is sharing the Wifi password from your iPhone to your Apple Watch or iPad.
But it also works with people in your contacts if you are already connected to a network (let's say your home network) and a friend is trying to connect to that same network.
The beauty of Apple's solution is around ubiquity. There are piles of Apple devices with iOS versions that support this.
It took me zero effort to set up and I can add my mom to my network in about 2 minutes. Even if I use Linux... chances are nobody coming over to my place is going to benefit from this.
Not panning it, and maybe it'll work with Android eventually. But as it is I can't see bothering with this.
This could be really helpful in the embedded space on devices like the ESP32 which offer both the BTLE radio required to advertise the feature and the WiFi radio to make use of it.
.. so all we need to do is create guest networks on every wifi network, put all routers around the world in public view, and print QR codes to stick next to them. Perfect!
QRs are significantly less useful for laptops, which makes it really nice to be able to enter the password/scan the code on my phone and just send it over to my macbook.
On Apple and Android, when you scan a WiFi QR, it pops up a notification that, if you tap on it, results in your phone automatically connecting to the network.
