IssueTracker

This needs to be fixed.

Please help fix this...

Please fix this. thanks

[Comment deleted]

Bump

[Comment deleted]

This is a security risk and should be fixed.

Please fix.

Pretty serious stuff, especially for people with rooted phones!

This should be immediately addressed.

I would think a breach like this should be elevated above Priority-Medium.

fix please!

Fix now please?

This problem should not be of medium priority, this needs to be fixed ASAP.

I would expect this to be fixed ASAP and better from google!

I would expect this to be fixed ASAP and better from google!

glad someone found this out! can't wait for it to be fixed

This isn't just something that will affect root users. If your phone is stolen, a thief can root it and then pull the data.

should be fixed at the earliest

Please fix asap I just rooted and feel very vulnerable to be attacked.

[Comment deleted]

Please fix this issue asap. Why would you not encrypt sensitive data. not cool google!!!!!!

Please fix

Read before you post comments!

Comments saying "please fix" and the ilk do nothing towards getting this issue fixed, and in fact send an email to everyone who has starred the issue.

If you want this fixed, star the issue. Only post comments if you actually have something to contribute.

Surely should be top priority for Google as you cannot expect the user to always check if the app he installs is a good one or rouge one!

[Comment deleted]

Yeah, this should be fixed.
Thanks.

What was google thinking? This is the most important information that should be encrypted. Duh.

Please re-prioritize as 'high'.

Please prioritize as High! This is extremely important.

So lets see if I get this correct:
The article I read on Android Central stated the following:
"Certain applications, including the stock Froyo "(Android 2.2) e-mail client, store your username and password as plain text in the phone's internal accounts database. This includes POP and IMAP mail accounts, as well as Exchange accounts(which could pose a bigger issue if it's also your domain login information)."

My response is that since MA and other states require encryption of storage on any mobile device that may have PII then we would need to remove any android phones from accessing exchange.

I got some feedback from another user stating the following:

"The exchange data is encrypted. Lets not run out and spread fud, ok?
The decryption key is store un-encrypted (although it is cleartext it is unintelligible gibberish). That's all this story says. Think that through for a moment or two and you will realize that unless your phone is set up to require you to key in a password each time you open the phone SOME encryption key somewhere is going to have to be stored unencrypted."

So which is it? I show my info plain as day on the Captivate which is a Galaxy S class phone.

Any input?

Pretty scary, bump for fix.

Check out TextSecure. It requires a password to access your text messages every time your phone is rebooted. Clean, secure, good enough for the average user. I wouldn't mind entering a password every time my phone is rebooted (doesn't happen that often anyway).

This should be high priority!

Please fix this issue.  Security can not be compromised on any system.

reddit!

I don't think this is serious issue. See here for a good argument why:
http://developer.pidgin.im/wiki/PlainTextPasswords

Looking at the Pidgin site, it seems like having an option to encrypt the password based on your lock code (if you have one setup) would be analogous to their "Store a password(s) behind a password" option. Doing this on an Android device would allow those who aren't as concerned with security to not use a lock code/pattern, and allow those who need enhanced security to use a lock code/pattern with would double as the encryption key.

[Comment deleted]

PLEASE STOP THIS ME TOO STUFF AND USE THE STAR AT THE TOP, THE COMMENTS ARE FOR HELPFUL FEEDBACK RELATED TO FIXING THE ISSUE.  We have 40 comments of me too and that does nothing but pollute this page and make it harder to read what is important and that is if you are not smart enough to know the risks of rooting your phone, there is a reason it doesn't come this way by default, similarly if you run a Linux OS at home, there is a reason they recommend running as a limited user and not running as root...

