5 ms·

Samsung Galaxy S3 stores passwords in plain text

64 points by jgnatch 14y ago

barista 14y ago
This thread has more details: http://forum.xda-developers.com/showthread.php?t=1983672 http://forum.xda-developers.com/showthread.php?t=1983672
jayfuerstenberg 14y ago
There is no excuse for openly storing passwords like this. Why does Samsung think this is acceptable?
- yuliyp 14y ago
  Why is storing them encrypted locally any better? Someone with root has access to the decryption keys anyway.
  - mtgx 14y ago
    Really? So device encryption is pointless then? Same for a jailbroken iPhone? That seems hard to believe.
    - cowsaysoink 14y ago
      If you don't have something like a lock code it is pointless because then you have nothing to lock the encryption with. The iphone works with its lock code.
    - archivator 14y ago
      This is not what's under debate here. Without device encryption, encryption of the passwords is useless, given root access, since the key is somewhere on the device as well. If anything, the only crime here is not using access tokens but storing the whole password. With device encryption, the situation changes slightly. Unlike iDevices, most (all?) Android phones don't come with a hardware encryption chip, so, given a vulnerable bootloader, full-device encryption doesn't do much in the way of security. Under a secure bootloader, device encryption should be secure as well.
      - chmod775 14y ago
        I don't see how a hardware encryption chip could keep me from installing a key logger via an insecure boot loader. What exactly does that chip even do?
  - aristidb 14y ago
    It isn't. Storing passwords on a mobile device, unencrypted or encrypted, is just wrong. Fortunately authenticating with Google services requires neither.
    - bigiain 14y ago
      The problem is, I want my phone to be able to authenticate with way more than just Google services. And I want it to be able to do that in a way which doesn't require me to remember several dozen secure-against-2012-vintage-password-cracking-techniques. I _know_ that sometime in the next year or two we'll see another password leak like, say, LinkedIn's recent one - so I know I need to use 12+ "upper, lower, number, and 'special'" character non-dictionary passwords to ensure I'm not trivially exposed by rainbow tables or gpu crackers. A quick count on my phone just now, there's at least 33 different services my phone "remembers" it's login for. Some of them use OAuth-style authentication (Twitter and Flickr, for example), and some (Google, Facebook, and Amazon) are 3 factor auth protected (but, against a rooted phone that wouldn't help much, since I'm using the Google Authenticator app to generate the auth tokens, if my phone were under someone elses control they could watch me using and unlocking the authenticator app...) But there are still dozens of services - email accounts, websites, web service backed apps - that require the phone to have access to the cleartext password, either from me remembering it and typing it in, or from it's own storage mechanisms - secure or not. My phone would be _remarkably_ less useful to me if it didn't store passwords, or only worked with services that didn't require password storage.
    - anothermachine 14y ago
      Yeah, Google would never ship software where "Password is stored on disk in plain text" https://code.google.com/p/android/issues/detail?id=10809#c48 https://code.google.com/p/android/issues/detail?id=10809#c48
  - jayfuerstenberg 14y ago
    The decryption keys aren't just sitting out in the open so any amount of encryption is better than none. This is like asking why would we encrypt data on a server since the decryption keys are accessible. Of course they are, they're needed to decrypt the data. But at least it takes more time to find the keys and that "can" be a deterrent much the way "The Club" is a visual deterrent that can still keep a car from being stolen by demanding too much time to break it.
    - charlesju 14y ago
      When you properly encrypt server passwords, they are not supposed to be decrypt-able. Whereas, this is supposed to be a two-way encryption as you need to access the raw data. Ergo, any form of encryption you can do can be easily undone and thus rendering your efforts moot. http://en.wikipedia.org/wiki/Salt_(cryptography) http://en.wikipedia.org/wiki/Salt_(cryptography)
      - jayfuerstenberg 14y ago
        I understand one way hashing but what about DB passwords for instance? You need access to plaintext passwords. This is getting long but the point is plaintext = he worst thing you can do. Even ROT13 is a little better.
        jrockway 14y ago
        Even ROT13 is a little better. No it's not.
