Categories
Hardware Process

Android *still* has a maximum passcode length of 16 characters

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:

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
(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:

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:

Tap the comic to read the original.

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.

Categories
Process Tampa Bay What I’m Up To

The final lap of UC Baseline: Python!

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!

 

Categories
Humor Process

We’ve all been the dog

You really should listen to the “egineering” team, and it wouldn’t hurt for some “egineers” to work on their communications and sales skills.

Categories
Process Tampa Bay What I’m Up To

UC Baseline: Windows security

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.

Scenes from UC Baseline’s “Linux 101” class. Tap to see at full size.

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.

Tap the photo to see my article from 2009 associated with this photo.

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:

Categories
Process Tampa Bay What I’m Up To

Scenes from UC Baseline’s “Networking 101” class

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:

Tap to see at full size.

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…

Tap to see at full size.

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:

Tap to see at full size.

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:

Tap to see at full size.

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.

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.

Tap to see at full size.
Categories
Process Programming

Supplementary UC Baseline notes #2: The easiest way to explain public key cryptography for sending secret messages and signing them

I’m often asked about how public-key cryptography (a.k.a. asymmetric cryptography) works. The concept of private keys and public keys isn’t an intuitive one. A couple of years back, I spent some time trying to come up with an analogy that was layperson-friendly and memorable.

Photo: The Undercroft sign, featuring the Undercroft’s “mascot” — a stag standing upright in a suit, leaning jauntily against an umbrella, walking stick-style.Regular readers of this blog are probably aware that I’m in week two of a five-week cybersecurity course called UC Baseline offered by Tampa Bay’s security guild, The Undercroft. The topic of generating keys for SSH came up, and not all of us are familiar with public key cryptography. This article should help!

The special box

Imagine a box with a special lock, as pictured below:

The lock has three positions:

  1. When the lock is turned to the “9:00” position, the box is locked, and its contents are inaccessible.
  2. When the lock is turned to the “12:00” position, the box is unlocked, which means you can open it and view its contents.
  3. When the lock is turned to the “3:00” position, the box is locked, and its contents are inaccessible.

The lock’s position can be changed by two kinds of keys. The first type of key belongs to the owner of the box, and is thus called the private key:

The private key fits the lock, but it has a special limitation: it can only turn the lock clockwise — from 9:00 to 12:00, or from 12:00 to 3:00. It doesn’t turn counter-clockwise.

There’s only one copy of the private key, and as the owner of the box, you hold onto it.

There’s a second kind of key. You may have already guessed that it’s called the public key:

Like the private key, the public key also fits the lock, and it also has a special limitation — but a different one: it can only turn the lock counter-clockwise — from 3:00 to 12:00, or from 12:00 to 9:00. It doesn’t turn clockwise.

Unlike the private key, you give copies of the public key freely to other people. This lets them communicate with you.

Using the box and keys, two different things are possible:

  1. People can send you secret messages. This is done with encryption.
  2. You can send messages to people with proof that it was you who sent the message. This is done with digital signatures.

Sending secret messages with encryption

The idea behind sending secret messages is straightforward: you take the message and encrypt it (that is, scramble it so that it’s incomprehensible to other people), and then send it. The receiver gets the message, decrypts it (that is, performs the inverse of the operation that scrambled the message), restoring it to its original form and making it readable.

Think of encrypting the message as putting it in the special box and locking it. Think of decrypting the message as unlocking the box.

If you wanted to send a message to me, you’d use one of my boxes. Since it’s one of my boxes, I would have the private key for it, and I would have given you one of my public keys.

To send me the message so that only I would be able to read it, you’d put the message into the box and then lock it with my public key. Remember, the unlocked position is at 12:00, and public keys only turn counter-clockwise. When you lock it, you change the lock to the 9:00 position:

Once the box is locked, you’d ship it to me.

In order to read your secret message, I’d unlock the box using my private key. Remember, the lock is currently at the 9:00 position (locked), the unlocked position is at 12:00, and private keys only turn clockwise. When I unlock it, I return the lock to the 12:00 position:

With the box unlocked, I can now read the message you sent me.

Proving that I was the one who sent the message using a digital signature

I can also use one of my boxes to sign my messages in such a way that you know that they’re definitely from me and not some troll pretending to be me.

If I wanted to send you a message that was guaranteed to be from me, I’d use one of my boxes.

To send you a message in a way that proved that only I could have sent it, I’d put the message into the box and lock it with my private key. Remember, the unlocked position is at 12:00, and private keys only turn clockwise. When I lock it, you change the lock to the 3:00 position:

Once the box is locked, I’d ship it to you.

In order to confirm that the message was sent by me, you’d unlock the box using the public key I gave you. Remember, the  lock is currently at the 3:00 position (locked), the unlocked position is at 12:00, and public keys only turn counter-clockwise. When you unlock it, you return the lock to the 12:00 position:

You can rest assured that I sent the message, because in the digital signature scenario, only my private key could’ve locked the box that you unlocked with my public key.

It’s all math

You may have to remind people that the box isn’t actually a box, the things that we call the private key and public key are just really large numbers, and that encryption and digital signing are just some fancy math operations that are performed on your message (which is really just a bunch of numbers) using the private and public keys.

I’ll write up a layperson-friendly description of how the math in public-key crypto works, but in the meantime, if someone’s asking you to explain it, send them to the EFF’s article, A Deep Dive on End-to-End Encryption: How Do Public Key Encryption Systems Work?

Credit where credit is due

I found the original “special box” analogy put together by Panayotis Vryonis (pictured to the right), in his article titled Public-key cryptography for non-geeks. He came up with an analogy that treated asymmetric crypto as a box with a special lock and special keys, and it seemed to do the job nicely, and I wrote about it in this post back in June 2017.

Analogies often have limits, and it wasn’t long before my computer science prof, Dr. Robin Dawes (pictured to the right), pointed out a flaw in Vryonis’ analogy. With his help, combined with a suggestion from Matthew Ernest, I came up with a tweak, resulting in the analogy shown above. Thanks to all of them for their invaluable help!

Categories
Process Tampa Bay What I’m Up To

The UC Baseline cybersecurity course at The Undercroft — Begin week 2: Networking 101!

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…

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…

Photo: A stack of seven interlocking baskets, each with a cat. From top to bottom, the cats are labeled: Application, presentation, session, transport, network, data link, and phyiscal.
The OSI network model, illustrated with cats.
Photo: A stack of four boxes, each with a cat in it. The cats are labeled, from top to bottom: Application, transport, internet, and network interface.
The TCP/IP layers.