I don't think using the lock code would really help, since services have to be checking your email in the background perhaps before you've unlocked it.  Also, I suspect the lock code is also stored somewhere in plaintext (though that's just speculation)

One more vote.

Please fix.

While I hate to post anything not pertaining to the fixing of this, I need to point out that even a locked device is accessible via adb, -- 2 minutes, a data cable, and a SQLite viewer gives me your Exchange password no matter what screen lock mechanism you're using.

> 2 minutes, a data cable, and a SQLite viewer gives me your Exchange password no matter what screen lock mechanism you're using.

Really??? Even if the phone is not set to enable debugging via USB? If so, then this is *definitely* not medium priority... It is CRITICAL!!!

I agree this is more than a medium priority.  Some kind of encryption for the passwords should be a must.

[Comment deleted]

Hello-

Thanks for the information and the feedback on this concern.

First, I would like to reiterate the notes made by a couple of you, which is to remind users that if you are concerned about this issue, *please* simply click the star.  Every time you respond "please fix" or "should be fixed!" it sends email to over 200 people.

Second, please know that we take information security very seriously, and this is baked into the Android platform at multiple levels.

Now, with respect to this particular concern.  The first thing to clarify is that the Email app supports four protocols - POP3, IMAP, SMTP, and Exchange ActiveSync - and with very few, very limited exceptions, all of these are older protocols which require that the client present the password to the server on every connection.  These protocols require us to retain the password for as long as you wish to use the account on the device.  Newer protocols don't do this - this is why some of the articles have been contrasting with Gmail, for example.  Newer protocols allow the client to use the password one time to generate a token, save the token, and discard the password.

I urge you to review the article linked to in comment #38, which is well-written and quite informative.  It provides some very good background on the difference between "obscuring" passwords, and making them truly "secure".  Simply obscuring your password (e.g. base64) or encrypting it with a key stored elsewhere will *not* make your password or your data more secure.  An attacker will still be able to retrieve it.

(In particular, some claims have been made about some of the other email clients not storing the password in cleartext.  Even where this is true, it does not indicate that the password is more secure.  A simple test:  if you can boot up the device and it will begin receiving email on your configured accounts, then the passwords are not truly secure.  They are either obfuscated, or encrypted with another key stored somewhere else.)

To the author of comment #44:  If you can obtain *any* data from files in /data/data/* on a non-rooted device, this is a security problem in the device, not a bug in the Email program.  I urge you to contact our security team and provide more information (details here: http://developer.android.com/guide/appendix/faq/security.html)

Having said all this - rest assured, I am not closing this bug.  We recognize that this is causing concern for some users, and we're going to look at identifying steps that can make your data more secure.

Andy Stadler
stadler@android.com

p.s.  PLEASE:  No more "me too" comments - for the sake of the other users who are interested in this bug.  Click the star.

You are right, in that obscuring the password is not enough. But requiring a password every time you restart the phone is a perfectly acceptable solution (at least as an option, where those not so concerned may continue to have a non-secure setup).

However, just because obscuring it is not the answer does not mean that this is a low (or medium) priority issue.

Obscuring the password is not secure, but would be a good first easy step, in the same way people lock their doors. It doesn't really make it harder to get in (locks are easy to pick, and windows are even easier to break), but makes it more trouble than it is worth to a lazy individual.

Encrypting the passwords with a strong key, then encrypting that key based on a gesture would provide a minimal level of real security with a minimum amount of hassle, especially if entering the gesture on unlock of the phone was sufficient, with the key being evicted from memory whenever the handset was locked.

It would be nice to see this solved... I personally think that delivering a quick update with MD5 encryption would be a fast patch for the moment. I don't know what security system uses Google in their servers but I'm sure they don't store passwords in plain text, so implementing the same security system would be nice...

velinion's method in comment #50 sounds very reasonable.
I suggest re-encrypting the stored passwords with a new strong key every time the unlock gesture is changed by the user as well, in case the stored key is ever compromised while the phone is unlocked so changing the gesture also maintains security by invalidate the old key.

A one way md5 hash of stored passwords as suggested by #51 won't work because those stored passwords must later be communicated in their original form with remote services.  The encryption has to be reversible.

That could be another Google security lack, transferring passwords without being encrypted. If one of the steps of the Google security system for storing passwords, that step could be implemented in the phone instead of doing it in the server, thats why I suggested to implement the security system in the server but in the phone.

BTW, I think that would be easy to intergate Unlock features (such a gesture, PIN-code or password) to encrypt passwords.
(sorry for my bad english)

Please fix ASAP!

security is always #1 someone can always take your phone, root it, and take files, I'm sure there are other scenarios. definitely needs to be fixed. how hard is it to change code to not store as plaintext. its dumb to store it that way in the first place.

Blandead - since it's so easy to code, you're going to contribute the patch to the AOSP, right?

Thanks in advance!

I'm willing to help him help, does anyone have any experience doing this that can point me in the direction of being able to test my modifications? I have the source and I do understand that this problem might be outside code that is public api.

@Owner..
I believe security issues like this one could be taken care of if there was some sort of heavy encryption and some sort of psuedo root privilege that allowed access. A god set up would allow all password storing application to utilize the capability of allow their users to store their passwords in a secure area that can only be granted access by entering the psuedo root password.

[Comment deleted]

Maybe the optimal solution could be, as someone said before, a secure ring to store passwords. Many OS's implement them...

I don't think it needs to be anything that complicated, the passwords get stored in that file anyways.. just have the apps encrypt the text before storing it

I agree, and thats exactly how the issues has been solved many times over in the past. I'm certain that in the next future update, it will be fixed.

this has to be fixed immediately!! this is rediculous that they would ever do that

People, please hush up unless you have something to contribute! Stop giving the devs crap about this plaintext stuff. Half of you don't know what you're talking about, and second, the devs aren't idiots. They know the reasons why certain things are done, and they know which items belong in which priority. Let them get on with what they do best. I assure you, it's not reading these stupid comments. This one included.

I have been a professional software engineer for > 10 years now.  First off, I would say that saving passwords in plain text in files is very poor security; even if nobody but you can (ideally) read that file.  It does not matter what the security in place is, if someone steals your phone/device/computer, they can read whatever data you have on it that is not encrypted (not to mention some data that is encrypted.)  

That being said, the more I've looked in to this, the less concerned I am about it (and am considering un-staring it.)  Here's what is happening, as I understand it:  Google IS encrypting passwords on there native apps.  There is one small exception which I do believe should be (and probably will be if it hasn't already been) fixed ASAP and that is the latest native gmail client that has only been released to the N1 (which, I might add, is technically now a development phone.)  

The problem is that non-google applications are saving passwords as plain text.  I'm not surprised that some of them are.  I'm sure some iphone developers have saved passwords as plain text, I'm sure some RIM dev's have as well, not to mention windows, mac, and linux/unix desktop or sever developers.  If you write an application FOR ANYTHING you should make sure you're using good security measures.  It's nice for the OS to provide measures to make it easy, however, it is your responsibility as a developer to make your application secure PERIOD!  The operating system (i.e. android) CANNOT ensure that you write your application in a secure way.    They can go out of there way to encourage you to, however, developers have always figured new ways to do things, and a developer can and will write a program that is not secure; be that through ignorance or creativity.

In summary, I feel this has been blown WAY out of perspective and most of the people seem to not quite get it.  What I believe should happen with this issue is the following:  

1) High Priority - Google should verify that all of their applications are secure without saving any sensitive information in plain text - probably mostly if not entirely already done.

2) Medium/High Priority - If not already done so, Google should provide a simple, easy and secure way to encrypt data (not sure if this is already done.)

