Insecure Authentication

High

Description

Insecure or weak authentication for mobile applications allows an attacker to authenticate himself anonymously, it is fairly prevalent due to the common weak mobile devices input factor, 4-digit PINs are a great example of it. Either a weak password policy due to usability requirements or authentication based on features like TouchID makes your application vulnerable. Contrary to what you may think, unlike passwords, you may be forced to give up your fingerprint.

Attack Scenario

Whether the checks are being made on the server side or the client side, depending on the authentication logic of the application, The attacker may try to bypass the checks of the application to authenticate himself. this can happen due to a weak password policy, missing rate limit, flawed/broken logic, insufficient workflow validation, or vulnerable dependency.

Mitigation

Avoid the following Insecure Mobile Application Authentication Design Patterns:

  • If you are porting a web application to its mobile equivalent, the authentication requirements of mobile applications should match that of the web application component. Therefore, it should not be possible to authenticate with fewer authentication factors than the web browser.

  • Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through run-time manipulation or modification of the binary.

  • Where possible, ensure that all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication.

  • If client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials. This will ensure that the stored application data will only be accessible upon successfully entering the correct credentials. There are additional risks that the data will be decrypted via binary attacks.

  • Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device.

  • Ideally, mobile applications should utilize a device-specific authentication token that can be revoked within the mobile application by the user. This will ensure that the app can mitigate unauthorized access from a stolen/lost device.

  • Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-location.

  • Persistent authentication within mobile applications should be implemented as opt-in and not be enabled by default.

  • If possible, do not allow users to provide 4-digit PIN numbers for authentication passwords.

ID: 30006