8 ms·

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 li

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 https://support.apple.com/en-us/HT209368

jtbayly 6y ago
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. Every time I use it I love it.
- afavour 6y ago
  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.
  - kfriede 6y ago
    Sounds like most of my experiences with Airdrop (though recently it does seem to be working better)
    - gtf21 6y ago
      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.
  - wojciii 6y ago
    Send the HCI logs from both devices to apple and let them scratch their heads as to why their protocol doesn't work all the time.
- gingericha 6y ago
  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
remram 6y ago
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.
- ocdtrekkie 6y ago
  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.
  - SEJeff 6y ago
    With an access point that supports really good beam forming.
- arghwhat 6y ago
  WPA PSK unfortunately couples encryption and authentication, so users require the key at all times. Your key is too simple if it's easier to spell out. :)
- dingaling 6y ago
  > My Android allows to share the password with a QR code 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
  - zaroth 6y ago
    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.
amelius 6y ago
Instead it should issue a ticket which allows one to use your WiFi for a limited time.
- KMag 6y ago
  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.

jtbayly 6y ago

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. Every time I use it I love it.

afavour 6y ago
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.
- kfriede 6y ago
  Sounds like most of my experiences with Airdrop (though recently it does seem to be working better)
  - gtf21 6y ago
    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.
- wojciii 6y ago
  Send the HCI logs from both devices to apple and let them scratch their heads as to why their protocol doesn't work all the time.
gingericha 6y ago
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

remram 6y ago

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.

ocdtrekkie 6y ago
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.
- SEJeff 6y ago
  With an access point that supports really good beam forming.
arghwhat 6y ago
WPA PSK unfortunately couples encryption and authentication, so users require the key at all times. Your key is too simple if it's easier to spell out. :)
dingaling 6y ago
> My Android allows to share the password with a QR code 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
- zaroth 6y ago
  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.

amelius 6y ago

Instead it should issue a ticket which allows one to use your WiFi for a limited time.

KMag 6y ago
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.