3) Low Priority - This is a far lower priority and the most complex - Google should build a process to identify applications that do not store data security and notify consumers.

(_note_ above I mentioned that an OS CANNOT prevent applications from being insecure - technically, that's not true - but for the sake of argument, it's an intractable problem that is not going to be solved in the near future - but that's another discussion.)

RE: Comment 66
Should have "looked into it" a little deeper:
* Gmail's fine.
* Android's stock mail client as built from source and shipped on/pushed to the Nexus One is not.
* Android's shaky Exchange remote admin abilities, combined with a clear text Exchange password is a security risk, no matter how many times someone from Google says it isn't.  And quite possibly may violate the license agreement for ActiveSync.  It should IMO.
* The Nexus One is sold by carriers in many area of the world, as a consumer phone.

RE: Comment 67
I mentioned the N1 gmail client and mentioned that that should be a high priority to fix.  As for the exchange support if you're talking about the exchange provided by carriers - that's not google - if you're talking about the one built in to 2.2 - well, from what I've seen carriers are pulling that out and replacing it with their own in some cases.  I have not seen the true native exchange support.

As for the N1 sold as a consumer phone, I figured someone was going to mention that.  You're right, it's a consumer phone.  Google sold it as a consumer phone.  Many people have it and use it as a consumer phone.  However, in google's defense, they declared it a developer phone before they released FRG33.

Why doesn't Google just expose the api to the existing private Credential Storage api?

The menus under Location&Security/Credential Storage show a checkbox for "Use Secure Credentials" that states:  

Allow applications to access secure certificates and other credentials.

but I can't find any public api for an application to use or store any credentials in this store.  

I would be happy if I could count on a screen lock of a certain strength ( That I specified with my Device Administrator) and secure credential storage facility provided by the OS.

That way my application (and all applications) could store passwords there.  
BTW, it should also be set up so apps signed with the same certificate can share...

@ Comment 69 by RickGillaspy, Oct 25

That's a great idea!
But this make's the password database a primary target for malicious software (as Android is still a pretty open platform).

Perhaps it is possible to (at least) encrypt the SD card.
It should be possible using DES with AES/512 programmed between the storage controller code as layer, which could be controlled from with the settings menu...

Just my 2 cents :)

please - password-protect /gesture protect this DB !

While I'm sure an experienced attacker can eventually get to whatever they are after with enough time. Stating that no protection is better then some protection is absurd in my opinion. That would be like saying we should not lock our doors as anyone really determined will just get past this level of protection anyways.

Do Android developers not lock their doors?

There are different levels of attackers. If you can detour any that is a win. Google should be embarrassed if in fact they've allowed email passwords to be viewed in plain text.

Until users are actually entering a long password (yes, 95% of users will sabotage the security with a crap password anyways) to unlock an encrypted store on their device, complaining about this is totally pointless.

As soon as anybody implements a "store encrypted password here and key there" scheme, the internet fill will with publicly available tools to dump that password.

Implementing that would *not* be a "scheme that stops some attackers".  It would be a complete waste of time for devs and a false sense of security for users.

Anybody who actually cares about this issue should direct their attention towards https://code.google.com/p/android/issues/detail?id=3748

Completely disagree with comment #73 from Alexb..@gmail.com. There are multiple layers of protection that are needed, this is one of the most basic that is apparently missing. Because people can pick a lock should we not lock our doors?

Google must not agree either as they've assigned this issue a medium priority. The same priority level assigned to https://code.google.com/p/android/issues/detail?id=3748.

I also disagree with #73. Any method of encrypting passwords is better than leaving them plain text and wide open for viewing. Preventing easy and immediate access to anyone is far better than the "false sense of security" concerns.

#66/#67 have the right idea.

So I think it *should* be changed, but the overall issue is not high priority. Go to your fav app developers and tell them to sort out their app if it's doing it wrong.

However the exchange issue on 2.2 should be high - it's a bit of joke if Google stores the average consumer password encrypted but the average business user's as plain-text.

If you're a business user in Europe, with a 2.2 device, I'd quote the Sale of Goods Act 1999 (amongst others) and ask for a refund or a replacement of similar value without the flaw. The average user would expect good security with Exchange. If this isn't the case, it has to be advertised as such or it is misleading - essentially you were missold the device.

I don't believe fake security measures do anybody any good.  This issue isn't as important as actual full disk encryption unlocked on bootup, it's a mere distraction.

You have to realize that the android device must be able to un-obfuscate the password to use it, and an attacker will always just un-obfuscate it the same way.

There is no obfuscation scheme that can change that.  It's important to realize that you *need* an encryption scheme with keys outside of the device (like a user-supplied password) if you want to be able to imagine that your email credentials are safe.

