Menu

Password compliance check returning the wrong result on device

Environment

Overview

You may encounter an issue where your managed devices perform a password compliance check and return the wrong result, causing them to be quarantined.

Cause

This is a known issue impacting only FDE-based devices. If the password requirements are changed after the device is booted up, the current password will no longer meet the requirements. Due to changes introduced in Android P, the API that checks if the active password is sufficient may return an incorrect value before the password is entered on a device for the first time.

isActivePasswordSufficient() will only return the last known state of password sufficiency. If the password requirement is changed before the user unlocks the device for the first time, the value returned by isActivePasswordSufficient() will not reflect the new password requirement until the user locks and unlocks the device.

                                                                   

Resolution

This behavior is by design. To avoid compromising your potentially sensitive data, the full set of active password metrics is not stored on your device.

Workaround

For IT admins:

Please consult with your UEM provider for further information on how they have implemented the password sufficiency policy.

For UEMs:

To handle this password compliance issue, the Device Policy Manager (DPM) can take one of three actions:

  1. Postpone updating the password requirement until the user locks and unlocks the phone for the first time.
  2. Skip updating altogether if the password requirement will not change.
  3. Simply disregard the value of isActivePasswordSufficient() during the window of time when the password requirement is being modified.

Additional Information

For a detailed breakdown of what code changes were made in AOSP to address this issue, head to the Android Git repository.

To learn more about FDE and FBE, see Full-disk encryption (FDE) and file-based encryption (FBE).

Back to KBAs