V4 feedback

[cybercybercyber]

(I hope you don't hate me yet)

4.2: Why do they have to be short-lived? Many large applications right now use long-lived tokens (log in once and use the application essentially forever), such as Facebook, Google, Whatsapp etc. Maybe an alternative would be to provide two different options: either use short-lived tokens, or provide the user with the ability to revoke longer-lived tokens.

4.4: Is this a duplicate of 4.2? Also, same comments apply.

4.5: Arguably this is outside the scope of a standard for mobile applications. Also note that some applications use OAuth for authentication (log in via Facebook/Google/LinkedIn), and therefore have no way to enforce a password policy.

4.7: I don't think I understand this.

4.8 & 4.9: Are there any specific requirements for 2FA? The issue with 2FA on mobile devices is that most implementations use the phone as a second factor (be it via a TOTP/HOTP or via SMS), so in particular 4.9 may not get you too much additional security unless you require a 2nd factor outside of the user's phone that the mobile application is installed on. Additionally, 2FA is notoriously bad UX (in particular on mobile), so it's quite likely the user will be pissed off if an application requires step-up auth too often.

4.10: binding the session id to the IP is fundamentally incompatible with mobile devices. Switching between different networks on your phone is just way too common. A local public transport mobile app where I live tried to implement this and it was quickly removed after lots of users complained. Also, what is meant by "indirectly using payload encryption"?

4.11: I'm assuming what is meant is invalidating specific sessions, rather than blocking individual devices?

Potentially you could also add a requirement saying that session identifiers need to be treated as credentials and must be stored per 2.1.

[muellerberndt]

(I hope you don't hate me yet)

No, but it is a lot of feedback to process :)

4.2: Why do they have to be short-lived? Many large applications right now use long-lived tokens (log in once and use the application essentially forever), such as Facebook, Google, Whatsapp etc. Maybe an alternative would be to provide two different options: either use short-lived tokens, or provide the user with the ability to revoke longer-lived tokens.

4.4: Is this a duplicate of 4.2? Also, same comments apply.

Yeah, these can be summed up to a single requirement. Hard to decide whether session timeout should be required in L1 or not. IMHO it's something that's quite essential from a security perspective. What's the point of having session tokens if they're valid indefinitely (I'm exaggerating a bit as they still can be invalidated on logout, but you get the point). On the other hand it is true that many apps implement long-lived tokens in practice. It would mean that these apps aren't fully compliant to MASVS. @sushi2k etc what do you think about this>

4.5: Arguably this is outside the scope of a standard for mobile applications. Also note that some applications use OAuth for authentication (log in via Facebook/Google/LinkedIn), and therefore have no way to enforce a password policy.

Strictly speaking out of scope, but including some basic requirements for auth was a conscious decision.

4.7: I don't think I understand this.

This is meant to prevent simply bypassing TouchID-auth etc. by patching the app. We'll have to elaborate on that in the MSTG and see if and how it works as a requirement.

4.8 & 4.9: Are there any specific requirements for 2FA? The issue with 2FA on mobile devices is that most implementations use the phone as a second factor (be it via a TOTP/HOTP or via SMS), so in particular 4.9 may not get you too much additional security unless you require a 2nd factor outside of the user's phone that the mobile application is installed on. Additionally, 2FA is notoriously bad UX (in particular on mobile), so it's quite likely the user will be pissed off if an application requires step-up auth too often.

Having 2FA does mean that you need to be in possession of the device, and not just the username password. IMHO this is a valid requriement.

4.10: binding the session id to the IP is fundamentally incompatible with mobile devices. Switching between different networks on your phone is just way too common. A local public transport mobile app where I live tried to implement this and it was quickly removed after lots of users complained. Also, what is meant by "indirectly using payload encryption"?

I'm with you on both points & also not in favor of having this requirement and payload encryption in general. @sushi2k @jeroenwillemsen any comments?

4.11: I'm assuming what is meant is invalidating specific sessions, rather than blocking individual devices?

No, it does mean blocking individual devices.

Potentially you could also add a requirement saying that session identifiers need to be treated as credentials and must be stored per 2.1.

This assumes then that session identifiers are saved permanently though. We'll still have to devide whether that's allowed or not (I could imagine it being allowed in L1).

[muellerberndt]

4.8 & 4.9: Are there any specific requirements for 2FA? The issue with 2FA on mobile devices is that most implementations use the phone as a second factor (be it via a TOTP/HOTP or via SMS), so in particular 4.9 may not get you too much additional security unless you require a 2nd factor outside of the user's phone that the mobile application is installed on. Additionally, 2FA is notoriously bad UX (in particular on mobile), so it's quite likely the user will be pissed off if an application requires step-up auth too often. Having 2FA does mean that you need to be in possession of the device, and not just the username password. IMHO this is a valid requirement.

Just to clarify the 2FA requirements, what we are talking about is something like SMS OTP that might well be linked to the particular mobile device. Mobile device as second factor is currently acceptable according to MASVS. The whole process can be transparent for the user (AFAIK it is implemented that way in all mobile banking apps here in Singapore). Does that make sense?

[boos]

I have the same vision of Cyberx3.

A "2FA" done on the same device where login and password are inserted does not provide any additional security/benefit and it's not exactly a two-factor authentication.

[sushi2k]

For requirement 4.7 (which was 4.4 before), i think it's a good way to go to have it as L2 requirement. Mobile Apps mostly have tokens that are long living, so it's different from a web app architecture where you want to have short timeouts. For highly critical Apps (like banking Apps) it should be a requirement to have a timeout.

For requirement 4.10, we can get rid of it. Binding the IP makes no sense as the IP changes regularly in a mobile network. Payload encryption is also something that fit's more into resiliency and is only slowing down an attacker.

[muellerberndt]

For requirement 4.10, we can get rid of it.

@sushi2k Already done.

A "2FA" done on the same device where login and password are inserted does not provide any additional security/benefit and it's not exactly a two-factor authentication.

@boos it's not ideal but still better than only having only username/password auth. If you compromise user creds without 2FA, you can use them to login from anywhere at any time. With a second factor that ties authentication to a particular device that's not easily possible. Sure, with root malware (or even just malware that can read SMS) it's not a big step up. Then again, that's where MASVS-R can make things more difficult.

It's a philosophical question as well. Whenever there's a security control X that can eventually be bypassed, pen-testers love to say "X is crap", when reality is more fine-grained than that. Most controls just raise the bar by a certain degree.

[commjoen]

@b-mueller I guess binding the session to an ip will not work indeed and 4.10 can indeed go, but still I believe that mechanisms, such as payload encryption, might make it harder to overtake a session as the other party will need the keys for that as well. I guess making payload encryption part of the standard MASVS lvl 1/lvl 2 might be too much as we do not want to get developers into applying their own payload encryption schemes... Still I wonder whether it would be a good recommendation to use payload encryption with ephemeral/session keys as a backup in case the SSL/TLS is broken...

@boos I agree with @b-mueller regarding 2FA: it is something that one can bypass (even without root on android, if the malware is part of an app that has access to SMSes), but it is still better than nothing and will indeed raise the bar by a little.

[muellerberndt]

@commjoen like you said, we don't want developers to invent their own schemes. Also, there's the false-sense-of-security factor that kicks in whenever there's E2E encryption. Why not focus on doing TLS correctly & hardening the config (SSL Pinning etc).