re #75: I agree, preventing easy and immediate access to email passwords would be awesome.  TOO BAD YOUR IDEA WON'T PREVENT EASY AND IMMEDIATE ACCESS TO EMAIL PASSWORDS.  Good day.

#74: a better analogy is, should we bother to lock our doors if we're leaving the keys under the doormat and everybody knows it?

A different security model for this should only be put in place if it makes it truly hard for someone to actually suck your personal data off your device. Merely obfuscating the passwords that are stored in plain text or encrypting them with an unprotected key held somewhere else on the device will only make it slightly harder for people who are technically ignorant to get at your data.

In a scenario where someone has their hands on your phone and that person is technically accomplished enough to understand what android is and how to use adb and a linux shell, then they are going to be technically accomplished enough to find keys/run deobfuscators. Even if they weren't, tools would be rapidly published by the community at large for the simple purpose of demonstrating that the "extra security measures" present no real extra challenge. For sure the process of performing password decryption/deobfuscation could actually be automated under the condition where no user input is required to decrypt stored data.

It'd also be madness to go around demanding that every single third party app developer comes up with their own obfuscation scheme for any data they might store about you.

If the platform were to implement some kind of global data munging scheme to make it harder to get into your data, then it'd be at least sensible for users without lock codes of any kind to receive the "extra step" security of having some kind of encryption performed on their data. This wouldn't provide any extra real security though, because the keys would have to be unprotected, and as such any competent attacker would be able to slice straight into their data. If the users do have a lock code of some kind then it makes sense to keep the key in memory whilst the device is unlocked, and expunge it from memory when the device is locked. This will provide real extra security, encrypt users data as it is stored on the device and hopefully make the entire platform more secure.

This scheme could be implemented transparently at the platform level on all data that's stored by applications, however it might be better to make it an opt in thing due to the possible power consumption of doing extra encryption operations (I'm no expert on embedded computing and how stressful doing encryption on this kind of platform is).

As it is, I see no real way of making this data any more secure without having some kind of system that requires encryption keys that can't be used without user input (IE entering a password, or just unlocking the device)

I keep seeing the 'meme' repeated, "unless the whole phone is encrypted, we have to store the password in cleartext for something, somewhere". But this is not true, so can we put this myth to death, please?

Instead of storing the password in the clear, you store a hash function of it. Then the verifier checks that the hash function of the input password matches the stored hash. That way, someone who has only the hash, does not have the password. Without modifying the software to accept the hash instead of the input password, he cannot take advantage of knowing the hash, either.

Now of course, the paragraph above will make no sense if the reader does not also know that computing the original data from the hash is infeasible. But it is in fact very infeasible, even for SHA-1, though I can't recommend the use of that hash function anymore.

Encryption operations do put quite a load on the slow ARM cores that are common in today's smartphones, but not THAT much. The user will not notice the extra time for computing hash functions unless he is trying to run OpenGL animation with software emulated floating point at the same time.

Now there is another myth I would love to see die the death: the myth that Google (or the Open Handset Alliance) should not bother fixing this bug as long as users still use weak passwords. This too is a dangerous myth. Why? Think about it: if a user uses a weak password and suffers a privacy loss, it is his fault. But if a user does all his password management by the book, choosing a strong password and keeping it safe, and -then- suffers the loss, then whose fault is it? It is then the fault of the author of the software.

Let's keep Android's hands clean from such a major fault, let's store only a strong hash of the password, WHEREEVER a password is used. This sounds like Google should provide a security API for password management and hash calculations -- or just use java.security and require entry of another password to access the key store.

The problem I see with hashes is that some services (particularly old pop servers) require plaintext passwords to be sent every time. How is that issue solved?

In the case where the hash of the password is enough to authenticate then it's no better than having the plaintext password stored on disk (person can suck hashes off your phone and provide them in the authentication phase to each service)

In the case where the hash changes using some kind of salting system then you have to store either the password or some function of the password, which once again on it's own will be enough to authenticate against the server.

In other words, whilst hashing means that people don't have the passwords, they have enough material to authenticate to broken services.

How is google going to stop non-google apps from storing passwords in plain
text?

The first post and reason for this ticket IMO was due to email storing passwords in plain text.  All this talk of stoing passwords using a hash does not consider POP3 and SMTP and how authentication is performed.  

As a technically above-average an Android user, I would say I would much rather someone steal a hash of a password they can send to some services than have my actual password.  Not to mention that while I agree with those saying hashing is not true security, plain text is far worse. Any amount of additional technical knowledge required to break the security, or additional hoops/annoyances/time needed, is better than none at all.

This is not the place to argue about the do's and do not's of the issue. If you have interest in seeing this fixed simply STAR the issue and move on this debate is both baseless and illogical. If you feel you have a solution to the problem simply go to http://developer.android.com and subscribe to one of the lists/Google groups OR suggest it as a new enhancement with all the work you have done and let the developers see and comment on your work don't keep adding to the growing list of email's.

thanks.

Answering #52.

That is a good point I overlooked when writing #79: the unencrypted password has to be passed on to the remote server. However, that does not kill the idea of using a hash. It only kills the idea of using a hash to store the email password itself. You can still use a hash to store a key un/locking the store where the password is kept, so that without that other password, an attacker cannot decrypt the store to get the email password. Sure, we  now we are back to the need for another password, but this enables the security conscious user to use a strong password correctly and be protected, while the current scheme fools the user into a false sense of security. This proposal also accomplishes this without requiring the whole phone be encrypted (as other commenters, e.g. in #78 claimed was necessary), thanks to the hash.

