4 ms·
This is the nature of shipping client code. Any key they used can be extracted by a sufficiently determined individual. The real security issue was not storin
by andymcsherry 13y ago
This is the nature of shipping client code. Any key they used can be extracted by a sufficiently determined individual. The real security issue was not storing the database in the app's private directory.
- acchow 13y agoThe real security issue is using the same symmetric key with every client.
- andymcsherry 13y agoThat's really just security through obscurity. You're still shipping code that explains the process of obtaining the key. If they store their credentials to obtain the key in a public directory, it's just as vulnerable.
- hueving 13y agoWrong. If a phone can only retrieve the key for it's own number (e.g. via SMS request), that's orders of magnitude better than the current case where one key can decrypt logs for any arbitrary number. Each SMS request could generate a new key, so even if another app on the same phone does it, it won't be able to get the key to read the logs.
- andymcsherry 13y agoThis still relies on the legitimate app not storing the key they fetched in a public directory so the attacker can read it. You can keep adding layers upon this, but it doesn't change that.
- hueving 13y ago>This still relies on the legitimate app not storing the key they fetched in a public directory so the attacker can read it. Obviously. Why would they do anything else? The point is that they can safely store the logs on an SD card under space constraints.
- meowface 13y agoNot really. No matter what or how many keys they used, someone who stole your device could root your phone and determine the key. Unless they did something like require the user to enter a master passphrase every time they started the app, then there is no real way around this.