V3 feedback

[cybercybercyber]

3.3: This may be necessary to interact with other applications/systems. E.g. if the application is using a (standard) protocol that uses SHA1 in some place, it wouldn't be compliant with this standard

3.7: Maybe instead of forcing to create them at installation time, at (first) time of use would be sufficient? I suspect the point this requirement is trying to make is that keys shouldn't be delivered with the application, so it might be worth phrasing the requirement this way. Also, it might be worth to include the requirement that secret keys used by the application have to be created on the device. It should also be phrased so that it's possible to use 3rd party APIs that use a secret key for authentication (e.g. to use OAuth authenticated APIs).

[cybercybercyber]

Also might be worth to include a requirement that the appropriate cryptographic primitives should be used (e.g. don't use encryption alone if you want to ensure the integrity, and don't use signing alone if you want to protect the confidentiality).

[muellerberndt]

3.3: This may be necessary to interact with other applications/systems. E.g. if the application is using a (standard) protocol that uses SHA1 in some place, it wouldn't be compliant with this standard

Could happen, but sounds like a rare case to me. Of course you can always accept the risk if you really, really need to use that particular protocol, and then simply not be fully compliant with MASVS.

Do you have examples where this would be an issue?

3.7: Maybe instead of forcing to create them at installation time, at (first) time of use would be sufficient? I suspect the point this requirement is trying to make is that keys shouldn't be delivered with the application, so it might be worth phrasing the requirement this way. Also, it might be worth to include the requirement that secret keys used by the application have to be created on the device. It should also be phrased so that it's possible to use 3rd party APIs that use a secret key for authentication (e.g. to use OAuth authenticated APIs).

Agreed that this requirement somewhat confusing and maybe too far-reaching. If we just want to make the point that the keys shouldn't be delivered with the application, then this is a variant of 3.1. Not sure if we should keep this at all.

Also might be worth to include a requirement that the appropriate cryptographic primitives should be used (e.g. don't use encryption alone if you want to ensure the integrity, and don't use signing alone if you want to protect the confidentiality).

I guess this is what be meant buy "Cryptographic modules use parameters that adhere to current industry best practices." I'll try to improve the wording there.

@cybercybercyber are you still reading the responses? Your feedback was quite a lot and I want to answer every issue first before I start editing anything. As I already mentioned there is new branch for making the changes. Also, what is your real name, for adding to acknowledgements?

[commjoen]

The new version of 3.4 would still render an app using SHA-1 as being a violation of this standard. I would rather say something such as: " The app does not use cryptographic protocols or algorithms that are widely considered depreciated for security purposes." This would allow one to say that deprecated algorithms for hashing can still be used for data generation for instance.

Would it be a good idea to say something about where one needs to use encryption for, what can be used for data integrity, what can be used for (source and/or receiver) authentication, etc. in terms of cryptographic operations. But this should just be an explanation, not necessarily a verification requirement. If you want a requirement, you could state that cryptographic controls are applied for the purpose to which they are inteded (or someting along these lines) and then refer to the explanation.

[sushi2k]

Would it be a good idea to say something about where one needs to use encryption for, what can be used for data integrity, what can be used for (source and/or receiver) authentication, etc. in terms of cryptographic operations. But this should just be an explanation, not necessarily a verification requirement.

That's a good point for the MSTG, when the details of the requirement are written for the test case. I guess there might already be something in the Android documentation, maybe this can then only be referenced.

[muellerberndt]

The new version of 3.4 would still render an app using SHA-1 as being a violation of this standard. I would rather say something such as: " The app does not use cryptographic protocols or algorithms that are widely considered depreciated for security purposes." This would allow one to say that deprecated algorithms for hashing can still be used for data generation for instance.

Yeah that makes sense.

Would it be a good idea to say something about where one needs to use encryption for, what can be used for data integrity, what can be used for (source and/or receiver) authentication, etc. in terms of cryptographic operations. But this should just be an explanation, not necessarily a verification requirement. If you want a requirement, you could state that cryptographic controls are applied for the purpose to which they are inteded (or someting along these lines) and then refer to the explanation.

This is what we were trying to express with:

3.3 The app uses cryptographic primitives that are appropriate for the particular use-case (...)

It's very generic for sure :) Like @sushi2k said, elaborating on this in detail is part of the test case in the MSTG.

[commjoen]

If we leave these kind of explanations to the MSTG, I Would recommend showing these dependencies in the introduction chapter . Otherwise a "newbie" would not know where to look.

[muellerberndt]

If we leave these kind of explanations to the MSTG, I Would recommend showing these dependencies in the introduction chapter . Otherwise a "newbie" would not know where to look.

MSTG references added.