
Android saves wifi passwords in plaintext to the cloud - JanLaussmann
https://code.google.com/p/android/issues/detail?id=57560
======
enginous
What key are you going to encrypt these passwords with?

If you were to encrypt passwords in the cloud with a key that's stored on the
device, you can't unlock the passwords on a different device (or the same
device after flashing), which is the whole point of backing it up in the
cloud.

If you were to encrypt them with the user's Google Accounts password, the
device would need to ask for that password on every startup or store the GA
password on the device at all times (the latter option is a far greater evil
than the current "situation"). As long as Google is ever given the clear text
password (i.e., before hashing), this would be open to interception by Google
-- or infiltrators thereof.

If the GA password were to be used to authenticate in a way where Google
doesn't get access to the clear text password (through digest-like
authentication), a user wouldn't be able to access the backups after resetting
her password. However, this method is not reliable if you don't trust Google
(or its infiltrators), because Google provides the clients that would do the
hashing before sending the password, so they could obtain the clear text
password (by skipping the hash step, or by sending it through side channel) on
any client they control such as HTTP login pages or mobile apps provided by
Google.

Like all things security, it's a trade-off between security and convenience.

~~~
brudgers
Horseshit.

Setting up a password for an Android device only needs to be done once for
each device->network pairing. The reuse of Wifi passwords across devices is an
edge case given the predominate ownership pattern of Android devices - i.e.
most people have a phone that runs Android and no other Android device.

Google's scheme allows them to harvest the passwords to a vast number of
wireless networks.

Google has harvested the location, name and signal strength of many millions
of wireless networks across the world - an act which can be in no way cast as
user convenience.

The very best possible light for this nexus is that it only appears to be a
very very bad thing.

~~~
jsnell
If you're going to dismiss an argument as "horseshit", you should perhaps
offer a compelling alternative. Because your idea of what is going on is
frankly ridiculous.

It's easy to see the user-experience story for this. Upgrade your phone, buy a
tablet, etc, and as by magic all 10 wifi networks you use work without any
configuration. No need to type that 32-character nuisance of a WPA2 password
again, etc. How lovely!

Your conspiracy theory hinges on the idea that Google wants your precious wifi
password for themselves, not for your convenience. That seems unlikely. Google
doesn't care about your network. They might care about your web usage patterns
insofar it makes it easier to provide better search results and improve ad
targeting. Your network is worthless for that. Using the passwords to actually
access these wifi networks would also be a massive legal and PR nightmare.

So on one side you have delighting users. On the other side you have a
malicious attempt to gather useless data at massive risk. How can there even
be a question of which explanation makes more sense?

~~~
brudgers
Encrypt the data on the device. Backup encrypted version in the cloud.
Download encrypted backup to new device. Unencrypt on new device. Merge
versions on the device.

No need for plaintext on Google servers. No way for monetization by Google.

Or to put my alternative another way, how much is a data set mapping WiFi
passwords to networks for the city of Bejing worth to a foreign intelligence
agency or other state-level actor? An answer in terms of dollars or 1000
clicks is equally acceptable.

As an alternative, how much is such a data set for Redmond worth to Google?

For extra credit, determine the value of each data set if includes historic
data on password changes, changes to the individual password repositories of
each user, and changes to the densities of WiFi networks at specific
locations.

In the end, it comes down to money in Google's bank account, not delighting
users (see Reader). Since Google does not directly profit from the sale of
nearly all Android devices, the burden for the thesis of delight is to show an
alternative mechanism by which Google directly profits from the plain text
storage of passwords.

~~~
jsnell
You're providing innuendo and "exercises for the reader", not an argument.
That's pretty weak.

What would such a data set of Redmond be worth to Google? Nothing. Because
accessing those networks for industrial espionage (if I read your innuendo
right) would be illegal and immoral. It would drag Google's name in the mud,
lose them customers, credibility, and most likely a decent chunk of talented
employees. The liabilities would be massive. And what's the gain? I don't know
what you think it would be, but it'd have to be pretty damn valuable to
outweigh the potential costs.

As for monetization... Android is a moat. The way things are going, whoever
controls the client operating system controls the default web browser and the
default web search. This is an existential threat to Google. Microsoft winning
the mobile OS war would soon make Bing the leading search engine. Apple
conclusively winning would allow them to charge monopoly rents on access to
the users.

