IssueTracker

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.

We are not able to provide support for Google products in this issue tracker. Please use the Google Support site for help at https://support.google.com/ or report this issue in the most appropriate Google Product Forum at https://productforums.google.com/forum/#!forum/en/ and especially in https://productforums.google.com/forum/#!forum/mobile

"backup data" is a Google service. This website is for developer issues with AOSP Android which doesn't include a single Google service.

Thanks, I'll try filing this bug in the appropriate place.

Are you sure, JBQ?
The BackupManager is afaik part of platform_frameworks_base and the setting app itself decides what data to back up - and this would be the place where to hash passwords or disable saving them completely (which imho should be opt-in).
Of course, Google provides the backup transport to store BackupManager data it in their cloud.

Nonetheless, the data send from BackupManager should have a level of encryption.

how did you figure out that the pwds are stored in plaintext?

hashing the passwords doesn't make much sense, though. Then you can't use them anymore. They should be encrypted. And the problem with encryption is, that you need to trust your encryption supplier if you don't do it yourself. And that supplier would be the same you trust your to at the moment: Google.
So I think the security of your data wouldn't improve much anyway. Also I hope Google already encrypts the stuff and doesn't send my passwords unprotected over the wire.

I think Erik is wrong here in saying that the security wouldn't improve much anyway, ultimately you have to trust someone, yes, for example, I trust Google when they say they are encrypting my synced data with a passphrase - perhaps this trust is mistaken. The point of encryption however is that you *don't* have to trust anyone else. For example, I would not need to trust the network that I'm on from snooping on my traffic to get my wireless passwords, and I would not need to trust that datacenter employees at Google would not make a copy of my data. Finally, and here's the most salient issue of our time: I don't need to trust that a state actor, whether our own (in the form of the hyper-aggressive NSA) or another (such as the UK GCHQ allegedly capturing and buffering all data traffic that enters or leaves the UK.)

The point of encryption is that it reduces the surface area of people I need to trust. You can't ever get that surface area down to zero, but with defense in depth and a modicum of trust, you can be a great deal more certain that it's close.