SoftwareMaven 14y ago
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 way, the phone won't either, so it won't be able to log you in. The only answer is to not let your device store your password. Choose security or convenience, but don't expect both. (This is no different than Pidgin storing your passwords in plaintext[1] with the exact same reasons and consequences.) 1. https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords
- hetman 14y ago
  Yes but there are other ways to mitigate the risks somewhat. Temporary revokable tokens would at least mean an attacker doesn't gain a permanent foothold, and never discovers the password.
- mentat 14y ago
  PBKDF2, it works for deriving keys to decrypt other things.
  - dfox 14y ago
    But still you need to have whatever you use as input into KDF accessible. Encrypting passwords that you still need to be able to send somewhere without additional user interaction simply does not have any security benefit. Full-device encryption does work, building separate encrypted credential store is mostly useless security by obscurity.
    - mentat 14y ago
      You can have an encrypted keystore which is opened by entering a password and using that derived key to decrypt the keystore. Firefox uses this with their "master password". You can cache the decrypted key according to some policy which doesn't necessarily result in it getting written to disk. Also, down votes? Really?
pygorex 14y ago
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.
- archivator 14y ago
  As someone on Reddit pointed out, the minimal API version of the app is 4, which corresponds to Android 1.6, which, incidentally, does not have the AccountManager infrastructure. 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.
kephra 14y ago
> While rooting a Samsung Galaxy S3 only takes about five minutes, the software tools required are uncommon enough that as long as your phone isn’t already rooted you likely don’t have anything to worry about. 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.
zobzu 14y ago
"When you have a rooted Android phone, it’s widely understood that all bets are off as far as vulnerabilities are concerned." FUD
unitesting24 14y ago
Maybe they should be added to http://plaintextoffenders.com http://plaintextoffenders.com
buster 14y ago
Wow.. what a bad title.. As far as i understand it's one application they found called S-Memo which stores passwords as plaintext. The title makes it sound as if all application passwords are stored plaintext somehow.. Wow... I guess i'll just avoid geek.com.

64 points by jgnatch 14y ago

This thread has more details: http://forum.xda-developers.com/showthread.php?t=1983672 http://forum.xda-developers.com/showthread.php?t=1983672

jayfuerstenberg 14y ago

There is no excuse for openly storing passwords like this. Why does Samsung think this is acceptable?

yuliyp 14y ago
Why is storing them encrypted locally any better? Someone with root has access to the decryption keys anyway.
- mtgx 14y ago
  Really? So device encryption is pointless then? Same for a jailbroken iPhone? That seems hard to believe.
  - cowsaysoink 14y ago
    If you don't have something like a lock code it is pointless because then you have nothing to lock the encryption with. The iphone works with its lock code.
  - archivator 14y ago
    This is not what's under debate here. Without device encryption, encryption of the passwords is useless, given root access, since the key is somewhere on the device as well. If anything, the only crime here is not using access tokens but storing the whole password. With device encryption, the situation changes slightly. Unlike iDevices, most (all?) Android phones don't come with a hardware encryption chip, so, given a vulnerable bootloader, full-device encryption doesn't do much in the way of security. Under a secure bootloader, device encryption should be secure as well.
    - chmod775 14y ago
      I don't see how a hardware encryption chip could keep me from installing a key logger via an insecure boot loader. What exactly does that chip even do?
