Samsung Galaxy S3 stores passwords in plain text | Hacker News Reader

Samsung Galaxy S3 stores passwords in plain text

geek.com

64 pointsjgnatch37 comments

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

While I'm mostly for the name-and-shame approach to lazy security practices, these "x stores passwords in plaintext" have become just as lazy. It's just an excuse for developers to feel better about themselves because they know about hashing passwords. Case in point, this article suggests Samsung should hash the passwords, which wouldn't work here. I suppose it does good to bring Samsung's oversight to light, but the reader gets nothing from the article.

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.

If Android doesn't provide suitable password management facilities, they could use the wallet approach and encrypt the password wallet with a key derived from/protected by the user's unlock code.

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

Yes, they could use the TPM/Secure Element, but that really only protects against attacks where the memory is removed from the device and the device is lost. (Unless you want to require the user to enter a PIN each time they want a password; then a hardware-based solution provides reasonable security.)

Honestly, that never happens.

Ever it that would happen it would not help in this situation anyway. The application simply needs to be able to access that data.

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

It is bad either way. The phone should keep an access token (which can be revoked), not store the user's password.

That's a great plan - we now just need to convince every website and web service (and whatever else your phone authenticates with) to update their authentication method to use these access tokens.

So are you going to phone Apple and ask them to change their website/ITMS/iCloud/DeveloperCenter password/authentication system? No? Neither am I.

Samsung storing the passwords in cleartext is lazy, but if the assumption is "you can only read that cleartext file if you've got root", since a consequence of having root means you can intercept anything the user does anyway, it's _maybe_ an excusable decision. I'm quite surprised they didn't choose to use a passwordsafe/keypass/lastpass/1Password style encrypted storage format though. It's not exactly rocket surgery…

(I wonder how that file appears on backups though? Does Android by-default encrypt backups? I know iPhone _can_ encrypt them, but doesn't by default. This file could be quite dangerous if it's sitting on a lot of people's laptops/desktops unencrypted...)

There is already a standard called OAuth, which Twitter, Facebook, Google and most services implement, and can offer tokens that do not expire. It's not just an idea, it's how thousands of apps already work.

Passwords are not included in iPhone backups. When you restore from a backup, you are prompted for wireless network passwords, for example, that the phone would have just connected to before the backup/restore.

Depends if you encrypt your backups or not. If so, passwords are restored to the device along with the rest of your data.

The correct way for them to handle this was to defer to AccountManager and allow Android to handle the Google authentication.

Similarly, users should not give credentials to 3rd party applications. I would not give Samsung my Gmail login, nor would I give it to Facebook to let them scrape contacts.

PBKDF2, it works for deriving keys to decrypt other things.

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.

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?

> 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.

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.

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.

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.

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

FUD

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

This thread has more details:

http://forum.xda-developers.com/showthread.php?t=1983672

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.

It isn't. Storing passwords on a mobile device, unencrypted or encrypted, is just wrong.

Fortunately authenticating with Google services requires neither.

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.

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

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.

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)

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.

Even ROT13 is a little better.

No it's not.

Really? So device encryption is pointless then? Same for a jailbroken iPhone? That seems hard to believe.

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.

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?

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.

Reply on news.ycombinator.com