Real world scenario for V2 Data Storage 2.12 and 2.13

[sushi2k]

Hi,

I think Jeroen was adding the following two items in the MASVS Data Storage Chapter:

2.12 If a remote locking mechanism exists, local storage is wiped upon locking.
2.13 The app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode.

Source: https://github.com/OWASP/owasp-masvs/blob/master/Document/0x07-V2-Data_Storage_and_Privacy_requirements.md

I think I understand the idea for both, but I am struggling on how this can actually be implemented in a real world scenario.

• What should trigger the wipe process (e.g. failed login attempts)?
• What does "local storage is wiped" mean? Shall the App trigger an uninstallation process of the App itself that the user need to confirm? If so the attacker would of course not proceed here.
• If the App really leverages some of the Device Admin functions in order to enforce device security mechanisms, it might get way too powerful and is in conflict with having only Android permissions it needs to operate correctly. https://developer.android.com/guide/topics/admin/device-admin.html#sample

If we cannot come up with a proper real world scenario where these requirements are actually helping and improving the security of the App and Android device, I would suggest to delete both.

[clviper]

Hi @sushi2k

2.12 If a remote locking mechanism exists, local storage is wiped upon locking

The only idea that occurs to me is:

• After first login with succcess, the application stores some guid that is mapped to the user;
• Each time during login makes a request with that guid to confirm that the user is not in a locked state. If it is(due to too many incorrect logins, account reported to be compromised), procceeds to clean the information inside the application sandbox (shared_prefs,sqlites,etc) that contain user information.

2.13 The app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode.

I think the application can query the Settings.Secure to confirm that, does not need Device Admin permissions. Not completly sure.

[sushi2k]

@clviper I like this approach, then it can also be controlled from server side in case the device is lost/stolen. Even though an attacker could of course easily bypassing this by going into flight mode, then the mechanism will not be working. For 2.12 there is actually an API function introduced in API Level 19 (KitKat) called clearApplicationUserData that is able to clear the App Data. https://developer.android.com/reference/android/app/ActivityManager.html#clearApplicationUserData()

@clviper Good idea to just query the settings. So for 2.13 we could suggest that the App should check for a minimum security policy by querying the settings and if the checked settings are not adequate according to what the App want's to enforce it's closing itself. What would make sense for an App to check for? I guess this would be a first draft for a minimum policy:

• Check if a password/pin is set for lock screen
• Check if filesystem encryption is activated, e.g. by using getStorageEncryptionStatus()

What else?

[clviper]

@sushi2k nice, didn't know the clearApplicationUserData function. Yeah, I think for a first draft those recommendations will do. Another thing that can be confirmed is if the adb is enabled by querying Settings.Global.ADB_ENABLED

[sushi2k]

I am still not convinced of the following requirement:

2.12 If a remote locking mechanism exists, local storage is wiped upon locking.

For an iOS or Android device a remote factory reset can be executed that resets the whole device. If a user looses his device or it's stolen he would go anyway this way. I cannot think of real world scenario where I only want to remotely erase one App and it's data, as anyway I want to wipe the whole device if only have remote access to it. On top of it, it would create a risk as such a function could either be misused by an attacker that is in possession of my user credentials, or by the company that creates the App and offers such a function.

Therefore I would suggest to remove this requirement.

[sushi2k]

As there are no objections from anyone, I will remove this requirement now.