It's like Google Toolbar back in the day. It's possible it provided some
information about user behavior. But the real value came in that it added a
visible Google search box into IE.

~~~
brudgers
I look at the money.

Google made $10 billion last year.

In a cyber-war, how much would the Kremlin pay to disrupt every Chinese WiFi
network to which an Android device has a current password?

In a shooting war, how much would the US pay? Keep in mind that the modern
battlefield increasingly uses ordinary data devices particularly in counter-
insurgency operations.

Jim McDonnell, Donald Douglas, Jack Northrup and Leroy Grumman did not start
out as defense contractors. They diversified their corporations when
voluntarily seizing the opportunity was a good alternative to the threat of
compulsion during the Second World War.

This may in fact be the one time that the rules are different. But there's
very little historical precedent upon which to premise such a belief. GM
produces military vehicles. Westinghouse and GE produce powerplants for
ballistic missile submarines.

[edit] The question of how plaintext leads directly to Google profits remains
unaddressed. It is not as if Android users can recover their passwords by
calling up Google customer service. On the other hand, storing passwords in
plain text is usually a decision made to facilitate requests from a company's
customers. Asking who constitutes Google's customers is a reasonable place to
start when inferring motives.[/edit]

~~~
mik3y

      I look at the money.
    
      In a cyber-war, how much would the Kremlin pay to
      disrupt every Chinese WiFi network to which an Android 
      device has a current password?
    

Do you think Larry Page can be bought?

I'm serious: You need to consider the way Google is run before deciding if any
of these theories are plausible.

This is a company which has a history of spurning money-making opportunities
in favor of some higher ideal (often times to the chagrin of business-minded
types within the company). To give a few examples: Licensing Android,
complying with China, accepting paid placements, etc.

You can argue each of those decisions was actually more profitable for Google
in the end. And that's the point: Google would not make $10B next year if they
sold out their users to the Kremlin this year.

~~~
brudgers
My opinion about Larry Page's price is that it depends upon who is buying and
what they are offering. An offer similar to one from the Kremlin which is easy
to refuse might be one he cannot refuse from Fort Meade.

But lest my meaning is misunderstood, an offer from Fort Meade might be one
Mr. Page gladly accepts as a US national - I certainly have no more reason to
question his patriotism than to believe it to be partisan in the extreme.

Even removing patriotism from the equation, developing and maintaining good
relations with governments and their agencies involved across national borders
probably makes sound business sense for a company of Google's size. And I have
little doubt that Mr. Page places substantial value on international business
opportunities.

------
bhauer
Yet another place where I feel a tinge of anger that VPNs utterly failed to
deliver on the potential of private secure connectivity to personal data
storage from anywhere. Several of us here at HN set up and manage home
networks to which we connect over an encrypted channel. To us--well, to me at
least--it seems plain as day that my device should allow me to backup its
sensitive data to a file that _I store on a file system of my choosing_. I
would store it on my encrypted disk array at home (which is then backed up to
a data center disk array).

But to a layperson, the lack of a secure private channel to personal data
storage remains an infeasibility. So laypeople embrace third-party "cloud"
storage offerings, this one included. These services offer omnipresence of
data. They don't offer personal control, but many people are willing to
concede control because omnipresence is such a convenience.

Putting all of that aside, however, and accepting the world as it is, with
VPNs the tragedy of user experience that they are... An open question remains:
why not ask the user to create a passphrase for use in encrypting the device's
data before storing it at the GoogleCloud + NSACloud?

The seemingly obvious answer to the rhetorical question is a worry about user
experience pain ("woe is me, I need to remember another passphrase now"). So
perhaps the user would be instructed to provide a passphrase if and only if
they are concerned about their backup being stored on the NSACloud. If they
are not concerned, they can leave the field empty.

~~~
js2
Back to my Mac pretty seamlessly establishes an ipsec connection back to a
time capsule or other Mac on your home network.

~~~
ctb_mg
Yes, but as far as backups and backup security is concerned -- a time capsule
is fairly proprietary, and a Mac on your home network is susceptible to local
catastrophe.

------
jmngomes
This reply "This report applies to a mobile Google application or service, and
the issue tracker where you reported it specializes in issues within the Open
Source source code of the Android platform." is a bit off, IMO.

The developer reported a bug found on Android to the Android forum. The reply
he gets sounds like a dismissal, which is quite strange given that the problem
is not only related to Android but also with a Google product.

