Is 2.4 possible to enforce?

[mmierzwa]

I have a question regarding a requirement from V2:

2.4 The keyboard cache is disabled on text inputs that process sensitive data.

Is this requirement practically enforceable on all major mobile platforms?

I'm asking this from a mobile developer perspective. For example, take a look at this discussion on forcing the system keyboard on iOS It's just the case I faced recently trying to disable 3rd party keyboards for certain input types on iOS (not for security reason). I guess there could be much more such cases (look at this SO thread on Android)

[muellerberndt]

That's a very interesting question that we conveniently ignored so far. Our test cases for Android and iOS only handle the default case.

What we did have before was a L2 requirement saying that highly sensitive apps must implement their own keyboard. This would address the issue indirectly by not using the keyboard offered by the OS. But then, shipping a keyboard with app is IMHO a clunky / hackish solution.

We'll need to do research into wether the system keyboard can be enforced, or consider re-introducting that requirement in some way.

[mmierzwa]

I agree that shipping the application with it's own keyboard is not a best solution, especially from the UX perspective. However the security matters often takes precedence before the better user experience.

Like I wrote, according to my knowledge (based on few hours research) there is no such possibility, at least on iOS. I have not found any solution for Android as well. On iOS we can only limit the possibilities by requiring specific capabilities (i.e. alphanumeric or ASCII only) but that's not the case.

EDIT: Of course, writing that "there is no such possibility" I meant - no possibility of forcing the default/system keyboard :)

[commjoen]

Well, I have implemented "custom application keyboards" in both Android and iOS: for the most sensitive parts (e.g. the screen where you enter your password/pin). In fact I gave a talk about it at BigAndroidBBQ last year ... You don't write an ACTUAL keyboard: instead you create a set of image-buttons with listeners that add chars to a char-array that is wipeable. The moment you start off using strings, you sort of defeated half the purpose in Java. In iOS you can have a NSMutableString being build up as long as you overwrite it properly.

[commjoen]

You can btw ship it as a viewgroup or something else, so you can easily reuse it across fragments/activities, etc.

[mmierzwa]

Of course, writing that "there is no such possibility" I meant - no possibility of forcing the default/system keyboard :)

[muellerberndt]

For me as a security consultant, it boils down to the question: Do I really want to recommend implementing custom keyboards to anyone? What's the value gained vs. the implementation effort, added complexity, loss in usability? For me, the math doesn't add up here. Same as E2E encryption.

It could be one of these requirements where we say it's L2 and optional anyway, but then I'd rather not have an optional requirement I don't actually want anyone to use (that's the ones we put in L4 when there were still 4 levels).

[mmierzwa]

@b-mueller I fully understand your point from both business and software developer perspective.

On the other hand, as I understand the motives behind creating MASVS, one of the goals is to broaden the awareness of potential threats. As the author you can verify my thinking.

Of course, some of them are more feasible than the others. From this perspective it may be worth to at least mention this somewhere/somehow. I don't know if this document and this way (by stating a clear requirement) is a best place for this.

Did you consider moving some of the most controversial requirements to the higher "paranoid" level? This could be treated as an informational/optional level as you suggested (and put even in appendix to highlight this fact ;-) )

[commjoen]

I think we want to keep it in for now and make sure that we do have valid testcases and solution alternatives in the mstg