Do you really need a long complicated pass code on Android?
Traditionally, IT admins applied similar pass code requirements to Android devices as with server and desktop operating systems. However, this approach can be excessive and unnecessarily restrictive. Unlike laptops or desktops, where unlocking grants access to all user apps and services, Android operates differently.
As “Android is now the most common interface for global users to interact with digital services”*(1) with many organizations, from small businesses to large multinational corporations and government agencies, relying on Android devices to access sensitive company data, it’s important to understand the distinction. The key difference lies in how these operating systems handle app permissions. While server/desktop OS's typically consider all apps running within the context of the logged-in user account as fully authorized, Android operates with a more granular approach. Android apps are not inherently granted full authorization for all user actions.*(1)
This inherent security measure within Android mitigates the risk of malicious code exploiting the vulnerabilities of server/desktop OS's. On server/desktop systems, attackers often only need to execute malicious code with the currently logged in user's privileges to gain significant control. Android's more restrictive environment makes this type of attack more challenging.
Windows, macOS, and Chrome will typically use a username and password coupled with Single Sign-On (SSO) or Multi-Factor Authentication (MFA) that is tied to a corporate account to log into the OS. Android simply uses a PIN, pass code, or pattern that is not tied to a user’s LDAP or domain account to unlock the device. This separates the device unlock on Android by not having that tied to a corporate identity. This difference keeps an Android pass code to unlock a device separate from the user's account to access corporate services and applications.
In this way, the Android security model grants less power to users versus traditional OS's that do not require multi-consent models. The immediate benefit to users is that one app cannot act with full user privileges. The user cannot be tricked into letting it access data controlled by other apps due to the robust app sandboxing on Android.
So, do you really need a long pass code on Android if the unlock pass code is not tied to your corporate account? Let's consider some more interesting facts to determine if a long pass code is needed to protect an Android device.
NIST passcode guidelines: A shift in perspective
What does the National Institute of Standards and Technology (NIST) have to say?
The general password guidance from the latest version of SP 800-63b *(2) are listed below:
- Pass code Length: Minimum 8 digits
- Complexity (Special characters, uppercase, lowercase, number): No longer required
- Pass code hints: Do not allow
- Simple or known pass codes: Do not allow
- Periodic pass code changes (every 90 days, etc.): Not required. Only force changes when a known compromise is detected.
- SMS for MFA Codes: Do not use
- Pass code guess prevention (Throttling): Implement
NIST’s updated requirements are a result of technology advances that prevent guessing a pass code. As an example, 8 digits without special characters, upper and lower case, and pass code changing requirements are no longer recommended. An 8-digit pass code of non-repeating numbers is now sufficient to provide very strong protection. On Android we actually changed our PASSWORD_COMPLEXITY_HIGH to 6 digits back in Android 12. Let's explore this a little more.
Rate limiting and password guessing
Android implements a very strong default rate-limiting capability, which imposes increasing delays after the 5th failed login attempt, culminating in a 24-hour lockout after 100 attempts. The benefit to a managed device is that Android Enterprise can limit the attempts to a specific number before a device wipe is triggered automatically. This helps prevent access to personal and company data.
Assuming that an Android device is properly managed with a limited number of failed pass code attempts, let's say 10 tries, enforcing a device wipe by policy renders an attack mostly infeasible. Even the latest version of the password-guessing USB tool, rubber ducky, is ineffective.
Now, let's explore a simplified explanation of what a hash is in this context. Imagine your pass code to unlock your Android device is "019283". Android has an "algorithm machine" (called a hash function, or algorithm such as SHA256) that takes that password and generates a unique string of characters that represents that specific data, such as "a5f4g6h7j8k9l0". This is the hash of your password. It looks nothing like your original password, making it virtually impossible to figure out your lock screen pass code "019283" just by looking at the hash. Additionally, reversing the hashing calculations is infeasible and the algorithms are created in such a way as to protect against a reversing calculation.
Now, every time you try to unlock your device, Android securely feeds what you type into the unlock prompt and puts it through the same hashing algorithm. If the resulting hash matches what is stored in secure hardware on the device, then Android knows you've entered the correct password and it unlocks. What is stored in secure hardware on Android is the hash of your pass code, not your pass code itself.
We have all seen the following image on social media, but it portrays incorrect data when it comes to Android. This table does not take into consideration that the attacker has successfully been able to capture the hash of the pass code. Extracting the hash of a pass code from a locked Android device's secure hardware is non-trivial and is extremely difficult, actually infeasible on Android.
Conclusion: Rethinking pass code complexity for Android
In conclusion, it is important to note that I have only covered a small portion of a very complicated topic that involves encryption, key storage, hashing, and rate-limiting in Android kernel and services. While anything is potentially possible, the reality of exfiltrating a hash from secure hardware is really not feasible or practical. Requiring a pass code that is long and complicated is not a factor in 2025 on Android. With the proper management policies, guessing a pass code to unlock a stolen or lost device should not be a concern any longer. Have a look at what your EMM provider options are when setting a pass code requirement and consider how you can make the user experience for your users better by not having to enforce long complex pass codes, it just frustrates users.
*(1) Android Security Model: https://arxiv.org/pdf/1904.05572
*(2) https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-63b.pdf
