User Pin's stored in plain text - Vulnerable to information leakage.

The security pins are stored in plain text for every user, in a single file. They can be used to leak sensitive information for a user. More importantly, this can be of more concern in the prod version.

Steps to reproduce the behavior:

1. Open terminal
2. Type adb shell
3. Type su
4. Once root (type whoami to confirm), navigate to the app’s directory. It is located in ~/data/data/org.oppia.android/files
5. Type cat profile_database.cache
6. See The info leak

Expected behavior An attacker should not be able to find out the user pins. We can solve this using a two ways ->

1. Store the Encrypted hash of the user pin, rather than the plain text.
2. Store the user pin using the KeyStore Android API

The 2nd option though being a more secure option, would demand a lot of code refactor and since we are using PersistentCacheStore it would become a mini project, just to implement this. The First option seems more reasonable, since we can hash the pins using state of the art encryption algo, it would demand a lesser code refactor while providing the security benefits.

Screenshots

Device

• Google Pixel 4 emulator
• SDK version 28

[BenHenning]

Thanks for filing this @justdvnsh, and I really appreciate the very detailed report!

We actually intentionally use 3 & 5 digits for user PINs so that they aren’t accidentally reused as sensitive PINs in the user’s life (such as a bank PIN). To this end, PINs are just a local property that is used to get into the profile. They’re not equivalent to passwords or keys, and in general don’t require the same level of security measures. Further, while you’re correct that storing them in plain text leaves them as human-readable, accessing the cache store file isn’t easy. Android apps’ individual storage directories are locked down via permissions. Other apps can’t access these directories, and accessing it via a computer requires developer mode + ADB (which was the approach you took to discover this issue). I’m not actually seeing a pathway where these files can be leaked–am I missing something?

That being said, it may be reasonable to hash the PIN rather than store it in plain text for the purpose of it being perceived as sensitive. This requires more thought, though, since we also need to store the PIN remotely once we finish remote profile syncing. I’ll take this issue as an advisory suggestion for the profile system once we start on the remote syncing project.

[BenHenning]

Going ahead and closing this since I don’t think there’s actually a vulnerability here. Please follow up @justdvnsh if you have any further thoughts or questions on this.

Thanks again for filing this issue!