Andrioid stores WLAN passwords unencrypted - and sends it to Google
https://code.google.com/p/android/issues/detail?id=57560 So, your smartphone/tablet will have a list of all the WLAns you connected to. Stored unencrypted. And sends it to Google (according to heise.de this is the Default on all the Android systems they tested it). Well - means, Google has a very very large database of WLAN passwords. Not using it yourself is just half of the solution. There is a friend coming with his Android, "Can I use your WLAN?" - and Google knows your WLAN password. Google will know your company's WLAN passwords too. Regards Peter
On 19 July 2013 10:03, Petros <Petros.Listig@fdrive.com.au> wrote:
https://code.google.com/p/android/issues/detail?id=57560
So, your smartphone/tablet will have a list of all the WLAns you connected to. Stored unencrypted.
This seems to be under dispute. Nobody really knows how the data is stored. Although if you wanted you could check AOSP source code and see how data is transmitted to Google. It would appear however, that even *if* Android encrypts the data before sending them to Google, Google has or could get access to the information required to decrypt them. For example, the data could be encrypted with your password. Which Google shouldn't be storing in clear text. However they get access to your clear text password every time you login to their servers. Maybe a small technically point; unfortunately it looks like the bug might be ignored due to another technical point (is it a bug in AOSP or Google cloud?). Kind of important to get the details correct. At one stage, perhaps years ago now, I seem to vaguely remember I could access this information using Google Docs, and it didn't appear to be encrypted. Think they have removed this access now. -- Brian May <brian@microcomaustralia.com.au>
Petros wrote:
https://code.google.com/p/android/issues/detail?id=57560 Google will know your company's WLAN passwords too.
Time to adopt EAP-TLS. Single-factor auth is *always* shitty. Of course, then you will have users with passphraseless TLS certs, and it turns out the CRL doesn't work in hostapd's built-in RADIUS server. Also it turns out that your enterprise-ready MFC doesn't support EAP-TLS, only fucking PSKs. And the x360 in the break room only does PSK. And the iPhones can do EAP-TLS, but only if they're jailbroken *or* you deploy a puppetmaster-type provisioning server for iDevices (which isn't an option anyway because they're BYOD). IIRC the maemo phones worked, but only if you killed their in-house wifi daemon and ran wpa-supplicant by hand, which chewed through the battery. So what I do now, to my disgust, is per-MAC PSKs - which I generate for the users (so they have full entropy), and which are all stored in plaintext on each of the APs. But at least I can revoke them by commenting them out. And the clients can be dumb as bricks. Attached is a patch that enables either approach for OpenWRT as at either backfire or aa (the script didn't change between releases). PS: yes, I know about EAP-TTLS. It's exactly as shitty as not using client-side certs for HTTPS. Also the wifi alliance only requires EAP-TLS for device branding, so in theory that's way more portable (except it isn't, see above).
On 19 July 2013 10:03, Petros <Petros.Listig@fdrive.com.au> wrote:
https://code.google.com/p/android/issues/detail?id=57560
So, your smartphone/tablet will have a list of all the WLAns you connected to. Stored unencrypted. And sends it to Google (according to heise.de this is the Default on all the Android systems they tested it).
It is perhaps worth noting that this is an issue with the proprietary Google android apps. It isn't a problem with the the Android open source (AOSP), which apparently doesn't have the Google backup transport. Not until you install the proprietary Google android apps anyway. https://code.google.com/p/android/issues/detail?id=57560#c33 Having said that, this is a perfectly good point too: https://code.google.com/p/android/issues/detail?id=57560#c35 -- Brian May <brian@microcomaustralia.com.au>
participants (3)
-
Brian May -
Petros -
Trent W. Buck