Actually, they are not perfectly fine in this case. They should take the Apple approach and use PBKDF2 to derive a key from the PIN/passphrase, if one is set, then use that to encrypt the database. Anything less is simply not OK.
Edit: You should also use some sort of hardware ID in addition to the PIN/passphrase, otherwise it's trivial to distribute a database of, say, all the <=7-digit PINs.
Unfortunately even with a unique salt, 7-digit PINs are not strong enough if, from a theoretical viewpoint, we assume they can be bruteforced at a few thousand per second.
If you use a TPM to store your device encryption key, a PIN combination should be fine. Of course, by definition that requires hardware support.
I work in Android security in particular for a manufacturer. We came across the unencrypted email pass ourselves, but decided it was fine for two reasons:
1) If you don't get rooted, there should be no way to pull from /data/data/* in the first place.
2) With filesystem encryption turned on, you essentially get the benefit of encrypting that pass along with everything else.
A TPM is obviously the best solution here, on all counts, but it's not possible to put one into every phone that's already been sold, so clearly we need a software mechanism that at least helps.
As it stands, if an attacker gains root on your device (which could be locally, via a malicious app running a local root, or via a malicious page exploiting a browser bug and then escalating with a local root), they have the keys to the castle. This is true whether you have filesystem encryption on or not.
Leaving these in plaintext is equivalent to storing plaintext passwords in /etc/shadow; yes, only root can access it, but getting root is by no means impossible. If an attacker does get access to it, it shouldn't be an immediate game-over for your passwords.
To amplify that a bit, in terms of accessing the file system, it's a pretty common security assumption that physical access and root access are equivalent. Since my phone is the system where I trust physical access the least, by extension it's the one where I'd most want a security model that doesn't assume that one can't read the file system the most.
For my purposes, the chances of an attacker having physical access to my systems in a rack in a major data center approaches 0%, whereas the chances of an an unauthorized party at some point having access to my phone approaches 100%.
There is certainly some benefit to encrypting removable flash. However, for non-removable flash, the speed at which normal attackers could pull items off of internal flash without the device running should be relatively long. I'm not totally sure what the limitations are with adb but if it's using Honeycomb style encryption, if you have permission to read the file it's going to be automatically decrypted.
Well, a TPM would be fine assuming a hard limit on rate of attempts or total attempts. Apple, as far as I understand it, uses a TPM but had an interface that didn't properly limit attempts, hence the elcom brute force attack.
Android supports text passwords as well. Also, in a sane security model, it'd be possible to separate having a long password for elevated privileges (i.e. things that could further open the door to compromises like booting and installing apps) from the one simply to unlock the screen.
Your average consumer probably wouldn't avail themselves to such measures, but it'd let the paranoid and companies with security policies at least have semi-reasonable security as an option.
Do you guys know that there's a mechanism in SIM cards that blocks the access if you enter the SIM PIN wrong three times in a row? Carriers store unique long PUK code for each SIM card, which is used to unblock the SIM. So the SIM card and it's contents can't be brute-forced. Wouldn't it be appropriate protection to store the unique salt or key on the SIM card?
The email client checks for new mail in the background, though. How is it supposed to do that if the user is currently "logged out" (assuming you mean the pin for unlocking the screen)?
Edit: You should also use some sort of hardware ID in addition to the PIN/passphrase, otherwise it's trivial to distribute a database of, say, all the <=7-digit PINs.