11–20 of 38 posts
This is a really bad article. I would call it nothing less than fear-mongering. Let's say they decided to encrypt the file. They would have to store that key in plain-text somewhere. Of course, they could encrypt that, but then that key would have to be stored somewhere. No matter how they decided to store the password, if somebody has root access to the device, they can find a way to read it. If they can't find a wa…
This is a really bad article. I would call it nothing less than fear-mongering. Let's say they decided to encrypt the file. They would have to store that key in plain-text somewhere. Of course, they could encrypt that, but then that key would have to be stored somewhere. No matter how they decided to store the password, if somebody has root access to the device, they can find a way to read it. If they can't find a wa…
This is a really bad article. I would call it nothing less than fear-mongering. Let's say they decided to encrypt the file. They would have to store that key in plain-text somewhere. Of course, they could encrypt that, but then that key would have to be stored somewhere. No matter how they decided to store the password, if somebody has root access to the device, they can find a way to read it. If they can't find a wa…
Is this really true? Could not the device manufacturer store embed the key in silicon somehow, perhaps in EEPROM or similar?
There is no excuse for openly storing passwords like this. Why does Samsung think this is acceptable?
Why is storing them encrypted locally any better? Someone with root has access to the decryption keys anyway.
Fortunately authenticating with Google services requires neither.
This is a really bad article. I would call it nothing less than fear-mongering. Let's say they decided to encrypt the file. They would have to store that key in plain-text somewhere. Of course, they could encrypt that, but then that key would have to be stored somewhere. No matter how they decided to store the password, if somebody has root access to the device, they can find a way to read it. If they can't find a wa…
> They would have to store that key in plain-text somewhere. Is this really true? Could not the device manufacturer store embed the key in silicon somehow, perhaps in EEPROM or similar?
This is developer sloppiness. Google provides plenty of methods to authenticate users without persisting user credentials to disk. There's no reason an application would need to store your Google login to disk, unencrypted or otherwise.
I guess that's a good reason to implement credentials storage, don't you?
P.S. AccountManager stores your passwords and tokens unencrypted in a database as well.
This is a really bad article. I would call it nothing less than fear-mongering. Let's say they decided to encrypt the file. They would have to store that key in plain-text somewhere. Of course, they could encrypt that, but then that key would have to be stored somewhere. No matter how they decided to store the password, if somebody has root access to the device, they can find a way to read it. If they can't find a wa…
This is a really bad article. I would call it nothing less than fear-mongering. Let's say they decided to encrypt the file. They would have to store that key in plain-text somewhere. Of course, they could encrypt that, but then that key would have to be stored somewhere. No matter how they decided to store the password, if somebody has root access to the device, they can find a way to read it. If they can't find a wa…
PBKDF2, it works for deriving keys to decrypt other things.
Earlier quoted context omitted.
> They would have to store that key in plain-text somewhere. Is this really true? Could not the device manufacturer store embed the key in silicon somehow, perhaps in EEPROM or similar?
Honestly, that never happens.
We had built some devices that did encrypt they local stores and used keys burned into separate silicon (really, keys derived from multistep mutual authentication with that silicon), but the attack model was that attacker would not possess both parts of device at once (as the key-containing part was able to be located in different part of the building from rest of the device, was reasonably tamper-proof and detected movement).
This is plain wrong: Any unrooted Android is insecure, because the exploit to root it is not fixed. The only way to make an Android secure is to root it, to install a newer version, and to upgrade it regular.
The right way to store passwords would be: Ask for a master password at boot, to start an app, that is managing the password crypt. So far I know, nobody does this. So the 2nd best way is, to install the google play into emulator, and use something like titanium to move applications between emulator and phone.