81–90 of 93 posts
Cleartext passwords are perfectly fine in this case. I speak as a software engineer specialized in security. This bug report was filed by someone who doesn't understand that obfuscating a password is different from encrypting it. No matter how you store it, the application must be able to extract a cleartext password from whatever storage options are available on the Android device. For a longer explanation: http://d…
Earlier quoted context omitted.
The person who wants the software fixed should fix it. This isn't a cop-out, it's simple economics. If you want a pony, go buy a pony. Otherwise, STFU.
If I buy a pony I expect to be a pony, not to be a donkey. Its definitely a total cop out because no one is taking responsibility on the matter, bugs are being ignored, and Google has made a history so far of passing blame and not addressing issues with Android. Lastly thats a moronic statement "The person who wants the software fixed should fix it". Android tends to attract lower income people who tend not to be IT…
Earlier quoted context omitted.
Ah, but how does this Superuser.apk achieve root privileges? By calling the setuid root `su` program, you say. And how does this setuid root program actually gain root privileges? Why, the OS is able to execute arbitrary code with arbitrary privileges, and it makes an exception for `su`. Wait... so Android could run processes with root privileges without asking you? Whoa! Now consider that adbd on a rooted device run…
Jumping to conclusions, are we? Superuser.apk does not achieve root privileges and su does not blindly run your program with root privileges. su asks superuser.apk, if your program is allowed to run as root and only when superuser.apk agrees (and displays toast), then your program is run. Also, the arbitrary privileges are reserved for setuid programs, which is not easy to achieve. Basically, su and Superuser.apk are…
Earlier quoted context omitted.
> if you've rooted your phone yourself, any OS security is null and void Are you sure? If I am not mistaken, even with a rooted phone, a program has to ask the user for root permission via the Superuser.apk app.
But, if you're rooted, you likely have a custom recovery and bootloader which will accept commends freely, so it is pretty trivial to pull arbitrary stuff from the phone. You should, however, be safe from other routes, so long as you disable adb (which also freely accepts commands as root in most ROMS), Filesytem encryption would close all these attacks, but I'm not aware of any particular implementations (I'm pretty…
Plus, "detecting" a rooted device is rather easy depending on how extreme your changes have gone. Seeing the AOSP lockscreen or a status bar that doesn't match the OEMs skin is a dead giveaway that the phone's been rooted. With that in mind, an attacker could simply pop open the battery cover, remove your SD card, replace it with a blank (so you don't notice the 'missing SD card' warning), and put everything back together in under a minute. By the time you notice something's up, the attacker will be long gone with your card full of plaintext backups.
PS: even if you don't keep backups on your device, merely having Clockwork installed makes the act of an attacker getting one (while bypassing your passcode) trivial. The attacker simply needs to power off your device (yank the battery), insert his SD card, reboot your device into Clockwork (on HTC phones, this is vol-down + Power), run a backup, remove his SD card and replace yours, and reboot again. This can be done in the space of 5 minutes, and you will never know unless you pay very close attention to your phone's uptime. And of course, how do you know your phone wasn't just having a bad day and rebooted of it's own free will?
Full device encryption is part of the Android platform as of 3.0; besides that some OEMs (I believe Motorola is one of them) have taken the liberty to implement it themselves. As well, Whisper[1] has produced a solution for the Nexus phones.
Earlier quoted context omitted.
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....
Earlier quoted context omitted.
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 encr…
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…
Earlier quoted context omitted.
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…
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 acce…
Earlier quoted context omitted.
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 encr…
Cleartext passwords are perfectly fine in this case. I speak as a software engineer specialized in security. This bug report was filed by someone who doesn't understand that obfuscating a password is different from encrypting it. No matter how you store it, the application must be able to extract a cleartext password from whatever storage options are available on the Android device. For a longer explanation: http://d…
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 ow…
Earlier quoted context omitted.
Couldn't you have something like: key = hash(hardware serial number, user password) And then store the key only in memory every time the user unlocks the phone and wipe it from memory when they lock their phone?
If you do that, I'd imagine that the phone would not be able to pull updates from those services while the phone is locked.