Now I have to admit that an attacker who is willing to use a logic analyzer and decompile the code as it tries passwords might still be able to break this protocol, but it is still much more secure than the current scheme. Besides: that attack would work only if the code carelessly puts the address of the private key on the address bus even when the branch fails. Avoid such coding mistakes, and the scheme is secure even if the attacker has the source code and unrestricted hardware access.

Let's not let the perfect be the enemy of the good. This scheme is still a lot better than the current situation, which really is intolerably insecure. Nor does this share the fault of the 'obfuscation' schemes mentioned before, since a hash really does do more than an obfuscator. There is no deobfuscator that can be written to undo a good hash function properly applied. I have never seen, for example, a deobfuscator than can crack a java.net KeyStore.

Come to think of it, doesn't java.net KeyStore already DO all this? If Android needs to avoid the X.509 assumptions KeyStore makes, then at least imitate the interface it offers, which really is quite appropriate here; it has just the security protocol Android needs.

Just an idea - I'm no cryptographic guru nor hardware specialist.

Surely Android controls the memory on the device - so could easily prevent anything reading a small portion of RAM?

Rather than retain the unlock pattern somewhere - store a salted hash. When the user attempts an unlock, salt the code and verify against this. If correct, allow the user access and then hash the unlock code against a *different* salt, this can then be used to retrieve the decryption key from the user's Google account to decrypt the passwords stored on the phone. This decryption key should be stored in the protected portion of RAM. (Decryption key stored in the cloud for a reason; users would need to re-enter all their passwords if they forgot their unlock code and had to gain access to the phone using their Google account password if the key were not stored online.)

I'm not sure why I'm suggesting this because it does have four flaws I can think of:

Before email can be checked, the user will need to unlock the phone after switching it on / rebooting.
There are only a small limited number of unlock patterns (aren't there?), so brute force will break this security with very little effort.
Every user will be required to use the unlock pattern if they require this security. Encryption security would simply be disabled if the unlock pattern is not on and passwords stored in plain text.
Full internet access required - if on a corporate network accessing email locally without access to your Google account via the internet would fail if you rebooted the phone.

But hey - if this suggestion helps someone else come up with a better suggestion then maybe it was worth posting! ;)

Security is critical.  Need to fix. Please elevate priority

please try to fix it , security on mobile devices need to be more powerful

Being in Higher Education, this is a must for my secure environment. Please change the priority on this and get it resolved ASAP. I do not want to have to resort to having hundreds of my users switching from their familiar stock email application or having to spend an additional $20 per use to use a 3rd party app for something that should come stock. Thank you.

Um, wow, thats awful, luckily I have authenticator enabled... or can apps access that too?

Too happy that i use an IOS

How is this ticket even still open? Ridiculous and amateur.

++

WTF MATE

[Comment deleted]

OK, first off, no you can't use a hash function here. With a hash function there's no way to get back the original text. You need that original text to send every time you log into the service, so the passwords need to be stored using some kind of reversible encryption.

That of course means the only secure method is using the user's unlock code as an encryption key, because otherwise an attacker can decrypt the password just as easily as the software itself can. And unlock codes are short and limited in number, so brute-forcing it would probably still be pretty easy.

Storing a hash and sending that instead of the password doesn't help at all either. The hash just becomes an alternate password.

Even if you encrypt with the unlock code, someone can steal the phone, bypass the unlock code with one of the many tools out there (exploiting the phone itself before Android even starts), connect the phone to their own network and trick apps into sending the plain-text passwords to them.

Really the only thing that can be done to keep stored passwords secure is:
1) Store them in the database and don't let apps access any part of it they didn't create. (And maybe encrypt *all* database entries using the unlock code if one is set.)
2) Have a system (like the many apps for this already) that the user can use to remotely wipe the database if they find their phone has been stolen.

Some Python from Py-Bcrypt, it reads well:
http://www.mindrot.org/projects/py-bcrypt/

hashed = bcrypt.hashpw(password, bcrypt.gensalt(10))

# Check that an unencrypted password matches one that has
# previously been hashed
if bcrypt.hashpw(password, hashed) == hashed:
        print "It matches"
else:
        print "It does not match"


It doesn't get any easier than that.

And as far as 'using' passwords for x,y,z service, keyrings could be used.

Alright, and how does this bcrypt snippet help you recover the original password for external services? You mentioned keyrings. Awesome... except those would probably be designed to hook into an unlock code of sorts, and unlock codes tend to be of limited length and complexity.

A letting is needed, and the unlock code is as simple or complex as you (the user) make it.

[Comment deleted]

Type-Enhancement
Priority-Medium
Is it ??? :-O
Make this high priority and this isn't Enhancement !!

Regardless of whether this floods the inboxes of 200+ android deb's at Google, this is utterly appalling and leaves me wondering if I shouldn't have gotten an iPhone... the fact that this is still medium priority - even more so...

The password is also stored in 'plain text' on iPhone as well.

There is no other way, really. bcrypt or any other hashing or encryption technology will NOT help, because they do not let you get the original password back and you need the actual original password to authenticate to the service that has your email. The same is true for all systems.

If you 'tie' it to the unlock code, then you can only check the email when the phone is unlocked, which is clearly quite useless.

