Hacker News Reader

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.

I guess we agree (see my edit).

By "hardware ID", you mean a unique salt.

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.

Does Apple IOS really use PBKDF2? The Fraunhofer paper does not mention it. http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords....

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.

If you have root you have access to the plaintext of the password in memory. It doesn't matter how it may or may not be obfuscated on disk.

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.

http://www.infoworld.com/%5Bprimary-term-alias-prefix%5D/%5B... According to this (mind you, this is my sole source), iOS 3+ use PBKDF2, with iOS 4 using 10k rounds.

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.

If you are paranoid you don't store the password in the first place.

Or use android for that matter

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)?

Not when there is already a market harvesting data from stolen phones. I think you probably haven't considered the impact for the standard user around using email as a authentication authority point.

Its like a skeleton key to your personal data, and with that you can get access to financial services very quickly. Hence why a black market exists, and I garantanee there is already rooting kits out there designed to own that data in seconds.

BTW obfuscation is not a security measure, and IMO its shameful and irresponsible to perpetuate that myth.

If someone has root on your phone, they have your passwords. It doesn't matter how they're stored on the disk. Protecting a key from someone who has full access to storage and memory is very hard.

Cleartext passwords are perfectly fine in this case. I speak as a software engineer specialized in security.

These passwords should of course be stored in a Keychain-like component that the OS provides.

Are you sure you are specialized in security?

The OS can't provide a key ring because the user dosen't use a password to login. Or if they do have an unlock code they are short and numeric, making brute forcing them trivial. So yes, in this case plain text is acceptable because there is no truly better alternative.

On one hand, both gesture unlock codes and longer alphanumeric codes, both of which android supports, would probably make good candidates to secure the key ring with. On the other hand, the email application, for example, still needs to receive email even when the screen is off, which makes anything entered on screen un-lock a bad candidate for key-ring solutions. Boot is better, but how often do you turn your phone off while not using it?

http://whispersys.com/whispercore.html implements full-disk encryption for android.

unfortunately it requires unlocking the boot loader and installing that company's android rom, so it's not an option for many users.

The difference between Pidgin and Android is, Google provides the whole stack from the OS to the Mail App and also dictates hardware requirements. Clearly the can come up with a better way to store the, for many people, most important password they have.

A passphrase won't really help, because passphrases user's typically use on a secure device will be too simple.

What's wrong with a keyring? Or something like KDE's wallet.

Android 3.x supports full disk encryption.