A few days ago I submitted an Android bug verified on a Samsung phone. The
reply was something in the line of "that's Samsung's problem, talk to them".

I'd say this isn't the right way for _Google_ to handle a severe issue such as
this, i.e. simply rejecting accountability. It's like having a team say "go
talk to some other team" when they're actually all aboard the same ship. Is
big company bureaucracy / turf wars getting to Google? Hope not...

~~~
hrjet
This.

I recently found the same irksome behaviour by Goog on another important
issue:
[https://code.google.com/p/android/issues/detail?id=56803](https://code.google.com/p/android/issues/detail?id=56803)

~~~
DannyBee
From what I can tell, JBQ is right and the maps folks are not understanding
the issue you have. :)

The Location Services API is not part of AOSP (or at least, this
implementation isn't) IIRC

You should rephrase the bug report to make clear you are talking about the
google play services location API.

As for the complaint on that bug report that google should file and track
these issues for folks, AOSP is an open source project, and like most open
source projects, prefers folks file upstream/downstream issues directly.

------
spdy
With the street view wifi scandal, this on going encryption problem and the
revelations about prism this looks very bad.

~~~
sil3ntmac
Reference: [http://www.engadget.com/2013/04/22/google-street-view-
fine-g...](http://www.engadget.com/2013/04/22/google-street-view-fine-
germany/)

(for others like myself who had not heard of this)

~~~
Plutor
Just to add to everyone's knowledge: this Street View wifi snooping was a)
three years ago, b) accidental, and c) only known by the public because Google
voluntarily revealed that it had been doing it (and immediately deleted all of
the collected data).

------
rsync
The title is, I think, a bit misleading. That's because it is not Android per
se that is sending your wifi passwords to the cloud, it's the use of the
"backup my data" tool.

If you're interested in robust, secure storage of your data, the candy-
flavored OS built-in-cloud-tool may not be your best bet. It's only there to
check a feature box on a sales card.

"Oooh but I get 5 gigs for free!"

------
DanBC
Frustrating that it's really hard to make my android phone show me the saved
password it's using for a wifi.

------
nodata
..otherwise it wouldn't work.

You can disable backups when you setup your phone.

~~~
TallGuyShort
Otherwise what wouldn't work?

~~~
Dylan16807
Saving wifi passwords to the cloud.

------
foley
And all for nothing - none of my Android devices have ever restored my wifi
passwords, it is always a mission to find and input my password on a fresh
phone.

~~~
myko
I've always had great experiences upgrading Android devices. Once I log in for
the first time they sync wifi and applications pretty seamlessly.

My wife recently picked up an S4 and none of her things synchronized. I was
pretty surprised at the time but thinking about it later I realized the AT&T
clerk skipped the initial sign-in process. It looks like the option to sync
old apps/passwords is only available upon launching a fresh device (which
being a Nexus user no clerk ever bypasses setup on my devices).

Anyway, this might be why your phone isn't syncing? I'd be interested in
seeing some option to force sync Android devices with backed up data at any
time.

------
babesh
No need to belabor the point given the many examples beyond this one. If you
want security, you're not going with Android. If you want configurability,
you're not going with iOS.

Android: slurping phone numbers, texting behind the scenes on your behalf,
etc...

iOS: no access to apps that Apple doesn't approve, no replacement of built-in
apps with third-party apps, etc...

These systems were not built exactly with your benefit in mind. Android was
built to prevent Apple domination of mobile and thus continue selling ads by
providing services. Apple has several services that would be much more useful
cross platform but are not: Facetime, iMessage, etc... and that reinforce
platform lock-in.

~~~
nly
> Android: slurping phone numbers, texting behind the scenes on your behalf,
> etc...

Debatable. If you install something like Permissions Explorer you can see
which apps access your contacts and/or texts. It's generally a small list. And
the Google sync features can be disabled.

~~~
babesh
The problem is that you've checked the chicken coop AFTER the fox has gotten
to the chickens.

------
pedrocr
Google could use this to bootstrap a FON like worldwide network. Have an
additional option in the settings for "Make this network part of Google Free
Wifi" and then any android phone anywhere can connect seamlessly to the
network. If you change the security settings they are immediately updated
because you also update them on your own phone.