why the priority for this is not critical? Don't follow Sony example please

please fix

Please encrypt

Is this the best way to do it?

I don't really use android, but as an embedded developer, I'd like to share my two cents :
You dont have to store the password or a higher order key in plaintext on unprotected memory. There are plenty of cheap hardware encryption options designed specifically to be key stores, and when you go to the extent to putting in GHz class processors on your phones, you can certainly afford a sub $1 chip if it means you protect your users data. You will, of course, need some way to 'unlock' the key, and to do that with a single password or a gesture is trivial as suggested above. You could even go ahead and use biometrics to allow key access.

I'm willing to bet the only people who think storing data in plaintext on any kind of not-designed-to-be-secure memory (which is more or less all memory larger than a few KB, unless you buy if from a store whose normal customer is the army) are pure software developers, who don't see the stack as a whole and restrict themselves to what they think is possibles. A motivated intruder could go as far as extract the passwords from flash frozen memory without much trouble - to do so from non volatile memory is relatively child's play.

Sorry guys but Google is doing the right thing by storing the password in plaintext.

This is a age old problem, how to store passwords for services that use plain text authentication.  I remember this from 1995 regarding a similar discussion about how a ftp client stored passwords in plaintext on the disk.

The sad truth is that there is absolutely no way to add any security to your passwords by encrypting or obfuscating them, anyone who wishes will be able to reverse them back to the original one.

The problem Google will have if they encrypt them is that frequently someone will publish a "advisory" on how the password protection is "broken", and Google won't get anything out of it other than bad press.

Is is better for everyone to just keep the passwords in plaintext, instead of creating a feeling of security that isn't there.

Please fix asap feeling very unsecure.

If it's true, you guys are amateurs!

This has been addressed in Android 3.0

http://source.android.com/tech/encryption/android_crypto_implementation.html

Full disk encryption.

There is quite an easy solution to this issue. This is called a Keychain and that is what Android is missing right now.

Saving the password information on the SIM card might address most of the concerns? It should be inaccessible until the PIN is entered (if the SIM card is secure and the user didn't disable pin request). In addition the SIM card limits the number of attempts allowed to attack the PIN code.

The phonebook / SIM SMS message store should have enough space, even on 8k SIM cards. (And doesn't seem to be used by Android) (Some compression might make sense, to reduce the amount of storage needed)

If some non-GSM / UMTS phones lack a SIM card, this might be problematic though. A database with optional encryption (even for GSM devices) might be useful. This password would then need to be entered when the device is powered on and, optionally, after a user-defined timeout expired. In addition, this can be used to encrypt other stores of private information, such as the on-device phonebook, OAuth tokens, the text message databse, etc. Apps should also be allowed to revoke the authentication (for use by apps like Prey)

(This assumes an attack on a stolen phone, a flash dump or by an application with root access)

For everyone commenting here:

There is currently nothing anybody can do.  Hashs won't work.  Keychains won't work.  Nothing -- especially if you want your email program to check for new mails automatically.

The password itself is protected by root access privileges by default, so only the app that stored it will have access to it.  If the phone itself is rooted (and not by the original user), you have a much bigger problem then just passwords.

SIM memory or Phone-Lock-Screen password-behind-password won't help either, since the user needs to input their PIN, which is no longer than 6 digits (for SIM) if I recall correctly.  That's easily breakable, especially with a SIM dumper.  Lock screen password entries aren't designed to be formidable security barriers -- it's just to make it inconvenient for regular people.

The bottom line is, older services like IMAP and POP3 *REQUIRE* plaintext password.  This means that all the information MUST be available at the time of check.  Not root? All is fine due to sandboxing / file permissions.  Rooted?  Worst case, memory or network sniff, both of which are easy to do.

If you're really concerned about plaintext password security, you should not be using IMAP or POP3, end of story.  Exchange or other token-based services would be what you're looking for, although even then, that's arguable since the token needs to be read by the app to send over (so it's basically a longer "plaintext" password)

Re: most of the comments - jeez, sofa kings.

So anyway, here's an email I sent to the Bay Area Hacker's Association mlist, which I run (baha.bitrot.info) - you guys ARE on that, right? :-)

Here's your free battle plan for protecting data on android devices.

With most crypto devices, you can store the keys in memory, and not
worry about them too much since memory isn't directly accessible.
If you have ports with DMA, you fail; do not pass go, do not collect $200.

This is modulo cold boot attacks - cold boot can be defeated with some
really simple tamper-resistance - you open the case, it releases a
pressure sensor, and a cap wipes the memory.  If this is a PITA, then
put your keys in a protected memory space, and have a secure key API.
If you have DMA, use hardware to prevent access to this space, and you gotta
keep the keys there.  See also TPM.  Pay someone to make a good reference
hardware design and release it as open-source hardware, because the mfrs are
gonna get it wrong, but they are probably good enough for copypasta.

If you really want to deal with hardware key extraction, tamper-resistance
for key storage is well-studied (and Tarnovsky can school all of us on it):