- aristidb 14y ago
  It isn't. Storing passwords on a mobile device, unencrypted or encrypted, is just wrong. Fortunately authenticating with Google services requires neither.
  - bigiain 14y ago
    The problem is, I want my phone to be able to authenticate with way more than just Google services. And I want it to be able to do that in a way which doesn't require me to remember several dozen secure-against-2012-vintage-password-cracking-techniques. I _know_ that sometime in the next year or two we'll see another password leak like, say, LinkedIn's recent one - so I know I need to use 12+ "upper, lower, number, and 'special'" character non-dictionary passwords to ensure I'm not trivially exposed by rainbow tables or gpu crackers. A quick count on my phone just now, there's at least 33 different services my phone "remembers" it's login for. Some of them use OAuth-style authentication (Twitter and Flickr, for example), and some (Google, Facebook, and Amazon) are 3 factor auth protected (but, against a rooted phone that wouldn't help much, since I'm using the Google Authenticator app to generate the auth tokens, if my phone were under someone elses control they could watch me using and unlocking the authenticator app...) But there are still dozens of services - email accounts, websites, web service backed apps - that require the phone to have access to the cleartext password, either from me remembering it and typing it in, or from it's own storage mechanisms - secure or not. My phone would be _remarkably_ less useful to me if it didn't store passwords, or only worked with services that didn't require password storage.
  - anothermachine 14y ago
    Yeah, Google would never ship software where "Password is stored on disk in plain text" https://code.google.com/p/android/issues/detail?id=10809#c48 https://code.google.com/p/android/issues/detail?id=10809#c48
- jayfuerstenberg 14y ago
  The decryption keys aren't just sitting out in the open so any amount of encryption is better than none. This is like asking why would we encrypt data on a server since the decryption keys are accessible. Of course they are, they're needed to decrypt the data. But at least it takes more time to find the keys and that "can" be a deterrent much the way "The Club" is a visual deterrent that can still keep a car from being stolen by demanding too much time to break it.
  - charlesju 14y ago
    When you properly encrypt server passwords, they are not supposed to be decrypt-able. Whereas, this is supposed to be a two-way encryption as you need to access the raw data. Ergo, any form of encryption you can do can be easily undone and thus rendering your efforts moot. http://en.wikipedia.org/wiki/Salt_(cryptography) http://en.wikipedia.org/wiki/Salt_(cryptography)
    - jayfuerstenberg 14y ago
      I understand one way hashing but what about DB passwords for instance? You need access to plaintext passwords. This is getting long but the point is plaintext = he worst thing you can do. Even ROT13 is a little better.
      - jrockway 14y ago
        Even ROT13 is a little better. No it's not.

SoftwareMaven 14y ago

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 way, the phone won't either, so it won't be able to log you in. The only answer is to not let your device store your password. Choose security or convenience, but don't expect both. (This is no different than Pidgin storing your passwords in plaintext[1] with the exact same reasons and consequences.) 1. https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords

hetman 14y ago
Yes but there are other ways to mitigate the risks somewhat. Temporary revokable tokens would at least mean an attacker doesn't gain a permanent foothold, and never discovers the password.
mentat 14y ago
PBKDF2, it works for deriving keys to decrypt other things.
- dfox 14y ago
  But still you need to have whatever you use as input into KDF accessible. Encrypting passwords that you still need to be able to send somewhere without additional user interaction simply does not have any security benefit. Full-device encryption does work, building separate encrypted credential store is mostly useless security by obscurity.
  - mentat 14y ago
    You can have an encrypted keystore which is opened by entering a password and using that derived key to decrypt the keystore. Firefox uses this with their "master password". You can cache the decrypted key according to some policy which doesn't necessarily result in it getting written to disk. Also, down votes? Really?

pygorex 14y ago

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.

archivator 14y ago
As someone on Reddit pointed out, the minimal API version of the app is 4, which corresponds to Android 1.6, which, incidentally, does not have the AccountManager infrastructure. 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.

kephra 14y ago

> While rooting a Samsung Galaxy S3 only takes about five minutes, the software tools required are uncommon enough that as long as your phone isn’t already rooted you likely don’t have anything to worry about. 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.

zobzu 14y ago

"When you have a rooted Android phone, it’s widely understood that all bets are off as far as vulnerabilities are concerned." FUD

unitesting24 14y ago

Maybe they should be added to http://plaintextoffenders.com http://plaintextoffenders.com

buster 14y ago

Wow.. what a bad title.. As far as i understand it's one application they found called S-Memo which stores passwords as plaintext. The title makes it sound as if all application passwords are stored plaintext somehow.. Wow... I guess i'll just avoid geek.com.