When it came time to set the passcode to unlock the phone, I found out that the longest device unlock passcode that even the most recent version of Android will accept is 16 characters. That was the case five years ago, and it’s still the case today.
Android’s “Choose Lock Password” screen is part of AOSP (Android Open Source Project), which means that its source code is easy to find online. It’s ChooseLockPassword.java, and the limitation is a constant defined in a class named
ChooseLockPasswordFragment, which defines the portion of the screen where you enter a new passcode.
Here are the lines from that class that define passcode requirements and limitations:
private int mPasswordMinLength = LockPatternUtils.MIN_LOCK_PASSWORD_SIZE; private int mPasswordMaxLength = 16; private int mPasswordMinLetters = 0; private int mPasswordMinUpperCase = 0; private int mPasswordMinLowerCase = 0; private int mPasswordMinSymbols = 0; private int mPasswordMinNumeric = 0; private int mPasswordMinNonLetter = 0;
Note the values assigned to these variables. It turns out that there are only two constraints on Android passcodes that are currently in effect:
- The minimum length, stored in
mPasswordMinLength, which is set to the value stored in the constant
LockPatternUtils.MIN_LOCK_PASSWORD_SIZE. This is currently set to 6.
- The maximum length, stored in
mPasswordMaxLength, which is set to 16.
As you might have inferred from the other variable names, there may eventually be other constraints on passcodes — namely, minimums for the number of letters, uppercase letters, lowercase letters, symbol characters, numeric characters, and non-letter characters — but they’re currently not in effect.
Why 16 characters?
16 is a power of 2, and to borrow a line from Snow Crash, powers of 2 are numbers that a programmer would recognize “more readily than his own mother’s date of birth”. This might lead you to believe that 16 characters would be some kind of technical limit or requirement, but…
…Android (and in fact, every current non-homemade operating system) doesn’t store things like passcodes and passwords as-is. Instead, it stores the hashes of those passcodes and passwords. The magic of hash functions is that no matter how short or long the text you feed into them, their output is always the same fixed size (and a relatively compact size, too).
For example, consider SHA-256, from the SHA-2 family of hash functions:
|String value||Its SHA-256 hash|
|I have come here to chew bubblegum and kick ass… and I’m all out of bubblegum!||3457314d966ef8d8c66ee00ffbc46c923d1c01adb39723f41ab027012d30f7fd|
|(The full text of T.S. Eliot’s The Love Song of J. Alfred Prufrock)||569704de8d4a61d5f856ecbd00430cfe70edd0b4f2ecbbc0196eda5622ba71ab|
No matter the length of the input text, the output of the SHA-256 function is always the same length: 64 characters, each one a hexadecimal digit.
Under the 16-character limit, the password will always be shorter than the hash that actually gets stored! There’s also the fact that in a time when storage is measured in gigabytes, we could store a hash that was thousands of characters long and not even notice.
My guess is that the Android passcode size limit of 16 characters is purely arbitrary. Perhaps they thought that 16-character passwords like the ones below were the longest that anyone would want to memorize:
TvsV@PA9UNa$yvNN sDrgjwN#Vc^pmjL4 argmdKAP?!Gzh9mG <Wea2CKufNk+UuU8 EmNv%LN9w4T.sc76
The problem is that it doesn’t account for (theoretically) more secure yet easier to remember passwords of the “correct horse battery staple” method described in the webcomic xkcd, which can easily make passwords longer than 16 characters:
Based on usability factors, there is a point after which a password is just too long, but it’s not 16 characters. I think that iOS’ 37-character limit is more suitable.