late 90s: Dallas semiconductor crypto iButton (out of production, was ~$40 ea)
early 90s: smart cards & satellite TV (see below)
HSMs (hardware security modules) - see Attalla (sp?), etc.
early 90s: IBM's Micro Abyss secure co-processor
even older: permissive action links on strategic nuclear weapons:
https://encrypted.google.com/search?channel=fs&q=permissive+action+links&ie=utf-8&oe=utf-8
Every USENIX proceeding over one year old is free, they have a con on smart cards:
https://encrypted.google.com/search?channel=fs&q=usenix+smart+card&ie=utf-8&oe=utf-8
Search Ross Anderons' page for tamper resistance too:
http://www.cl.cam.ac.uk/~rja14/
So if you don't know Tarnovsky, he's kind of like a hardware honey badger:
http://www.wired.com/politics/security/news/2008/05/tarnovsky?currentPage=all
And his company is:
http://www.flylogic.net/
They're blogalicious, too.

So now all you have to do is worry about data at rest.  Then you
require FDE and password entry on bootup - and of course if you can
access the disk over USB with adb and no serial port debugging enabled,
that's a problem - but I couldn't tell if that was the case.  Then
Michigan state police won't be jacking our cellphone data at traffic
stops any more.

You then eliminate most needs to reboot so this isn't a major
usability fail.

Optionally, derive it from a biometric, like a thumb scanner, with
some kind of long password as backup.  Customers will have an toygasm
over this, because everyone any phone which has a scanner is obviously
from the future. I don't really know if it has enough repeatable entropy
for a real key - hopefully so.  IIRC correctly, there's some lit on
securely deriving crypto keys from biometrics, so don't store the
extracted features on disk, m'kay?  If you think key rotation is a PITA,
you haven't tried replacing your fingerprints.  Just decrypt and
check a magic number, like PGP and TrueCrypt.  For the extra
cryptonerd academic correctness, you can use HMAC instead of
decrypting and looking for a magic number - see my comments here:

http://rdist.root.org/2011/01/17/stuxnet-is-embarrassing-not-amazing/

Here's some of my Android security linkage:
http://www.subspacefield.org/security/android_security/
Represents some links I collected over about two weeks.

And a book I wrote:
http://www.subspacefield.org/security/security_concepts.html

If you can't really secure everyone, at least let us secure it ourselves, and maybe let a corporate server push down a policy.  Not everyone really cares, but at least give the people who do the tools to do it.

Oh and... why does my corporate exchange server force me to use a PIN instead of a gesture?  I'm kind of baffled by that - does a PIN necessarily have more guessing entropy than a gesture?  And if they care about that, maybe they want FDE too.

For extra credit, use the secure key storage to do crypto handshakes and stuff - your cell becomes a secure key storage device and login token.  Not sure how usable - maybe NFC, possibly a QR code, or via USB - see ubikey on keyboard emulation - entering passwords is so 20th century, and remember, you're from the future.

Okay everyone, get your ass to the mobile hacking class tomorrow 630pm (Wed 27 Jul 2011 1830) at the Hacker Dojo - courtesy of DC650.org - it's free.  You guys ARE attending DC650, right? :-)  It's in Mountain View, so schedule a bus.

http://events.hackerdojo.com/event/1001006-dc650-mobile-hacking

And next time I have an on-site interview, tell me who to remind of this email :-)

I have seen many good comments here and I particularly agree with ones advocating the use of some h/w based protections of key materials. I am not quite sure that I agree that the FDE solution alone provides adequate security. This is because of online attacks where other malicious applications or possible remote agents that have penetrated the device and simply access the relevant SQLite data store while the FDE happily decrypts the relevant blocks as it is operating at a very low level with no intelligence about users and applications.  

In order to provide some reasonable solutions to the existing base of users and offer more fine grained protection, especially against online oriented attacks, I would recommend a software update that provides a key-chain/secure storage service for files and individual fields of SQLite backed data stores. This service could be offered as an API to any Android app including the mail application. In future this API could make automatic use of any h/w based secure storage for key materials and credentials. Most of the fundamental crypto methods and needed software libraries exist to implement a service of this nature.

