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.