At least for networks that are already designed to be public (e.g., coffeeshop
wifi) this would be awesome. For my home network I'd have to first setup a
second SSID myself that I firewall from the rest so that I don't expose all my
wifi devices to any passer by. That bit isn't very user friendly.

------
jpalomaki
I guess it would be fairly difficult to make this truly secure without making
it too difficult to use. Simply encrypting the data with your Google account
password does not do much good, since you are going to provide that password
to Google and they could obviously use that to decrypt the data (should the
government request it).

One option would be to use separate password for protecting the data, but that
would not be very convenient for the user. Very easy to forget such password
since you are not going to need it very often.

------
keithnoizu
That's a feature, saves NSA from the effort of building up rainbow tables.

------
brudgers
The most plausible explanation for this behavior, if the assertions are true,
is that Google is acting in a way which serves its customers interests.

If you don't write checks to Google for a service, you are not among Google's
customers.

------
durkie
I know it doesn't really address the issue at hand, but as an alternative here
Android features a little-documented local backup feature that can be done
through adb, and can be encrypted.

Even google's official adb page has no mention of it, but I've done it and it
works fine: [http://tutznet.com/1283-perform-full-backup-android-phone-
ad...](http://tutznet.com/1283-perform-full-backup-android-phone-adb/) (not my
blog -- just the least spammy site i could find)

------
somesay
Of course, they don't ask for a specific password.

"Encrypt synced passwords with your Google credentials" is impossible in times
of app specific passwords, right?

~~~
Tomdarkness
How Chrome for Android handles this, which supports encrypted sync, is that
after logging in it will prompt you for your real password so that it can
decrypt the sync data.

~~~
somesay
Sounds handy, but at some point breaks the concept of not saving the main
password on any platform. Still not that bad, since app specific passwords
only are in use if you also have 2-factor-login.

------
ksowocki
If anyone hasn't downloaded [cloud to
butt]([https://github.com/panicsteve/cloud-to-
butt](https://github.com/panicsteve/cloud-to-butt))

Let [this]([http://cl.ly/image/1X0o212T3B0Y](http://cl.ly/image/1X0o212T3B0Y))
be your reminder to do so.

------
krapp
At this point I feel you might as well assume that every device and every
website stores your credentials in plaintext until explicitly proven
otherwise, I guess. Or _maybe_ unsalted md5 if they're a bank.

------
tazjin
I would like to know how this works with 802.1X credentials. Does this
"feature" save my company internal LDAP password that I use to authenticate to
the network to the cloud? Unencrypted?

------
Kurts
You can turn it off if you like: Settings > Privacy > Backup my data, backup
application data, Wi-fi passwords, and other settings to Google servers.

Every few months someone rediscovers that Google also syncs Wifi credentials
between devices (perhaps when logging into a new device and finding it tethers
itself nicely to the network on its own).

It's a matter of convenience, Wifi passwords are only applicable at a certain
range, and other restrictions could be applied even then (like hardware
whitelisting etc) it's not your bank credentials.

Here's a reddit discussion (from 2 years ago!)
[http://www.reddit.com/r/Android/comments/g6ctt/just_upgraded...](http://www.reddit.com/r/Android/comments/g6ctt/just_upgraded_to_nexus_s_am_a_little_freaked_out/)

~~~
nwh
> like hardware address whitelisting

I wouldn't recommend that in any circumstance, it's completely false security
really.

MAC filtering is incredibly easy to bypass, all Malory has to do is wait for
another device to connect and clone their hardware's address.

~~~
yardie
It's also a diagnosis nightmare. The ISPs in my country used to use WEP with
MAC filtering with their wifi-routers. The password was mildly complex (16
characters) and on a label on the box. Most users never changed the password.
So Joe Blow connects his laptop using the password on the sticker, and it
doesn't work. Imagine the same problem for a few million users.

It's false security because (especially for wifi) MAC filtering is like a
verbal password that's been written down on a billboard. Everyone can read it
so its not a secret.

~~~
nwh
Heh, even the longest possibly WEP key can be broken in a few minutes with
consumer hardware. At least ISPs in Australia use WPA as standard.

~~~
yardie
They use WPA2 now and from a few years ago. The cheap wifi-routers they sent
out years ago didn't have the muscle to do WPA encryption.

~~~
nwh
Our have for a while too. Sure the password is the hash of the the routers MAC
and the manufacture date, but they did try.