The key-chain service can keep a fully encrypted data store of passwords, keys, files, and other tokens that any applications require. Each entry in the data store can be associated to a user and application identifier. Whenever a user or application needs to access a resource local/remote over the network (e.g. email message check) that requires a credential this can trigger an event that the key-chain service is listening for. The event would have the necessary user and application identifiers. Upon receiving the event the key-chain service can query the user for a master password that is used to dynamically generate a key (there are many secure ways to do this, but PBKDFv2 in PKCS#5 [ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2_1.pdf] is a good point of inspiration) for decrypting individual entries in the service data store (it is best decrypt only the necessary entries as to narrow the window of attack). In this example we could use AES-256-GCM (which offers an authenticated mode of encryption that has some good properties for data-at-rest) for the protection of data store entires. Each time the service decrypts an entry and delivers it to the application for use it should zeroize the key and keep a reference to the credential it has provided to the application. Once the application has declared (through an API call or de-reference) its final use of the credential the service can ensure its zeroization as well. Upon user configuration the key-chain service can cache the master password in memory for certain periods of time (e.g. once per day to enable more convenient automated access) and still alert/query users whenever it is being used. Whenever possible the key-chain service should make use of more protected areas of memory for dealing with master key and key-chain service data store services. Also some further access controls can be put into place to ensure the requesting application has permission to access the credentials being requested. When the permissions are not available the user can be presented a request to grant them if they so choose with an adequate warning.

Of course non of the above are a perfect protection. But it does address the need for storing credentials for automated use securely and using a method that is beyond mere obfuscation while offering some mitigations against trivial online attacks as well. There are also other more advanced techniques that can be discussed for providing more enhanced protection of the key-chain service and its data stores which I can be directly contacted for if there is interest in the discussed approach.

Best Regards
Daniel.

This defect is a symptom of 3748. If you can encrypt the storage, you would end up encrypting the passwords stored on it. Anyone interested in securing your phone's data should also star http://code.google.com/p/android/issues/detail?can=2&q=3748&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&id=3748

We need to get the Android team to start focusing on data security.

just adding my two cents

those crying this file could be easily taken out on a rooted device.

please check that getprop ro.secure would be yielding 0 or /system amd /data has 777 on your phone

if this is the case its your or ROM makers ignorance and not fault of google.


I understand that encryption should be allowed however they have already provided protection of user level access if you keep running your adb shell in root mode its equvalent of having a linux machine always running in root and doing rm -rf / and crying that distribution is bad or linus torvalds have not taken enough care.

as simple there is no protection against user stupidity.

also adding more to what is already said how can you be sure that a whole disk encryption will protect you.
whole disk encryption is never for running machine its for machines which are shutdown.

also we need to understand that any encryption used need to be decrypt-able coz these passwords will be used by apps only making encryption not the best option. otherwise this requires a all out change in api or application level changes in making then compliant to a shadow kind of password architecture.

Agree that Security is unacceptably weak with the growth of android use, and with  too many novices rooting.  This defect is a symptom of 3748. If you can encrypt the storage, you would end up encrypting the passwords stored on it. Anyone interested in securing your phone's data should also star http://code.google.com/p/android/issues/detail?can=2&q=3748&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&id=3748

I urge the Android team to start focusing on data security.

Security is a defense-in-depth proposition:  start with a fully-encrypted device, requiring PIN at startup.  Specific sensitive information such as passwords should, in fact, be additional protected - both from malicious as well as inadvertent disclosure.  Agreed that if they are "automagically" leveraged, they are not truly secure - but sometimes, even a little obfuscation can add some value.

Appreciate all the security features Google can bake into the core AOSP - so that we become less reliant on vendor / hardware specific ROMs coupled with 3rd party management apps to bridge the gap.

Thanks!

Starting with Honeycomb, device encryption is now supported and is the most appropriate solution for this issue.  Closing this now.

WTF? Where is the update for 2.x? There should be a securityfix for it... I thought google developer has to develop secure and high quality code?

Full-disk encryption really isn't a good solution to the problem.
Sure, it will protect the tech-savvy crowd who aren't afraid of the "this could trash your disk if it's interrupted" message.

"We support disk encryption" is not a justification for storing passwords in the most naive way possible.

Yeah, too bad no currently selling phone will receive Gingerbread or ICS except the Nexus S

if android is to be taken seriously as a enterprise device (aka good technologies good.com), then this needs to be fixed. Beyond the rooting issue, there are some serious data-at-rest issues. As this becomes more publicized, device manufacturers should demand that google fixes this. It will hurt their bottom line.

This should be fixed in CM7.2.0. Too little phones do have Android 4 support yet.

can somebody please email me where the passwords are stored because I forgot the password for one of my emails i signed into on my phone

This issue, present in ics is also there in JB (Nexus 7)but the file has been moved to /data/system/users/0/accounts.db

This should have been fixed in Jelly Bean.  Why can't the KeyChain API used to fix this issue.  Storing ActiveSync creds in cleartext is a major error and needs to be fixed.

Device encryption incurs huge overhead and is overkill for this issue. Top-notch, impenetrable security isn't necessary, but some form of encryption is necessary. The fact that Google has proposed an all-or-nothing mentality to encryption is pretty sad.

Then again, Android's internal app suite has been neglected by Google in favor of the more lucrative, closed-source suite. I wouldn't expect a fix for this issue... ever, because Google has no incentive. Oh well :-(

can somebody please email me where the passwords are stored because I forgot the password for one of my emails i signed into on my phone
 i m using android 4.1.1

This issue bothered me as well, until I realized that, any form of obscuring password while keeping the possibility to use it by the phone software, is just a false and misleading "security". See the arguments above.

What still puzzles me is that nobody considers a possibility to NOT store the password at all. I.e. a mail client that requires you to enter the password EVERY time you want to read your messages. In this way, the problem would be solved once and forever. Of course, some may find this inconvenient. For me, this is a perfect solution. I do not want my device/messages to be synchronized in the background. As a matter of fact, internet connection in my phone is off most of the time. I only switch it on when I need it.

The real problem is a different one. Even if an email client does not store password at all, but keeps all mail in a local folder for off line use, the mail can be accessed by whoever got your phone. He/she does not need an email client for this. The solution of this problem would be either (i)to not store your mail locally; or (ii)to encrypt all local mail and require a user to enter the decription password every time you want to access it.

Addition: of course, a possibility to NOT store your password to your google account should be not an email client option but a system option. The option should be available when you first register your device with your google account.

Why is this being marked as "Released"? Device encryption is not feasable to any sane user until #29468 is fixed and thus will not be used. As it stands, email passwords are still stored in clear text. Also, if other email apps are able to encrypt the password, why can't the stock Android app do this?

Хуйня какая-то!!!

Хуйня какая-то!!!

хуета не понятная

Полностью согласен ,блядь.

Я упоролся!

по русски блядь! Никуя не понятно!