Yawh...@gmail: I remember a command in terminal (requiring root rights to access the file) that listed every single WiFi and password i`d connected to. Definitely not encrypted. Not going to mention name/location but a quick Google search will bring it up

Ok, I have posted about this in Google's product forums as well: https://productforums.google.com/forum/#!category-topic/mobile/android-devices/android-applications/D6vWpQu8AWU

If it is the case that this is an Android bug, then this issue is still open here.

yawh...@gmail.com: About figuring out if the passwords are stored in plaintext, if Google has the ability to see the plaintext of them it's irrelevant how they're stored on disk. They can be compelled to give up the plaintext version. I know that they have access to the plaintext because, after formatting my phone and flashing a stock Android ROM, I logged into my Google account and automatically connected to my password-protected wifi.

computer...@gmail.com: If you're using Linux with NetworkManager, that command is: sudo cat /etc/NetworkManager/system-connections/*

micahf...@gmail.com: meant in android terminal. Screw it, it's /data/misc/wifi/wpa_supplicant.conf

@michahf...@gmail.com: That doesn't mean it's stored in plaintext. That simply means that your android device was able to retrieve the plaintext password.

Have you determined that the passwords are actually sent and stored in plaintext, or are you assuming that because your phone can retrieve the plaintext that it's transferred and stored as plaintext?

Its not necessarily in plan text. They could use your account details to encrypt the data, and retrieve it based on your authentication credentials.  In this sense logging into your account is the equivalent of decrypting your online password storage.

There seems to be some disagreement about whether this data is encrypted. I think that this confusion is because -- while we're all using the same word -- we're thinking of different designs.

When Micah says "encrypted", he means that "Google can't get at the plaintext". If we apply the mud puddle test (http://blog.cryptographyengineering.com/2012/04/icloud-who-holds-key.html), we should conclude that Google *can* access the plaintext, because you can destroy a backed-up phone, change your Google account password or log in with an application-specific password, then get your data back.

It appears that commenters 7, 8, 11, 12, & 13, are referring to to the prudent use of encryption in other places, such as ensuring that when this data is sent to Google, that is done over an encrypted link, or that Google or your phone store this data in an encrypted format (while also having access to the key needed to decrypt the data).

It is thoroughly prudent to encrypt data in transit, at rest and so on. That's sensible security practice, and we would expect nothing less. What Micah is asking for is specifically the ability to encrypt the data with a key which is not accessible to Google, so that no matter who tried to force Google to give up this data, they would be unable to. Google simply would not be able to access this data.

But if Google would add such a functionality, then in my opinion you lose more than you gain. If you keep up the policy of never reusing a password and also have a really strong password for your W-Lan, then why encrypting it?
If you encrypt it (also with a strong and complex keyphrase) and forget this keyphrase then you'll lose the convinience of this functionality. Why backing up your W-Lan password online, when to get it(if replacing the phone), you have to get your super-complex keyphrase first(which you obviously can't backup on google). Then why backing up your W-Lan password in the first place? Just remember it instead of the keyphrase for it's encryption.

And I really understand that everyone is really concerned about security nowadays, but I don't really care whether my government has my W-Lan password. I doubt some govermental staff will be sitting in my garden and surfing with my W-Lan, because they got the password.
The government doesn't really gain anything from this if you don't reuse this password anywhere else.

@Flamsmark - I am in fact referring to the latter form of encryption you mention, which is akin to the way Google Chrome Sync works when the user sets up a passphrase.

My wifi password is a randomly generated string with 20-30 mostly non-alphanumeric characters that I email to people when they need it.  If it is compromised I will generate a new one and I don't use it for anything else.  I suggest you use the same strategy.

A workaround could also be to use WPA2 Enterprise with a RADIUS server, which would allow you to revoke keys for different devices.

"We are not able to provide support for Google products"

Android is not a Google product ? WTF

oakw...@gmail that is a completely ridiculous workaround. What home user is going to know how (or even take the time) to set up a RADIUS server?

How about making it optional for Google to back up WLAN passwords at all? As it is, users can either opt to back up everything including these passwords, or nothing. I'm fine with backing up a lot of application data, it's convenient and useful, but I would *greatly* prefer not backing up my passwords.

[Comment deleted]

[Comment deleted]

drewwalt...@gmail.com

I did not suggest that it was intended for home users. How is that ridiculous? It is an established method of ensuring security. I was merely pointing out that if you use RADIUS authentication, you are still mostly protected from a single device key being leaked (e.g. to Google) and that it is also the fault of wireless router manufacturers for not including a basic RADIUS server in their products - if RADIUS was widespread and built-in to most access points, key leakage would not be such a large concern.

This is definitely a situation in which convenience was chosen over security. At the very least, the keys could have been encrypted with your Google account credentials before being uploaded to Google's servers.

chris.j...@gmail.com #17 solution is one of the worst idea I've read : 1- Having your password randomly generated doesn't change the problem that Google is able to read it; 2 - Sending your password by email is just an additionnal way you give to hackers to sniff it; 3 - Your «If it is compromised» statement is hilarious: the moment you know it's compromised, well, it's already too late ;-)

@#15 lSoleyl

"And I really understand that everyone is really concerned about security nowadays, but I don't really care whether my government has my W-Lan password. I doubt some govermental staff will be sitting in my garden and surfing with my W-Lan, because they got the password. "

Thats because you are viewing this in the perspective as a home user.  If you have an enterprise corporate wireless network using 802.1X (like eduroam) then the credentials used to login to that wireless network are your corporate credentials.  These could be used by intelligence (or google or others) agencies to login to VPNs, Servers, etc.. and steal confidential material.

[Comment deleted]

[Comment deleted]

Is the general public willing to lose access to their backup should they forget their password?

If the answer is "no", then it doesn't matter what Google does because they will need to access the original password to decrypt and re-encrypt the new password with the payload (Wifi credentials/backup data in this case) -- or the more likely case, the data was never encrypted at all; most website back-ends do this with user profiles.

Most people forget their passwords at one point.


Side note: It's still not clear if the original poster is just paranoid that the data comes back unencrypted, or he actually did a packetsniff on his WiFi / Router and found that the data itself was being transmitted plaintext (i.e. not over HTTPS or similar).  If it's the latter, then yes, it's something that needs to be fixed.

If it's the former, then this is overblown.  If the OP feels the need to protect against big brother and is willing to inconvenience himself by losing all his backups if he ever forgets his password, then he can take the AOSP code and make his own online backup service that does this.  (Name one other mainstream OS that allows you to do this this!)

Enterprise users are free to force-disable Google backup and use their own service.

Offline backups have no password recovery, so if the OP is really paranoid -- just do an ADB backup / use Helium.

I would like the option of WHAT i backup..not just all or nothing.  Even in Google apps for business we don't' have that choice.

Googlenew.com

I just published another blog post about this issue: https://micahflee.com/2013/07/despite-googles-statement-they-still-have-access-to-your-wifi-passwords/

Android team, pay attention to this part:

"The correct response for Google at this point is to label issue 36949180 (“Backup and restore” should offer encrypted backups) as a security bug, set the priority to High, and promptly release an update to Android that fixes this bug."

Answering the questions in #4 (knapp.robin), #19 (epervie..) and #32 (micahflee) - please don't shout me down, I'm only trying to help!

As JBQ stated, this website is for AOSP Android, not Google apps or services. Although AOSP Android includes the BackupManager, there is no actual Backup transport as part of AOSP (see screenshot below of the "Backup & Reset" screen in the settings app). An AOSP build of Android has *no* Google login facility at all.

It's only when your device includes gapps/gms that the option to "backup my settings" appears (see second screenshot of a device with gapps/gms installed, which clearly mentions "Google servers"). Only once you have gapps/gms installed can you login to a Google account on your device as well.

So JBQ is correct when he closed this issue as "WrongForum" - your concerns with (a) encryption, (b) wifi passwords or (c) content are all part of the Google backup transport which is not open sourced or part of the AOSP project, or therefore supported by this website. The Google backup service is documented ( https://developer.android.com/google/backup/index.html ) where it clearly states "The Android Backup Service offered by Google provides a backup transport on most devices that include Google Play Store and backs up your app data to Google servers."

I don't doubt this conversation has been very interesting - I've been following it from the start - but as JBQ states, if you want to try to effect any change in Google, or indeed any response, you need to use one of the forums specifically for Google apps.

#10 created a new post in a more official Google forum ( https://productforums.google.com/forum/#!category-topic/mobile/android-devices/android-applications/D6vWpQu8AWU ). You are more than welcome to continue with the conversation here, but please refrain from the "Google fix this" or "Google please reply" as you won't get a reply or a comment about any Google services on any issue on this AOSP website. That's just the way it is.. :-(

There's no point saying "Android team fix this" as there is clearly nothing in AOSP to fix - AOSP Android has provided a generic backup facility that allows apps to backup "data" to a third party service. It's the Google Backup service that chooses what data to backup and exactly what format/encryption to send it to that third party service.

hbls00..., sorry, didn't mean to shout. I was just surprised to see Google respond to the media with vague denials, but not to this issue in particular. Nothing against you of course. I'll try bumping the Google products post.

Hang on, that interpretation means that every backup service must implement its own crypto for this purpose.

Why design it that way, when encryption *could* be done generically for any backup service? If this is just for backup, there's no reason to let the backup service see cleartext data, right (when the user chooses to provide a passphrase)?

Putting this functionality in an open-source OS component rather than in each (often closed-source, as in the case that motivated this issue) service implementation, could significantly increase confidence that it's being done correctly. There are many important details in how the crypto is done that would then be subject to open review, as they should be.

@davisar has a point! i would definitely expect this to be part and parcel of the standard backup service.

so, please re-open this issue.

I agree, @davisar makes a good point.

Recently published leaks (http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security, http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html) confirm that NSA has been working with commercial software vendors to backdoor their crypto.

Any client-side crypto that Google implements to protect it's users' privacy should be part of the open source Android project and not part of the proprietary Google Apps.

Please at least consider this feature request.

Hi,

I think the original request was to add client side encryption to Android, so that backups could be stored potentially anywhere, without revealing your key to the company whose servers you store it on.  

This seems sensible to me, and is not specifically to do with a Google service.  Can this issue be re-opened please?

thanks,

Chris

Is Google addressing this issue?

Alternatively, why not have the option to save WiFi passwords as a separate option?  I would like my apps, app data, and app settings backed up.  I DO NOT, however, want Google to have the key to my home network.

Hello all, i recently formatted my phone, with the backup option on (including the wifi password), however, the wifi password did not restore and now, i want to know the location of the wifi password backup location, so that i can manually punch in it. any help would be greatly appreciated.

Joseph

[Comment deleted]

Can we close this non-issue

I am still impacted by this bug but I am un-starring it to not receive more spam

Please visit : https://transferemails.com/gsuite-email-archive/