[HN Gopher] OpenWifiPass - Open-Source Implementation of Apple's...
___________________________________________________________________
OpenWifiPass - Open-Source Implementation of Apple's Wi-Fi Password
Sharing
Author : jagged-chisel
Score : 185 points
Date : 2021-01-27 13:37 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ogre_codes wrote:
| 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.
| rektide wrote:
| TIL Apple has their own encoding format, opack.
|
| https://github.com/seemoo-lab/openwifipass/blob/main/OPACK.m...
| remram wrote:
| What does Apple's Wi-Fi Password Sharing do? Share the password
| between a user's device? With other users? Based on location,
| contacts?
| t0mas88 wrote:
| 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.
| djrogers wrote:
| Those 2 use cases are completely separate, and the one that's
| being discussed here is the second one. The first is covered
| by iCloud Keychain sync.
| bberenberg wrote:
| 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
| remram wrote:
| 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.
| jeromegv wrote:
| 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.
| jorvi wrote:
| You can't, because it's hashed. Check it right now, all
| the shared passwords are just hashes.
| Nextgrid wrote:
| 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.
| nathancahill wrote:
| It's encrypted. Not sure what with which key, but it's
| not plaintext, which is what they were responding too:
|
| > you can then go on your Mac and access the password in
| the list of saved wifi password
|
| Not true.
| Nextgrid wrote:
| 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.
| ocdtrekkie wrote:
| 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 wrote:
| With an access point that supports really good beam
| forming.
| arghwhat wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| djxfade wrote:
| Apple does support it. Its standardized
| dmitrygr wrote:
| WIFI:T:WPA;S:MY_SSID;P:MY_PASSWORD;;
| jtbayly wrote:
| 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.
| gingericha wrote:
| 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
| afavour wrote:
| 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 wrote:
| Sounds like most of my experiences with Airdrop (though
| recently it does seem to be working better)
| gtf21 wrote:
| 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 wrote:
| 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.
| amelius wrote:
| Instead it should issue a ticket which allows one to use your
| WiFi for a limited time.
| djrogers wrote:
| But the WiFi specs don't work that way...
| KMag wrote:
| 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.
| luma wrote:
| 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.
| robterrell wrote:
| Exactly my first thought too. Micropython's ubluetooth might be
| usable for this.
| tomas789 wrote:
| I'll definitely implement it on a button press in by AppDaemon
| linked to the Home assistant.
| 1996 wrote:
| It's a very interesting proof of concept.
|
| 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.
| 2Gkashmiri wrote:
| at least on my kde neon you just right click on the connected
| wifi and press show QR code.
| IggleSniggle wrote:
| 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.
| javageek wrote:
| That's what guest networks are for. I have a QR code next to the
| router for any guest coming to our house that wants to use our
| WiFi.
| jackson1442 wrote:
| 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.
| pletsch wrote:
| Does it automatically connect after scanning?
| IggleSniggle wrote:
| 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.
| rconti wrote:
| .. 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!
| franga2000 wrote:
| 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?
| WhyNotHugo wrote:
| Not really.
|
| 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.
| nashashmi wrote:
| Remember WPS? Apple never implemented that and then android
| removed it too. Ugh.
|
| On iPhone if you and a friend in iMessage are together and one
| can connect to a protected WiFi, the other can connect to.
| Automatically.
| franga2000 wrote:
| 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!
| pmontra wrote:
| 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.
| djrogers wrote:
| 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...
| xoa wrote:
| > _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.
| ballenf wrote:
| 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.
| yarcob wrote:
| > On iPhone if you and a friend in iMessage are together and
| one can connect to a protected WiFi, the other can connect
| to. Automatically.
|
| I don't think this is accurate. The Wifi sharing feature
| works differently. It's documented here:
| https://support.apple.com/en-us/HT209368
| Nextgrid wrote:
| WPS had significant security issues if I remember correctly.
| AshamedCaptain wrote:
| 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.
| nemothekid wrote:
| WPS was laughably insecure. If Apple's solution was
| piggybacked off of iMessage's key infrastructure then
| MITM is a non-issue.
| Nextgrid wrote:
| 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.
| acct776 wrote:
| Insanely insecure, holy wow.
| gcblkjaidfj wrote:
| just as insecure as wpa and every other wifi "security"
| of the time.
|
| That's what you get when all the decisions are made by a
| comitee that only cares about the BOM cost in the modems.
|
| btw, nothing on this have changed. Only that the not-so-
| secure stuff is still relatively new and not exploited
| yet.
|
| all hail wpa3, the new crapy unsafe standard of tomorrow.
| junipertea wrote:
| Apple literally invented a (click) wheel!
| https://en.wikipedia.org/wiki/IPod_click_wheel
| JeremyBanks wrote:
| And it was great.
| jedberg wrote:
| 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.
|
| But the Apple sharing is something else entirely.
| franga2000 wrote:
| 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.
| matt74827289 wrote:
| 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.
| emteycz wrote:
| Are you sure Android didn't reinvent the wheel (again)? I
| certainly remember iOS having the option far earlier than any
| Android.
| franga2000 wrote:
| 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.
| brorfred wrote:
| It seems like DPP is part of WPA3, which came out in late
| 2018 and Apple's version was first introduced in iOS 11,
| which was released 2017?
| sigjuice wrote:
| QR codes also work on my iPhone. $ qrencode
| "WIFI:T:WPA;S:${SSID};P:${PASSWORD};;" -o wifi.png
| encom wrote:
| 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.
| NieDzejkob wrote:
| Perhaps this standard allows specifying the BSSID instead,
| somehow?
| franga2000 wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-27 23:01 UTC)