A Android user complain that , All passwords are stored in plain text on Disk via a message on
discussion board of Android.
Android phones store passwords for email and some other services in plain text which as you can expect is a nightmare for many users.
“The password for email accounts is stored into the SQLite DB which in turn stores it on the phone’s file system in plain text. Encrypting or at least transforming the password would be desirable.”For those people who think think again as if you ever lose your Android phone someone can easily root it and pull the data off it. This is a big security nightmare for many users. this security risk is only for rooted phones well
Android Support "Andy Stadler" Reply that :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.
A Android user complain that , All passwords are stored in plain text on Disk via a message on discussion board of Android.
A Android user complain that , All passwords are stored in plain text on Disk via a message on discussion board of Android.
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 Stadlerstadler@android.comGoogle Solution Have been foundIf you want to enable encryption on your device based on Android 3.0 aka HoneycombFor first release, we only support encrypt in place, which requires the framework to be shutdown, /data unmounted, and then every sector of the device encrypted, after which the device reboots to go through the process described above. Here are the details:
1.From the UI, the user selects to encrypt the device. The UI ensures that there is a full charge on the battery, and the AC adapter is plugged in. It does this to make sure there is enough power to finish the encryption process, because if the device runs out of power and shuts down before it has finished encrypting, file data is left in a partially encrypted state, and the device must be factory reset (and all data lost).
Once the user presses the final button to encrypt the device, the UI calls vold with the command "cryptfs enablecrypto inplace " where passwd is the user's lock screen password.
2.vold does some error checking, and returns -1 if it can't encrypt, and prints a reason in the log. If it thinks it can, it sets the property vold.decrypt to "trigger_shutdown_framework". This causes init.rc to stop services in the classes late_start and main. vold then unmounts /mnt/sdcard and then /data.
3.If doing an inplace encryption, vold then mounts a tmpfs /data (using the tmpfs options from ro.crypto.tmpfs_options) and sets the property vold.encrypt_progress to "0". It then preps the tmpfs /data filesystem as mentioned in step 3 for booting an encrypted system, and then sets the property vold.decrypt to "trigger_restart_min_framework". This causes init.rc to start the main class of services. When the framework sees that vold.encrypt_progress is set to "0", it will bring up the progress bar UI, which queries that property every 5 seconds and updates a progress bar.
4.vold then sets up the crypto mapping, which creates a virtual crypto block device that maps onto the real block device, but encrypts each sector as it is written, and decrypts each sector as it is read. vold then creates and writes out the crypto footer.
The crypto footer contains details on the type of encryption, and an encrypted copy of the master key to decrypt the filesystem. The master key is a 128 bit number created by reading from /dev/urandom. It is encrypted with a hash of the user password created with the PBKDF2 function from the SSL library. The footer also contains a random salt (also read from /dev/urandom) used to add entropy to the hash from PBKDF2, and prevent rainbow table attacks on the password. Also, the flag CRYPT_ENCRYPTION_IN_PROGRESS is set in the crypto footer to detect failure to complete the encryption process. See the file cryptfs.h for details on the crypto footer layout. The crypto footer is kept in the last 16 Kbytes of the partition, and the /data filesystem cannot extend into that part of the partition.
5.If told was to enable encryption with wipe, vold invokes the command "make_ext4fs" on the crypto block device, taking care to not include the last 16 Kbytes of the partition in the filesystem.
If the command was to enable inplace, vold starts a loop to read each sector of the real block device, and then write it to the crypto block device. This takes about an hour on a 30 Gbyte partition on the Motorola Xoom. This will vary on other hardware. The loop updates the property vold.encrypt_progress every time it encrypts another 1 percent of the partition. The UI checks this property every 5 seconds and updates the progress bar when it changes.
6.When either encryption method has finished successfully, vold clears the flag ENCRYPTION_IN_PROGRESS in the footer, and reboots the system. If the reboot fails for some reason, vold sets the property vold.encrypt_progress to "error_reboot_failed" and the UI should display a message asking the user to press a button to reboot. This is not expected to ever occur.
7.If vold detects an error during the encryption process, and if no data has been destroyed yet and the framework is up, vold sets the property vold.encrypt_progress to "error_not_encrypted" and the UI should give the user the option to reboot, telling them that the encryption process never started. If the error occurs after the framework has been torn down, but before the progress bar UI is up, vold will just reboot the system. If the reboot fails, it sets vold.encrypt_progress to "error_shutting_down" and returns -1, but there will not be anyone to catch the error. This is not expected to happen.
If vold detects an error during the encryption process, it sets vold.encrypt_progress to "error_partially_encrypted" and returns -1. The UI should then display a message saying the encryption failed, and provide a button for the user to factory reset the device.
Full Details on
Android Developers 
