…go check your drawers. I just opened the drawer on my right-side desk and this is what I saw:
And these are the ones that aren’t being used to charge phones, iPads, Apple watches, or drive other USB-powered things including my videochat lighting rig.
You probably have lots of them around your place as well.
It works quite well — and better than I expected. While it’s light and takes up little space once collapsed, it’s a little too flimsy for someone who needs on-the-go lighting.
However, if you plan on keeping the rig in just one place and not travel with it, it’s a good setup for your video chats, meetings, interviews, classes, and so on. Check it out on Amazon.
The lights worked well for last night’s class and the previous week’s tech interview. I’ll write more about how the interview went soon.
I need to look up this grill to see what its embedded controller does. Aside from…
reporting its current settings and temperature, and
some limited ability to control it remotely (very limited, if at all — the computers in IoT devices are cheap and insecure, and attackers can cause all sorts of mischief with a networked propane tank)…
…what else does it do that needs an update, never mind an update big enough to interfere with cooking?
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:
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:
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.
In my opinion, when it comes to getting the best bang and build quality for the buck on an Android phone, check out Motorola’s phones. Lenovo — the same company who took Right now, they’ve got discounts on many of their mobiles, including $100 off any of the Motorola One family — the Action, the Zoom, and the one I got: the Hyper.
With the discount, the unlocked Hyper goes for US$299 when purchased directly from Motorola. That’s a pretty good price for an Android phone with mid-level specs.
Released on January 22, 2020, the Hyper features the Qualcomm Snapdragon 675 chipset, which was released in October 2018. This chipset features 8 cores:
Here’s a quick video review of this chipset from Android Authority’s Gary Sims:
As a point of reference, this chipset is also used in Samsung’s Galaxy A70, A60, and M40, and LG’s Q70.
This chipset puts the Moto One Hyper firmly in the middle of the road of current Android offerings, making it a reasonably representative device for an indie Android developer/article author like Yours Truly.
The phone’s “Hyper” name is a reference to its “hyper charging” — high-speed charging thanks to its ability to take a higher level of power during the charging process. It comes with an 18 watt charger (the same level of power provided by the current iPad Pro and iPhone 11 chargers), but if you have a 45 watt charger handy, the phone’s 4,000 mAh battery will charge in just over 10 minutes.
The phone also comes with the usual literature and SIM extraction pin:
There is one additional goodie that I didn’t expect: a clear, flexible, rubber-like plastic case. It’s nothing fancy, but it was still a nice surprise.
I’ll post more details about the phone as I use it and start doing development work (native stuff in Kotlin, as well as some cross-platform work in Flutter, and maybe even Kivy).
Day 4 of the Hardware 101 component of the UC Baseline cybersecurity program was all about security for the enterprise, which naturally included topics such as servers. Not everyone in the class has had the opportunity to tour a server room or data center, and this was their chance to see these machines up close.
Unlike the previous days, we did not attempt to dismantle and then reassemble the servers — this was a “look, but don’t touch” sort of lesson.
We also had a guest lecturer who gave us a pretty thorough walkthrough of the sorts of things involved in an enterprise server/data center setup, some of which went way over my head. I don’t see a sysadmin/system architect role in my future, but it might not hurt for me to do some supplementary reading on this topic.
Day 5 was the final day of Hardware 101 and started with something that I’ve always been terrible at: Making networking cables.
Arrrrgh.
We also spent some time looking over all sorts of intrusion devices, such as the incredibly cute “Pwnagotchi”, a Raspberry Pi Zero-based device that “listens” to wifi chatter to feed its machine learning program in order to figure out wifi passwords.
It uses an e-paper screen, which is quite legible and consumes little power.
It’s incredibly small:
Here’s a Pwnagotchi beside a U.S. quarter for size reference:
A great way to steal information to gain access to people’s accounts and systems is to set up a fake wifi hotspot at a place that offers free wifi, such as Starbucks. That’s what the Wifi Pineapple is for — people connect to it, thinking they’re connecting to Starbucks wifi. You route their signals through to the real Starbucks wifi, but you’re the go-between, and can “see” everything that your marks are sending on the internet: the data they’re passing back and forth, including stuff like user IDs and passwords:
It sends out a signal that causes devices currently connected to wifi to disconnect. You could use it in tandem with a Wifi Pineapple to force people to disconnect from the real wifi and then connect to the Pineapple instead, enabling you to read their internet communications.
If you really want to “sniff” all the wifi traffic in the room, you’ll want one of these — a high-gain antenna system hooked to a network interface controller (NIC) that reads signals in “promiscuous mode”, a capability that’s disabled in most NICs. In promiscuous mode, you can capture all wifi traffic instead of the bits of data that you’re authorized to receive. It’s a good network diagnostics tool — and it’s also useful for getting up to no good:
And finally, the Shark Jack. Plug it into someone’s network, either via the ethernet jack or USB, and it will execute scripts to get a map of the network or even deliver a payload somewhere onto the system:
It’s basically a real-world version of the device that Tony Stark slipped onto the command console of the SHIELD helicarrier in the first Avengers movie (it’s at the 0:44 mark):
I may have to invest in one of those bad boys. For research purposes, you understand.
We also had a guest lecturer who delivered a very thorough and informative presentation on getting started in cybersecurity. I’ll have to post notes on it later: