Category: Process
My new Android phone, a Motorola One Hyper, which I wrote about a couple of weeks ago, came out of the box with Android 10.
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 constantLockPatternUtils.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 |
|---|---|
| (empty string) | e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 |
| x | 2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881 |
| Chunky bacon! | f0abf4f096ac8fa00b74dbcee6d24c18cfd8ab5409d7867c9767257d78427760 |
| 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.
For the past four weeks, I’ve been spending over eight hours a day in a classroom in Ybor City, as a student in the inaugural cohort of UC Baseline, the cybersecurity training program offered by Tampa Bay’s security guild, The Undercroft.
We’ve taken the following courses under the tutelage of these instructors:
| Course | Instructor |
|---|---|
| Hardware 101 (5 days) |
Tremere |
| Networking 101 (5 days) |
TreyCraf7 |
| Linux 101 (3 days) |
Cochise |
| Windows 101 (2 days) |
Turtle |
| Infosec 101 (5 days) |
KobyBeefcake TheCleverShark |
There’s just one course left in the program: Python 101, which starts today! Considering that I’ve just come from teaching a Python course to beginners, I suspect that the instructors will have me:
- Help instruct my fellow students,
- Take on some harder Python programming assignments, or
- Both (I suspect that this will be the case).
The Python 101 course will run from Monday to Wednesday. After that comes…
…the virtual job fair. The Undercroft will set up online interviews between UC Baseline students/Undercroft guild members and representatives from Tampa Bay security and security-adjacent companies looking to hire. I see some resume editing and LinkedIn profile polishing in my near future.
Friday will be devoted to graduation rituals, which include a solo Capture the Flag competition and a grad barbecue (socially distanced, of course — they’ve got a nice courtyard).
I’m looking forward to the week!
You really should listen to the “egineering” team, and it wouldn’t hurt for some “egineers” to work on their communications and sales skills.
We’re on the back half of Week 3 of UC Baseline, the cybersecurity training program being given by The Undercroft, Tampa Bay’s cybersecurity guild and security-focused coworking space. We just finished three days of Linux 101, which was mostly an intro to command-line Linux, and now it’s time for two days of Windows from a security point of view.
I’m the lucky recipient of a UC Baseline scholarship (I wrote about the scholarship opportunity and then landing it a few weeks back), and I figured that I might as well use my COVID-19 downtime productively by spending five-ish weeks participating in the program.
From the fall of 2008 to the spring of 2011, I ate, slept, and breathed Windows — that’s when I was a developer evangelist for Microsoft Canada. I like to think that I was pretty good at it — good enough that the looney-tunes site TechRights.org saw me as enough of a threat to run a hit piece containing this image:
Since leaving Microsoft, I’ve stayed pretty much outside the Windows world. I call it “time off for good behavior”. I took it to the point that immediately after handing in my blue badge, I drove straight to the store and bought my first iPhone — and remember, I was a designated Windows Phone champ:
This part of the program is being taught by Michael “Turtle” Dorsey, and it’s a great refresher for a lot of material that I haven’t covered in a good long time, since none of my machines runs Windows at the moment (for the class, I’m running Windows 10 in VMWare on my primary Linux laptop).
The class opened with this slide, which I think bodes very well:
Here’s my daily view for seven hours a day for the next little while, as I’m part of the inaugural cohort of UC Baseline, the 5-week cybersecurity training program from Tampa bay’s security guild, The Undercroft:
Last week was devoted entirely to the “Hardware 101” part of the program. Here’s a video summary of what happened that week, and Yours Truly’s in a fair bit of it:
This week is “Networking 101”, which is all about how the bits gets transferred across wires and air to our hardware.
One of the exercises is making our own Ethernet cables. I can do it — just, very, very slowly…
We spent a good chunk of time setting up virtual LANs on our individually-assigned Cisco Catalyst 3750 programmable 48-port switches (alas, we don’t get to keep them), hooking up our Raspberry Pi 4 boxes (which we do get to keep) to them, and wiring our VLANs together via trunks:
It’s a strange world, where IOS doesn’t Apple’s refer to “iPhone Operating System” — part of my usual stomping grounds as a developer — but in the world of network administration, it’s Cisco’s Internetwork Operating System:
This is way outside my normal experience with networking, which I do at the application level, where I deal with data structures like arrays, dictionaries, base64-encoded data, and maybe the occasional data stream. This is the world of packets, frames, switching, and routing. I would still probably ruin a server room if left in charge of it, but after this course, I’d ruin it less.
I do have a refreshed generalized concept of what happens at the lower levels of the network, and that’s the important thing for me and the sort of work that I do.
It’s Monday, July 27th, which means that I’ve completed the Hardware 101 portion of the 5-week UC Baseline cybersecurity training program offered by Tampa Bay’s security guild, The Undercroft! Here’s a quick rundown of what I’ve posted so far about my experiences…
- Joey’s Bizarre Adventure (or: I’m in The Undercroft’s “UC Baseline” cybersecurity education program!)
- Why I’m excited about learning cybersecurity at The Undercroft
- Scenes from Day 1 of the “UC Baseline” cybersecurity program at The Undercroft
- Scenes from Day 2 of the “UC Baseline” cybersecurity program at The Undercroft
- Scenes from Day 3 of the “UC Baseline” cybersecurity program at The Undercroft
- Supplementary UC Baseline notes #1: The connection between binary and hexadecimal numbers
- Scenes from Days 4 and 5 of the “UC Baseline” cybersecurity program at The Undercroft
We’re now on week 2, which means it’s time to move to the next module…
It’s time for Networking 101, which takes up the next five days! This should be fun.
In anticipation of this week’s lectures, I thought I’d repost these two “cats and networking” pics…
