V5 feedback

[cybercybercyber]

5.1: To me, "sensitive" here is used differently than in the rest of the standard. Take an application like Whatsapp for example. I would argue that all the text messages are sensitive enough to send them using TLS, but not sensitive enough to qualify for most of the requirements in V2 (e.g. disabling clipboard for a chat application is a significant UX issue).

5.2: Should this requirement spell out that "verifies the X.509 certificate" entails:

• checking the CN matches the domain name
• checking it's not expired
• checking it hasn't been revoked
• valid signature, etc.

5.3: Availability is a security property as well, and pinning certificates is weighing availability against confidentiality/integrity. I don't think this should be a requirement, but rather applications should weigh the risks and benefits and make a decision for themselves. Also, most applications will implement pinning incorrectly, and e.g. forget that certificates expire, so I think the standard should provide some guidance on how to implement this correctly.

5.5: I'm not sure I understand this requirement. I'm assuming it means that in addition to SMS it also requires the password for step-up? Might be worth to add an example. If I understand correctly, I agree with this requirement in principle, but note that most account recovery mechanisms that are out there rely on a single factor like email or SMS at the moment.

5.6: I think this requirement needs additional guidance, e.g. on how to distribute client certificates. I have two scenarios in mind how implementors might try to implement this requirement: a) they require users to get a personal certificate from a CA that verifies their identity (government card or something like that) b) a client certificate is generated after the user logs in.

I feel like (a) is an overkill for the vast majority of even super sensitive applications, and (b) doesn't provide additional security, since there's no client certificate available for authentication, and anyone with the valid credentials can generate their own certificate, and a secure session ID provides just as much authentication as a client certificate. Then again, maybe I'm misunderstanding this requirement or I'm missing a way to implement this practically.

[muellerberndt]

5.1: To me, "sensitive" here is used differently than in the rest of the standard. Take an application like Whatsapp for example. I would argue that all the text messages are sensitive enough to send them using TLS, but not sensitive enough to qualify for most of the requirements in V2 (e.g. disabling clipboard for a chat application is a significant UX issue).

This leads back to the problem that we don't have a consistent definition of "sensitive data" in the MASVS. I'll try to address this in V1 and the "using the MASVS" chapter. Btw, are you still around to have a look at the next draft / help writing it? If you want please also provide your full name so I can add you to the contributors list.

5.2: Should this requirement spell out that "verifies the X.509 certificate" entails (...)

Again, this is something that will be elaborated on in the respective test case in the MSTG. Not sure if we should go into more detail here?

5.3: Availability is a security property as well, and pinning certificates is weighing availability against confidentiality/integrity. I don't think this should be a requirement, but rather applications should weigh the risks and benefits and make a decision for themselves. Also, most applications will implement pinning incorrectly, and e.g. forget that certificates expire, so I think the standard should provide some guidance on how to implement this correctly.

See 5.1 - the decision between MASVS L1 and L2 should be based on the data sensitivity level / business risk in the first place. So you'd choose L2 - which includes SSL pinning - only for high risk apps.

5.5: I'm not sure I understand this requirement. I'm assuming it means that in addition to SMS it also requires the password for step-up? Might be worth to add an example. If I understand correctly, I agree with this requirement in principle, but note that most account recovery mechanisms that are out there rely on a single factor like email or SMS at the moment.

AFAIK this was meant for account recovery and enrollment. For these two use-cases I think it's an appropriate L2 requriement. Also sounds like overkill for step-up-authenticaton to me.

5.6: I think this requirement needs additional guidance, e.g. on how to distribute client certificates. I have two scenarios in mind how implementors might try to implement this requirement: a) they require users to get a personal certificate from a CA that verifies their identity (government card or something like that) b) a client certificate is generated after the user logs in.

I feel like (a) is an overkill for the vast majority of even super sensitive applications, and (b) doesn't provide additional security, since there's no client certificate available for authentication, and anyone with the valid credentials can generate their own certificate, and a secure session ID provides just as much authentication as a client certificate. Then again, maybe I'm misunderstanding this requirement or I'm missing a way to implement this practically.

