Get out of the users way

[uniquePWD]

If I've encrypted my messages once, I don't need to re-authenticate every now and again. The app should make users' lives easier not add a hurdle. If a user wants their phone secured, they're likely to have a system wide lock or even an app lock. But a users shouldn't have to re-enter their password just to open their messages because the app is being overzealous.

I also suggest using the Android AccountManager: http://developer.android.com/reference/android/accounts/AccountManager.html

[ghost]

+1

We shouldn't bug the user.

[moxie0]

Data is locally encrypted with a user's passphrase. There's no sense encrypting it with a passphrase if the passphrase is stored in plaintext on disk next to the encrypted data. The only way to do it is to never write the passphrase to disk, and to keep it in memory. If the passphrase falls out of memory, we need to prompt the user for it again.

There is an option to disable local encryption entirely in the TextSecure settings, and the user is offered the option to skip passphrase creation at install time as well. If you have any other suggestions for making the process easier, please let us know.

[uniquePWD]

But the point here surely being that the current method isn't doing it's job. There needs to be a middle ground between always prompting a user and storing in plain text. Perhaps rather than storing the password, store a hash that can be checked to authenticate the passphrase without prompting the user.

At the very least, it needs to be made clearer that enabling encryption will periodically prompt the user for the pass phrase.

[uniquePWD]

So I've been looking into this further and: "AccountManager can generate auth tokens for applications, so the application doesn't need to handle passwords directly. Auth tokens are normally reusable and cached by AccountManager, but must be refreshed periodically. It's the responsibility of applications to invalidate auth tokens when they stop working so the AccountManager knows it needs to regenerate them."

also

"Gmail store authentication tokens instead of passwords if the service supports them, minimizing the risk of a user’s password being compromised."

Now can we switch to using a token system and get out of the users way? Quite frankly speaking, if a users system is compromised, they're more likely to have a keylogger running than they are to have something that has managed to breach the accounts.db given the stringent permissions system in place.

[moxie0]

@sabret00the "Tokens" are for situations like OAUTH where there's a server you're authenticating to. It's basically a per-device password that can be revoked. Disk encryption is a very different situation.

Unfortunately there really is no "middle ground" here. Storing a hash of the user's passphrase doesn't buy us anything, we'd still need the actual passphrase to decrypt the locally stored data. If you have any suggestions for improvements within the constraints that we have, particularly how to message this better, please let us know.

[rhodey]

The account manager on android was designed to share OAuth credentials for web apps between multiple android apps-- and even for that it's a bit weird. If we were to store the users passphrase in pain-text within the account manager then our threat model would worsen considerably.

I would put my money on even the most basic police cellphone forensics tools dumping the contents of AccountManager (ie in your proposed model your TS encryption passphrase).

[moxie0]

One more note, local encryption isn't about online device compromise like malware, it's about offline compromise. The point is that I can lock TextSecure or turn my device off, walk through customs, and know that there's nothing they can do to retrieve the plaintext.

[uniquePWD]

Okay, so reading back through this, I'm reminded of an XKCD strip: http://xkcd.com/538/

So I've decided to approach the problem from a different perspective. How about simply giving the user a choice. Security Level: None (no local encryption), Mild (local encryption but passphrase stored in AccountManager and while not in the way of the user, susceptible to physical attack) and Max (prompts the user repeatedly for the luxury of using the app)?

[moxie0]

I can't think of a single attack (online or offline) that the "mild" case would prevent.

[uniquePWD]

I'm unable to find a case of the AccountManager being breached in either Jellybean or KitKat. The system itself is designed to hold secure credentials. While maybe not at the level of espionage. It would enable a level of encryption whereby other (malicious) apps couldn't read the messages.

[moxie0]

I'm not sure what an AccountManager breach would mean, it's just an API to store things on disk with a built in mechanism to share those credentials with other apps.

Think of it this way, if TextSecure can get the user credentials it needs from the AccountManager, then anyone with the TextSecure UID (or root) can get the credentials. No more or less secure than storing them in plaintext the /data/data/textsecure directory.

[uniquePWD]

I've been looking into this further and getting the UID of TextSecure isn't an easy feat, which would justify mild.

[moxie0]

Yes, but to read any unencrypted TextSecure data, you'd also have to elevate your privileges to that UID. This is just to say that there is no difference between "mild" and "none." They're fully reducible to each-other.

[uniquePWD]

I think you're overly trivialising what the mild proposal does. To get access to the encrypted data, a person or app would have to get the TextSecure UID which is no easy feat in order to unencrypt the data. That is without a doubt a big difference between not having any local encryption at all. And falls smack-bang between "Max" and "None".

[moxie0]

Let's say there's no encryption. An attacker either needs to:

1) Escalate to the TextSecure UID to read the data out of the app's sandboxed area.

or

2) Physically take the storage out of the device and read the data.

Let's say there's "mild" encryption. An attacker either needs to:

1) Escalate to the TetSecure UID to get the key to read the data out of the app's sandboxed area.

or

2) Physically take the storage out of the device and read the key to read the data.

There is no difference from the attacker's perspective. There are no attacks that "mild" encryption prevents.

[uniquePWD]

So just for to clarify, as things are currently set up, you're saying that if local encryption is disabled. TextSecure will encrypt message database anyway?

If yes, then I assume a local encryption key/passphrase is stored on the device?

[ghost]

No. I just got a dummy notification, which turned into a bad encrypted message and rendered communication with the other party impossible. On Feb 27, 2014 10:29 PM, "Paul" notifications@github.com wrote:

So just for to clarify, as things are currently set up, you're saying that if local encryption is disabled. TextSecure will encrypt message database anyway?

If yes, then I assume a local encryption key/passphrase is stored on the device?

Reply to this email directly or view it on GitHubhttps://github.com/WhisperSystems/TextSecure/issues/686#issuecomment-36287478 .

[moxie0]

@sabret00the password based encryption works like this: a random cipher key and mac key are generated, which are then encrypted using PBKDF2 of the user's passphrase. That is all written to disk. Any time a user "unlocks" the app, they are prompted for their passphrase, which is used to decrypt that cipher key and mac key.

If a user disables local encryption, we still do everything the same way, only we use a static passphrase like "insecure" or something that we don't prompt the user for. This is not because it's more "secure," but just because it means there's a single code path through the system in dealing with data.

[uniquePWD]

Thanks for the clarification @moxie0 it makes perfect sense now. Thank you and everyone else following this bug for the patience shown. Perhaps some work could be done on the language to make the user experience a less confusing one.