Hacker News Reader

Comment by SoftwareMaven | Hacker News Reader

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

View on HN

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?

Reply on news.ycombinator.com