I agree with you here as well. Managing this is so complicated that it's simply not worth doing it. @sushi2k @jeroenwillemsen comments please, otherwise I'll remove this.

[muellerberndt]

5.1: To me, "sensitive" here is used differently than in the rest of the standard. Take an application like Whatsapp for example. I would argue that all the text messages are sensitive enough to send them using TLS, but not sensitive enough to qualify for most of the requirements in V2 (e.g. disabling clipboard for a chat application is a significant UX issue).

That's actually a difficult one. We need multiple data sensitivity levels then :) Or how should we rewrite this? Does it make sense to require encryption for all data sent over the network, or something like "whenever possible"?

[muellerberndt]

I have to say I'm not too happy with the network requirements overall. They are all very generic except one requirement - "5.4 - The cipher suite used to encrypt network data enables perfect forward secrecy." Apparently perfect forward secrecy is the only important property to have? It's just inconsistent.

Either we leave it at four generic requirements - "appropriate settings" etc. and have more details in the MSTG, or we list the most important settings in the requirements. We could refer to this resource for example.

[sushi2k]

@b-mueller: Agree, when looking at the requirements we should get rid of 5.4 and 5.6. Leave the other requirements and go into detail in the MSTG.

Isn't 5.5 already covered in

4.8 A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced.

I think 5.5 could be one of the recommendations in the MSTG for 4.8, as 4.8 is also a Level2 requirement.

5.5 The app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery.

Why is 5.5 anyway in Network Communication? If it's a requirement on it's own it should be in "Authentication and Session Management".

[sushi2k]

We also should rewrite 5.1, by saying

5.1 The communication channel is encrypted on the network using TLS. The secure channel is used consistently throughout the app.

Otherwise it might be misleading by using HTTP for "non-sensitive" data.

[muellerberndt]

Why is 5.5 anyway in Network Communication? If it's a requirement on it's own it should be in "Authentication and Session Management".

It's an edge case? It's talking both about authentication and communication channels.

[commjoen]

I have to say I'm not too happy with the network requirements overall. They are all very generic except one requirement - "5.4 - The cipher suite used to encrypt network data enables perfect forward secrecy." Apparently perfect forward secrecy is the only important property to have? It's just inconsistent.

In the latest version: if you have 5.2, you don't need the latest 5.5 anymore, but i would really provide a link to a standard/best practice that gets frequently updated.

Another thing: some older android clients might not be able to work with all the latest TLS settings. Should we recommend users of the standard then to still use this?

I agree with you here as well. Managing this is so complicated that it's simply not worth doing it. @sushi2k @jeroenwillemsen comments please, otherwise I'll remove this.

I think we can indeed remove this, it might be too much given our new direction of the MASVS.

Why is 5.5 anyway in Network Communication? If it's a requirement on it's own it should be in "Authentication and Session Management". It's an edge case? It's talking both about authentication and communication channels.

@sushi2k & @b-mueller I think 5.5 (The new 5.6) can be in both, it does not really matter.

[sushi2k]

Another thing: some older android clients might not be able to work with all the latest TLS settings. Should we recommend users of the standard then to still use this?

The requirements should be selected by the client and the MASVS just gives you the framework on what you should think about. The MASVS then be something where the client picks the requirements he need. If it's a financial banking application you might want to enforce a minimum Android version, so you can leverage for example all the best practices in TLS. If it's a simple game app then you need different, more lax requirements and might want to support as many Android versions as possible as it's a business requirement. Of course the Level 1 requirements are all recommend to use and build in an App, but they might not be applicable sometimes due to various reasons. At least the MASVS shows you what you are missing so you are aware of the risk and hopefully it's tracked in a risk register ;-)

[muellerberndt]

Another thing: some older android clients might not be able to work with all the latest TLS settings. Should we recommend users of the standard then to still use this?

Should we add something along the lines of "as far as they are supported by the OS"?

[commjoen]

@b-mueller sounds legit to me

[muellerberndt]

The issues have been addressed, closing this.