Author: Dave

I don’t think I wrote anything last week, which is something I feel low-grade anxiety about. One of the things I’ve been trying to do as some sort of Psychic-Goat-Sacrifice-To-The-Apocalypse-Gods is to knock out a few words of wisdom now and again so that I can tell anyone who cares that I’m trying to put some positive energy out in the world or somesuch. It’s a lie, of course; I’m just writing things down because I have more free time to bang my head against problems these days, and if I don’t record that stuff then I’ll just forget.

I’m good at forgetting things. Not maybe-I-should-seek-professional-help good, but definitely in pro-am territory. Happily, technology has solutions for people like me, and those solutions tend to be the common-sense, regular solutions that I’ll cheerfully recommend to anybody who’ll pay me to have an opinion; keep your data safe and accessible, and back it up. A lot. Equally handily, there’s a relatively simple thing for doing that – a NAS. Specifically (in this case) a Synology DiskStation 220+, nestled discreetly in a bookshelf:

I love Synology DiskStations. They’re an excellent piece of kit, striking the line between full-featured and accessible, allowing you to do pretty much anything you want with data without making the process utterly incomprehensible. They’re the perfect $300-if-you-have-your-own-drives solution for the enterprising young IT consultant on the go, and while the latter part of that sentence seems unduly optimistic, the three hundred bucks part rather does the heavy lifting, value-wise.

The problem with having one of these in my office is that they don’t support WiFi, and the only internet I have in the office is WiFi, and there’s literally nothing that I can plug anything into to get internet via the customary physical route, i.e., a cable.

So, a problem. What I really needed was to find a way to bridge the wireless connection in the office (via Cox Wifi and their Captive Portal) to the Synology box, and at first blush this seemed pretty simple.

When you first sign a new device onto the Cox Hotsports Captive Portal (which I’m going to call “WiFi portal” from now on to save a lot of typing) it prompts you for your credentials, and once you’ve entered those you’re able to stay logged in to the network for as long as you might possibly want, because what the WiFi portal does is capture your MAC address, checks to see if it’s authorized to use the network, and then if not gives you a prompt for your username and password. If you have a web browser installed on your computer (which you do because otherwise I’d be intrigued to know how the hell you’re reading this) then most of this is done for you. But the Synology DiskStation has no web browser, and even if it had one it has no WiFi hardware that would allow it to connect to the WiFi network in the first place.

Oh dear.

So, I have no ability to use the Synology with WiFi, but I do have a number of large boxes filled with cables and assorted bits of networking gear of assorted vintages. Trawling through those boxes yielded one part of the answer in the form of an Apple Airport Express.

These are little puck-sized wireless boxes that were mostly designed to extend existing Apple Airport networks, but also did decent duty as simple routers that you could use to create wireless networks. One of the great things about them is that the built-in Airport Utility software in macOS gives you the option to Join A Wireless Network, which effectively turns the Airport Express into a little wireless bridge. In English: you select this option, choose a WiFi network to connect to, WiFi goes into the box, and internet comes out via a cable. Perfect. Except that there’s no web browser installed on the Airport Express so you can’t sign it into the WiFi portal, which was the same problem we had when we started.

Except no, it really isn’t. What’s happening when you use your web browser to sign into the WiFi portal is that – as I mentioned before – the first thing that happens in the process is that the portal looks at your MAC address and decides whether or not you’ve connected before. If you can tell the portal that the MAC address its looking at is one that it’s seen before then the portal will simply allow the device that bears that MAC address to connect to the network, no questions asked.

So, let’s start lying to the WiFi portal about who we really are. To do this we’re going to temporarily change the MAC address of your computer so that you can use it to connect to the WiFi portal, and then once that’s done whatever device that actually owns that MAC address will be able to connect. This is done via the command line with the following command: sudo ifconfig en0 ether 00:11:22:33:44:55 (where 00:11:22:33:44:55 equals an actual MAC address and not a lazy placeholder). You’re going to do this more than once, so if you’re like me and enjoy tinkering with your whole Terminal environment then you can add it as an alias to your .zprofile, thus:

alias mac='sudo ifconfig en0 ether'

The first step is to make sure that the Airport Express is able to join the WiFi network. To do that we’ll have to find the MAC address of the Airport Express, which is easy if you have the original box that the thing came with but not so easy if you dug the infernal gadget out of a large, dusty cardboard box of junk and knotted cables that resides in your haunted garage. Happily, there’s an undocumented way of finding the MAC address of an Airport router; simply hold down the Option key on the keyboard while clicking on the icon for the router in the Airport Utility, and instead of the default view (this):

…you get this:

The next step is to take the MAC address of the Wi-Fi interface on the Airport Express and then clone that onto your computer. I chose the 5GHz MAC address, but you may have to do either the 2.4GHz or the 5GHz or both depending on the WiFi portal you’re connecting to. The first thing to do is to connect to the WiFi portal normally, then open up the Terminal and either use the handy alias from earlier on or go ahead and type in sudo ifconfig en0 ether followed by the MAC address of the appropriate wireless interface that you got from the Airport Utility. After a moment you’ll be prompted to sign into the WiFi portal again, and once you’ve done so then that MAC address will then be accepted and useable. Reboot your computer to reset the MAC address to it’s original state. No, I don’t like rebooting either. Yes, you should probably do it.

Once you’re back up and running, turn off WiFi and connect an ethernet cable to the network port on the back of the Airport Express. All things being equal you’ll now be able to connect to the internet. If not then go back a step or two and try the MAC address for the other interface on the Airport Express (2.4GHz or 5Ghz).

Next, you’ll need to go snag the MAC address of your Synology NAS. This is a lot easier; simply open the Control Panel on your DiskStation, click on Info Center, and then the Network tab, thus:

Again, do the same trick: connect your computer to the WiFi portal, fire up Terminal and enter sudo ifconfig en0 ether followed by the MAC address of the DiskStation. Reboot your computer, then shut down the DiskStation, connect it to the network port of your Airport Express, then fire it up again.

This has, I must say, worked flawlessly, but there are caveats. For one thing, there’s no guarantee that you’ll retain the same IP address if there’s, say, a power outage, so if you’re planning on connecting to the Synology remotely then you’d better enable the QuickConnect feature and/or sign the thing into some kind of DDNS (I like dyndns.org, but the Synology supports a lot of options in that space). Finally, I’d encourage the use of Synology Drive to keep data synced between your Synology and your computer, as having the thing safely store and serve important things to your computer is rather the whole point of the exercise, and this makes that considerably easier…

Apple’s Configurator application (now Apple Configurator 2 because it’s an irrefutable rule that adding more numbers to things makes them intrinsically better) is an essential tool in the enterprising Mac IT persons’ toolbox. Initially it was designed as the way to build profiles that you’d put onto iPads, but it’s increasingly become a sort of multitool that you can use to build configuration profiles on an ad hoc basis, and even to resuscitate dead T2-enabled Macs.

It’s great, except that (as is the way of things) updates not only introduce fixes but occasionally add new and interesting problems. More specifically (and the reason I’m writing all of this nonsense) is that I spent a frustrating hour or two this week trying to work out why in the name of all that’s good and true Apple would see fit to remove the Shared Secret field from the VPN configuration portion of the Configurator. I’d been building config profiles to post on an intranet for a client, so imagine my surprise when instead of seeing a field where I could pop in the Shared Secret I saw… well. Nothing. Nothing at all. And that was a problem.

So, a problem. But every problem is a solution waiting to be discovered, and happily enough this one is the most enjoyable kind of head-scratcher; the kind that can be solved with a modicum of common sense and only minor trickery. Happier yet, the .config files generated by Apple Configurator are basically just Property List files that can be opened by a text editor and tweaked. It’s just a case of knowing what tweaks to make.

First, figuring out what to add to the .config file. The mysterious removal of the Shared Secret field showed up with the most recent version of Apple Configurator (2.12.1), but prior versions allowed you to set that configuration, so digging out an older .config file and opening it allows you to see what’s different, thus:

The older .config file (on the right), includes this text:

<key>IPSec</key>
<dict>
<key>AuthenticationMethod</key>
<string>SharedSecret</string>
<key>PromptForVPNPIN</key>
<false/>
<key>OnDemandEnabled</key>
<integer>0</integer>
<key>SharedSecret</key>
<data> encoded-shared-secret </data>
</dict>

So, copying that into the new, non-shared-secreted .config file should theoretically add the shared secret into the configuration. Great! There’s just one more piece of the puzzle – encoding the shared secret itself. There are websites out there that will allow you plug in text and covert it to Base64, but it’s simple enough to do it via the Terminal. Let’s say your shared secret is… well, let’s just call it sharedsecretpassword:

echo -n 'sharedsecretpassword' | base64

Which will translate sharedsecretpassword to c2hhcmVkc2VjcmV0cGFzc3dvcmQ=

Edit the .config file thus:

<key>IPSec</key>
<dict>
<key>AuthenticationMethod</key>
<string>SharedSecret</string>
<key>PromptForVPNPIN</key>
<false/>
<key>OnDemandEnabled</key>
<integer>0</integer>
<key>SharedSecret</key>
<data> c2hhcmVkc2VjcmV0cGFzc3dvcmQ= </data>
</dict>

…hit “Save”, et voila. You’ll now have a functional VPN config file that can be deployed with the shared secret (even though Apple Configurator doesn’t seem to want you to).

One thing that’s become abundantly apparent during this long, disease-vectored sequester we all seem to be on is that this time represents a wonderful opportunity to get the kind of frank, honest feedback about ourselves that only our nearest and dearest can bestow. And when I mean “bestow” I mean “crush all illusions about how you are perceived by the people who are around you the most.”

Two things that I’m being educated on of late are that I am not as amusing as I think and I am I’m also fussy about things in ways that are frequently incompatible with other people. Not in big, interesting ways (I mean, I’m not a monster), but in small, frustrating ways. I like my coffee very specifically made from one very specific coffee shop that my coffee friends look down on as being The Bad Coffee Shop, and will ruthlessly subvert and hijack plans so that said Bad Coffee Shop ends up being our ultimate destination. Being masked and gloved and PPE’d and socially distanced hasn’t changed that – it’s just made it more apparent and troublesome.

It’s nothing personal. It’s just that I know that the Bad Coffee Shop is secretly the Best Coffee Shop. I’m capable of sustaining the position that my way is really the only correct way, even while cheerfully acknowledging that said position is, in fact, tangibly incorrect. I call it the “Grand Irrefutable Theory of Self Deception™” because it’s my flaw and the very least I should be able to do is name the wretched thing.

Take Finder views, for example. I like them when they look like this:

…because the Column view is clearly superior, and everyone should look at their files that way. It’s so much better! You can zip up and down directory hierarchies quickly and simply! I’m right!

Not everyone feels that way – mostly because of the afore-mentioned “Grand Irrefutable Theory of” etc. Some people (philistines and malcontents in the main) prefer the old fashioned icon view, thus:

It’s unfortunate that some of us have to work with these poor, misguided folks, but there’s no reason why you should have to put up with their ham-fisted insanity when there’s a better way.

Your Mac knows how you like your files positioned and your preferred view and retains that information in tiny, invisible files that it creates in each directory you access. These files are .DS_Store files, where “DS” stands for “Desktop Services”. They’re difficult to open and inspect, but once you crack one open and took a look it’s clear that they contain information about the window’s position on screen, the window view, icon size, relative position inside the window, the status and visibility of the window bar icons, the sidebar, backgrounds, snap-to-grid, stacks and so on and so forth. Whenever you change view or move something around those changes are update in the .DS_Store file so that next time you open that window it appears exactly the way you left it.

Which is great if it’s your computer, but not so great if it’s a share on a server that is also accessed by nincompoops and dunderheaded ne’er-do-wells who prefer icon view for some insane, incalculable reason, because the moment they open that window they see your (superb, intelligent, morally-superior) layout and not their stupid mess. And then they change it to reflect the way they like to do things and then when you open it again it’s all awful and you have to step away and go lie down in a dark, cool room for a while.

Happily, there’s a way to tell your computer to not make those .DS_Store files, which locks in as default the nonsensical, asinine way that your idiot colleagues and co-workers like to use their stuff – simply fire up the Terminal and enter the following:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Once you’ve done that then your colleagues will be able to set up the way they view those files according to whatever the inchoate voices in their heads tell them to, and you won’t have to put up with that. Instead, the next time that you access that folder you’ll be able to set the view appropriately. Like the misunderstood genius that you are. Right? Right.

Here’s fun. Back in the Halcyon Days of 1982 one Richard McClintock made an interesting discovery – the origins of Lorem Ipsum (you know, the filler text you occasionally find padding out web pages and anywhere requiring placeholder material), thus:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Mr McClintock – in a letter to Before & After magazine in 1994 – pointed out that the full passage was originally an excerpt from Cicero’s ethical treatise “The Extremes of Good And Evil” which was the number one hot bestseller of 45 B.C (probably). At some point in the sixteenth century – so the theory goes – an annoyed typesetter threw Cicero’s text into his press along with some filler, nonsense words in order to pad out enough text to mockup different types and fonts for a book, and then due to tradition and institutional laziness it stuck around for the next five hundred years and is still popping up today whenever You Just Need To Put Something There.

The thing is that it turns out there’s enormous value in having something on tap that you can use as a quick, reliable placeholder. It makes your life easier, you don’t have to constantly reinvent the wheel and go find new material to put into place, and it’s widely recognized for what it is; not actual content, but something to fill empty space until actual content can be substituted and you can go back to work.

But this isn’t my typeset blog; this is my macOS IT blog. And I’m not here to talk about placeholder text; I’m here to talk about placeholder processes. Hmm? What’s that? Well, I’m glad you asked. Meet kernel_task – the Lorem Ipsum of the macOS world.

When your Mac is running something particularly demanding then the chances are that whatever the “something” is will be using a lot of the CPU. You can see this in the Activity Monitor.app – sorting by % CPU will show you which apps or services are using the most system resources. The more CPU a process or program uses the more power it consumes, and the more heat it generates. And that’s fine; well-engineered computers and devices are built with heat tolerance and dissipation in mind (well, most are. I had a colleague who blew through three – yes, three – cheap PC laptops that all melted while my slightly more expensive PowerBook kept on ticking in support of the Sam Vimes Theory of Boots). Still, there are times and circumstances where it pays to have a way to throttle the activity of your computer to allow it to cool down – and this is that kernel_task does.

Simply put, it’s a process that the computer fires up whenever it decides that it’s running too hot, specifically to block other processes and applications from using the processor. Google Chrome wants to use a hundred percent of your CPU? Sorry; it’ll have to wait. kernel_task is using that right now, except all it’s doing is twiddling its thumbs, waiting for the computer to cool down while the fans run. Once things are back to an acceptable operating temperature then kernel_task frees up more and more resources until finally it all but disappears…

It probably says something about mildly disturbing about my character that I’m borderline obsessed with online security. That might sound like a setup for some kind of epic humble-brag (“I suppose my greatest weakness is that I’m too dedicated to doing this thing that is awesome” etc), but honestly, if you want to distract me from anything useful then start talking to me about IT security and I’ll break out the grey beard and pocket protector and suddenly turn from the dapper bon vivant my clients know and love into an utter, utter adenoidal bore.

Freudian theory would dictate that I’m clearly hiding some terrible, dark set of secrets that make me preternaturally concerned with discovery and deceit, but I’m frankly baffled as to what they could be. I mean, my greatest flaws are that I lie about going to the gym, play Dungeons and Dragons over Zoom with other nerds on Thursday nights and my secret addiction is about thirty-five dollars a week in espresso and not opioids or persons of negotiable value. It’s distressingly low-stakes stuff. My midlife crises are of the existential variety and not the acting-out type. I’m… well. I’m pretty dull.

And it’s probably that inherent, unrelenting dullness that makes me interested in security, simply because a lot of it so cerebral and complex, and scratches all the itches that speak to philately and not philandery. Still, there are nuances that are potentially interesting to people who don’t lick their chops when they hear about end-to-end encryption and start banging on about said subject while their loved ones roll their eyes at the dinner table and exchange just-let-him-get-it-out-of-his-system looks, and those nuances also happily seem to fall into the category of things-I’m-sometimes-asked-about, and so here we are in paragraph three and I’m about to talk about masking your IP address. I’ll try and make this painless.

Practicing safe browsing is common sense in this day and age. It’s not simply a case of hiding your location and details from the authorities out of (probably justifiable) paranoia about The Man nor is it about using anonymity to go and do illegal things on the internet. Okay, it’s partly about those things, but it’s more about the value of privacy in an age where the commoditization of the individual has become the chief form of currency. Advertisers track you, build profiles of you, push products and content at you, increasingly crafting narratives and information designed to feed their ideas of who you are economically and demographically. Andrew Lewis put it concisely into this quote: “If you are not paying for it, you’re not the customer; you’re the product being sold.” It’s an unfortunate condition of using the internet, and it’s kind of gross. But there are simple, easy, legitimate ways to take yourself off the market.

VPNs and Proxies are a simple and effective way to mask your location and presence on the internet, and Tor is a technology that essentially uses an alternate network altogether. There are pros and cons to each.

A VPN creates a Virtual Private Network – an encrypted channel between you and the endpoint you’re accessing on the internet.

Pro: When you connect to a VPN you’re essentially telling your computer that it has a special network interface, and that when data is sent out via that interface it is encrypted and protected and – as far as the world is concerned – you’re actually at the end point. A prime use for VPNs is connecting from a remote location – coffee shop, airport, home – to an office network. You host a VPN at the office and connect to it remotely, and as soon as you do so then your office network thinks that you’re on its local network and in your office and not using the Shake Shack™ guest Wifi network in Irvine, CA. The sketchy guy at the table near the door can’t eavesdrop on the traffic going into and out of your computer, and you can access all the resources you have in the office (servers, printers etc) just as if you were actually on the office network – because in a very real sense, you are on the office network.

Con: VPNs don’t always work. Oh, sure, they mostly work just fine, but it’s entirely possible for VPN traffic to be blocked or throttled by ISPs and local networks – particularly if you’re running your own VPN out of your office/remote location. If you don’t run or roll your own and prefer to use a commercial VPN solution (you know, the kind you pay ten bucks a month for) then you need to read some fine print and do some research. Sure, any data you send to and from those VPN providers is securely encrypted, but there’s nothing preventing them from logging what you access on the internet once you’re connected to them. Some VPN providers will swear blind that they don’t keep logs, but that’s not always factually correct.

Proxies are much like VPNs in that traffic you send or receive goes is handled on your behalf by a third party.

Pro: Proxies are reasonably fast, and proxies are flexible; where a VPN sends everything out of your computer as encrypted traffic to a remote location, a proxy can be set up for a particular service or program. Want to use one proxy for web traffic on Safari and another for gaming? Fiddly, but doable. Also, proxies are relatively simple to set up and inexpensive.

Con: Proxies are not as fast as VPNs. And they do a miserable job of securing your data. That guy at Shake Shack™ might as well be like that kid John Ellison when you were in eighth grade who you had pass a note to Hannah Davis during math class to ask if she’ll go out with you. Yes, he’s going to be able to read everything, and No, she was never going to date you with that haircut.

Tor is the one I get asked about least. I think that’s because Tor doesn’t really use the internet as we know it; instead it routes traffic through multiple volunteer networks.

Pro: Tor is secure. Like, really, really secure. It’s less a product and more a system of stripping your data of identifying information, adding layers of encryption and then funneling your data through multiple networks. To use Tor you’ll need the Tor browser (based on Firefox).

Con: The Tor browser is great and allows you to use the Tor network, but on the other hand it’s not infallible. You have to trust the operator of the exit node you’re connected to, who can potentially track your information and activity. Additionally, the Tor browser only protects data on that browser – anything else sent out on your computer is something that your ISP can track, and additionally your ISP can see that you’re using Tor.

So, what does this all get you? Well, it’s clear that there are pros and cons to proxies, Tor and VPNs. But can you mix and match to get the best of all worlds?

Sort of. You can combine a Tor and a proxy by connecting to Tor via a proxy – which isn’t a great idea because then the connection between you and the Tor network goes through an unencrypted proxy. The other way round is marginally better – if you connect to a proxy through Tor then your traffic would end up finally exiting through a proxy and thus the ISP would have no proof that you were using Tor. But it’d be slow. Like, slow.

No, the better move is to combine VPN and Tor. Using those two together isn’t what you’d call fast, either. But if you’re using a VPN to encrypt your traffic to the Tor network then you’re getting the best of all possible worlds; route obfuscation and end-to-end-encryption. Your data is encrypted when it enters the Tor network and your origin IP address is likewise protected…

Right. Last time I wrote about how to configure your Mac to optionally use a Yubikey as a hardware authentication device – you plug the Yubikey in to a free USB port and you can then use the PIN for that key to log in to your user account – which is handy if you don’t want to have to mess around with your regular password. However, allowing it as an optional method of authentication isn’t the same thing as requiring it as a method of authentication. In other words, if you didn’t have your Yubikey handy then you could type in your password and still be able to use your computer, but maybe there are times and circumstances where you’d like to disable the ability to use a password entirely and substitute it with a Yubikey.

This isn’t as crazy as it seems. Gather around the fire, friends, and let me recount a tale from the long, long ago; a fragment from a distant time, a ghostly antiquity from the Turn Of The Century.

A long time ago I worked at a design/branding agency where I had the unenviable duty of acting as a sort of media archivist as well as general IT factotum. This translated to being the guy who – if you needed to pull a work file from an archived job from three years ago – knew where to find the DVD with the data burned onto it. (This was almost twenty years ago. Storage space was expensive and DVDs were cheap. It was a different time, whippersnapper!) I didn’t particularly enjoy this condition of my employ, but it was fine. We used an obscure media-tracking application that had been put into effect some years beforehand and was full of an enormous amount of data that we were stuck with – we tried a lot of abortive attempts to shunt the massive, proprietarily-created weird database that the application used into some kind of form that we could slap on the office intranet with no real effect, so I was stuck doing it by hand; now and again I’d have someone show up and give me a time and a project name and I’d go dig through the archive and pull out the data, and everyone would be happy. To a degree. Okay, all parties would be equally frustrated, but would at least be good-natured and mutually apologetic about it.

Except for one guy, who was kind of a jerk. He thought that this was a ridiculous arrangement – and while I agreed with this in both theory and practice I at least understood that you can’t cram two hundred gigabytes of data into a one hundred gigabyte RAID and that being as this was the case it a necessary evil that it took a few minutes to go dig up old work. He didn’t. And he didn’t like waiting for me to go find the data for him, so because he wasn’t long on confrontation and trying to be proactive he thought the logical first move was that he should try and break into my computer and go find the data for himself.

I don’t think it’s controversial to run the following opinion up the flagpole: This was a dick move. But he was pretty sneaky about it – it took me a while to figure this out, but as the IT guy I’d usually be one of the first people in the office each morning and there were plenty of times that I’d find him there already, in a vile mood, loitering around my office. Sometimes my desk was in disarray (inasmuch as that was possible considering I’d spent years perfecting the platonic ideal of disarray). Once or twice I caught him sitting at my desk with my computer turned on and at the login screen. Just waiting for me to get there, he’d say.

And then, one day, I went to fix… I don’t remember. Probably something to do with QuarkXpress (because it was twenty years ago and QuarkXpress broke so badly and so often that whole careers were made out of fixing the thing), but that’s not important. I was at his desk and saw, stuck on a post-it note, my login password for my computer. He’d been watching me type on the keyboard when I logged in and I think he’d piecemealed it together over time.

This stuck in my craw because it was my computer. As in, not the-computer-that-work-issued-me because all the budget went into gear for the design teams and the computer they gave me had some serious hardware defects, but my computer as in the-one-that-I-bought-with-my-own-money-and-kept-at-my-office-desk. Still, things being as they were, there was little I could do about this except be creative about it, so I was creative about it. For one thing, I changed all my passwords. For another, I put my boot volume on a fast external drive and took it home with me every night. With no operating system there was nothing for him to snoop on. Effective, but drastic, and horribly insecure because if something terrible had happened to that drive (lost, stolen, destroyed) it would have significantly impacted my job performance. Everything was backed up, but it would have cost some time to restore things to their former glory.

Still, while he was a fairly senior person in the company there was a lot of information on that drive that for one reason or another couldn’t live on a server share and also was not for his eyes – after all, as well as finding DVDs and fixing QuarkXpress I also supported the CEO and had a couple of projects I was working on for her on there that the rest of the rank and file should absolutely not know anything about.

(Sidebar: On the slim chance that the offending party might ever read this – you know who you are and I’m still mad about it.)

If there’d been a way to secure login to that computer with a token that I could have kept on a keychain – say, a Yubikey – then this would have been a considerably simpler problem to navigate. That guy could have written passwords or PIN numbers down all day long, but without my hardware token plugged into the thing he’d have been pulling his hair out in frustration. And that would have been a thing of beauty.

It turns out that setting up macOS to only allow authentication via Yubikey/Smartcard isn’t terribly complicated. There are a few hoops to jump through, but the procedure itself isn’t vastly involved. However, there are a few caveats that I’d encourage you bear in mind before going forward.

Firstly, enable the root user (open /System/Library/CoreServices/Applications/Directory Utility and choose “enable root access). Having root enabled on your Mac is generally regarded as A Bad Thing for many excellent reasons, but we’re about to go mucking around at the bottom of the Marianas Trench of the operating system, so having God Mode on tap in case things go awry is a must. You can (and should) always turn it off again once we’re done.

Secondly, make sure you have a good backup before you start anything. If something unexpected happens (bizarre system crash, power cut, bad stick of RAM, freak Act of God) then you could incur significant loss of data – or more precisely, significant loss of access to your data.

Assuming you’ve taken both of these into account, we’ll need to change some things in /etc/pam.d – which I wrote about a few weeks back and took a run at an explanation of the mechanics of the thing that might be worth a read.

In case things go awry we’ll do some backing up in /etc/pam.d – I have my Yubikey set up and enabled for sudo and login, so to make a copy of the default, non-tinkered-with configurations for each you should enter the following two commands:

sudo cp /etc/pam.d/login /etc/pam.d/login_backup_`date "+%Y-%m-%d_%H:%M"`

sudo cp /etc/pam.d/sudo /etc/pam.d/sudo_backup_`date "+%Y-%m-%d_%H:%M"`

Note: It is important to back these up prior to changing anything. If you mis-type something and don’t have these files backed up then you’re in a world of hurt, but if you have these files backed up and root access enabled then you can log in as root at the loginwindow and copy these files back to their default names/locations.

Next, if you want to use your PIN instead of your password when executing sudo then replace the contents of /etc/pam.d/sudo with this text:

# sudo: auth account password session
auth        sufficient    pam_smartcard.so
auth        required      pam_opendirectory.so
auth        required      pam_deny.so
account     required      pam_permit.so
password    required      pam_deny.so
session     required      pam_permit.so

At this point you’ll now be required to use your Yubikey PIN instead of your password whenever you want to use sudo – it’s not for everyone, but my PIN is deep in my muscle memory and it’s a lot faster than typing in my password. If you want to change it back then I implore you to make sure that you open the backup you created and then sudo pico /etc/pam.d/sudo and manually make the changes you want rather than deleting the /etc/pam.d/sudo file, because it’s awfully hard to use your keys to unlock your front door when you’ve just chucked the things in the drain.

If you want to force the use of a PIN/Yubikey to log in to the computer then you’ll need to likewise change the contents of /etc/pam.d/login to this:

# login: auth account password session
auth        sufficient    pam_smartcard.so
auth        optional      pam_krb5.so use_kcminit
auth        optional      pam_ntlm.so try_first_pass
auth        optional      pam_mount.so try_first_pass
auth        required      pam_opendirectory.so try_first_pass
auth        required      pam_deny.so
account     required      pam_nologin.so
account     required      pam_opendirectory.so
password    required      pam_opendirectory.so
session     required      pam_launchd.so
session     required      pam_uwtmp.so
session     optional      pam_mount.so

Finally, create a new file on your Desktop by firing off touch ~/Desktop/smartcard.mobileconfig and then pico ~/Desktop/smartcard.mobileconfig and copy in this wall of text:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadDescription</key>
<string>Configures smart card-only</string>
<key>PayloadDisplayName</key>
<string>Smart card-only</string>
<key>PayloadIdentifier</key>
<string>com.apple.configprofile.78.</string>
<key>PayloadOrganization</key>
<string>Apple</string>
<key>PayloadType</key>
<string>com.apple.security.smartcard</string>
<key>PayloadUUID</key>
<string>5A15247B-899C-474D-B1D7-DBD82BDE5678</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>UserPairing</key>
<false/>
<key>allowSmartCard</key>
<true/>
<key>checkCertificateTrust</key>
<false/>
<key>enforceSmartCard</key>
<true/>
</dict>
</array>
<key>PayloadDescription</key>
<string>Smartcard profile.</string>
<key>PayloadDisplayName</key>
<string>Smart card-only</string>
<key>PayloadIdentifier</key>
<string>com.apple.configprofile.77</string>
<key>PayloadOrganization</key>
<string></string>
<key>PayloadRemovalDisallowed</key>
<false/>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadScope</key>
<string>system</string>
<key>PayloadUUID</key>
<string>7D34CC86-C707-44D2-9A9F-C5F6E347BD77</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>

Close out of the Terminal, find the smartcard.mobileconfig file you just created, double-click on it and install it.

All things being equal, you should now have your computer set up to require the Yubikey for logging in. If you pull the key out and try and log in you’ll get a password prompt, but neither your password nor your PIN will work until you plug the key in. Likewise, unlocking System Preference Panes or any other task that requires an admin password.

Last week I wrote a pretty dull treatise on some of the problems with using your phone as a solution for multi-factor authentication. Actually, just reading that last sentence aloud has a soporific effect, so I’m off to take a quick nap.

Right. That’s better. Using your phone as a security measure is fraught with problems because there’s a perennial tradeoff between convenience and security, and when push comes to shove most people like to talk a good game about the latter but end up opting (albeit with varying levels of guilt) for the former. Physical key setup has a reputation of being fiddly, so I thought I’d knock out a quick how-to on how to do it (relatively) painlessly.

Note: In order to secure your Mac with a Yubikey, you’re going to need… wait for it… a Yubikey. They have a nice wizard on their site that’ll help you choose the model for your optimal security needs, but the one I have is the Yubikey 5C Nano. You’ll also need admin access to your Mac, to be running macOS High Sierra or above, and to have downloaded (and installed) the Yubikey Manager software.

Your Yubikey will come out of the box with a PIN, PUK (PIN Unlock Key) and 3DES Management Key already programmed into it. While we’re on the subject of acronyms, the Yubikey uses the PIV (Personal Identity Verification) card interface to do its signing/decrypting. If that none of that makes a lot of difference to you then that’s fine; think of it as analogous to purchasing a combination padlock. Right out of the package it has a combination set up on the thing – you change that before you put it on your gate/locker/avant garde fashion statement/80’s punk jewelry chain, but nonetheless it comes with something set up on it from the factory.

The PUK and PIN for the 5C Nano is 123456, and the Management Key is an eye-watering 010203040506070801020304050607080102030405060708. You will, if you’re not an idiot, want to change all of those to something more in line with elementary common sense and reason, and this is done via the Yubikey Manager app.

Firstly, choose “PIV” from the “Applications” menu:

Click “Configure PINs” then “Change PIN”, enter the old PIN (123456) and then the new PIN (a 6-8 digit number. Not 123456 or 12345678.)

Once you’ve clicked “Change PIN” you’ll be put back in the PIV screen, so hit “Change PUK” to… well, change the PUK. It’s the same drill; replace the old PUK (12345678) with another six-to-eight numbers, then hit “Change PUK” to head back to the PIV screen so you can change the Management Key.

This bit is a little trickier and there are a couple more moving parts to consider. If you have a favorite, catchy, memorable 48 character password you like to use as a matter of course and feel it appropriate to spend thirty seconds typing the thing in here then by all means do so. On the other hand, it’s a lot easier to click “Generate” to create a randomized key, and that’s what I do. It’s also worth spending a moment with your mouse hovering over the “Protect with PIN” button, as checking that box will allow you to use the convenient six-to-eight digit number you made up a couple of steps ago and not have to bash away at the keyboard trying to remember if it was bc2b0366860a92dab92de4141dd87e3ed58d39c48a3c6442 or bc2b0366860a92dab92de4141dd873eed58d39c48a3c6442.

tl;dr: check the “Protect with PIN” box.

Back at the Applications->PIV window, click on “Setup for macOS”, because if you’re this far down then that’s probably the reason you’re here. Click “Setup for macOS” again and enter your PIN then click “OK”. You’ll be asked to remove the Yubikey from your Mac and then plug it in again, and all things being equal doing so will give you this notification:

Click “Pair”, and then wend your way down the garden path of approving things and Giving The Process What It Wants, like so:

All things being equal, you should now be able to use that PIN to log in to your account while the Yubikey is connected to your Mac. Testing it out is pretty simple; just choose “Login Window…” from the Users menu at the top of the screen and check to see if you can use your PIN to log in.

So, why do all of this? Well, for one thing it allows you to greatly up your local security game. Passwords are an Achilles heel for security – they’re theoretically decent enough, but the problem with passwords is that they have to be something that people can remember and use, which is why whenever someone sits me down in front of a computer that they don’t know the password to I generally try “password” and it works alarmingly often. The solution – the way to make passwords feasible – is to make them monstrously, inhumanly difficult to the point that people can’t remember them.

Or, better yet, make them something that people never know. Work with me here.

Imagine you have an office with ten computers in it and ten people using those ten computers. Normally, people would be assigned passwords that they’d have to remember and ostensibly keep secret, but anybody who’s ever worked in an office with a bunch of other people knows that passwords are soon widely known, or the schema is worked out. If I was hired at DaveCo on June 12th 2007 and my password is dave061207 then it’s pretty simple to work out what my boss Bob’s password is if I know he was hired on January 3rd 2008 (hint: it’s probably bob010308). If Bob is out of the office and has a spreadsheet with DaveCo secrets on it then I can go look at that and see things I’m not supposed to. Or maybe Bob writes his password on a post-it note and leaves it on his monitor (or – pro tip here – stuck to the underside of his keyboard), and so on and so forth. The takeaway here is that password security breaks down with remarkable ease.

So, let’s take away rational passwords. Let’s replace bob010308 with rjaycuyfhephudojpunmibelpehuokk, and replace dave061207 with dovopuewubsidopsykfyddaoravykwu, and then we’ll give Bob and Dave a token that they keep on their keychain and plug into their computer whenever they’re using it. And then let’s never tell Bob and Dave what their passwords are. Why? Well, they don’t need them anymore. If Bob and Dave need to unlock something or log in to their computers then all they have to do is plug their tokens into a USB port and enter their six-to-eight digit code. If one of them steps away from their computer to run out for lunch then all he has to do is unplug his keychain and have a hot corner set up to switch to the login window and that computer is suddenly very secure. The actual passwords are secured and kept by an office manager or IT person or someone similar should they be needed; that way it’s possible to log in using that horrible password if a token is lost or destroyed.

Of course, there’s another option here. Right now, the token is optional as a means to log in or access the computer; if you pull it out then you can still enter a password. But what if you wanted to take it a step further? What if you wanted to make using a token mandatory and disabled any other way of logging in? More on that next week…

Last week’s Twitter hack was an example of how good design and implementation isn’t a panacea for functional insecurity.

It’s easy to obfuscate or hide the shameful truth of how you’ve been compromised, but I have to give props to the Twitter security team for being frank and open about what happened. In short, parties-somewhat-unknown managed to take over a healthy fistful of ostensibly secured and verified high-profile accounts via social engineering and access to an internal Twitter slack channel upon which access credentials and tools had been left for all to see. This – and I don’t want to blow anyone’s mind by stating this – was a Bad Thing To Do on Twitter’s part – understandable, but nonetheless unwise.

Still, for a moment or two the prevailing theory was that some of those accounts had been compromised using the same method that prior Twitter hacks employed, and thus – for a brief moment – the narrative illustrated the Achilles heel of a lot of modern authentication exploits, chiefly that SMS hacks and SIM swaps are a remarkably efficient way of completely defeating text-based two-factor authentication.

In simple terms, a SIM swap is usually a socially-engineered hack whereby someone convinces your phone carrier to port your phone number over to a SIM card that isn’t yours and that they own. Sometimes this is done with the aid of an unscrupulous phone company employee, sometimes this is done with enough personal information and details about the victim that a legitimate employee might be fooled, but the net effect is the same: a person (who is not you) is in possession of a phone (with a number that latterly belonged to you) that they can use to receive SMS messages from companies and institutions that use SMS as a means of secondary authentication. Thus, they can seize control of anything that sends a one-time code to your phone to prove your identity, steal your social media accounts, raid your bank accounts and generally play havoc with your life.

While a host of companies (I’m looking at you Google) employ the use of authentication software that isn’t tied to SMS messages, Apple’s approach is fairly ingenious. Simply, if you’re trying to access your iCloud account on a new device then it’ll send a six-digit code to another device signed in with the same Apple ID, so that your prospective attacker would need to also have access to another device signed into your iCloud account in order to be able to get the code to access your iCloud account. Which, if you think about it for a second, is as silly as it is unlikely.

It’s a solid approach, but only really good for data inside their own little ecosystem, and for my money there are are better two-factor solutions out there. Apps like Google Authenticator give you an extra level of security in that the code required to access the relevant service is created on a device that you already own and that you’ve already configured to create the relevant code. Better yet, Google supports the use of physical authentication methods like Yubikey, which requires an actual USB or NFC device to be plugged into the computer or phone in order to allow access. The beauty of this is that if someone wants to steal your data then they’re not only going to have to steal your device but also swipe your physical keys, which rather ups the game on their end from “stupid, greedy and malicious” to “Thomas Crowne Affair-style shenanigans.”

Still, setting up physical keys and enabling the use of apps like Google Authenticator are – while strongly recommended for critical services – potentially a lot to manage for a lot of people. I love Google Authenticator, but I have about eight or nine different services set up on the app and have to scroll around the list to find the right one only to find that the key is about to time out, which is admittedly a pretty low-stakes complaint but apparently yes, I’m that petty and shallow. It’s an unfortunate truth that if you make a system too complex or difficult then people won’t use it, and third party authenticators sadly seem to fall into that category. It’s understandable; there are hoops to jump through and apps to install and codes to scan and the miscellany of the operation can be tiresome and easy to push off to tomorrow or ignore altogether.

There is, fortunately, a fantastically simple way of locking unauthorized people out of your phone accounts: put a PIN on the account. AT&T (for example) calls it a “wireless passcode”, and it’s simple to find if you log into your account via their customer portal; simply create a four-to-eight digit code and then that will be required whenever you (or someone pretending to be you) wants to do anything to your account either online or in a retail store. Verizon and T-Mobile offer something similar – it won’t protect you if someone at the phone company is willfully consorting with criminal elements to defraud you and compromise your identity, but it’ll stop anyone from walking into a phone store with a tale of woe and your personal details and walking out with a new phone and the keys to your life…

Since macOS Server has been progressively waning as an affordable and effective counter-offering to the equivalent Windows and Linux alternatives I’ve been moving more and more clients to dedicated NAS hardware, which mostly means Synology DiskStations. I could write a whole other article about my experiences with Synology over the years, but nobody would want to read it because the vast bulk of it would be the equivalent of me doodling my first name and Synology’s last name in my binder during English Lit class, and probably drawing a lot of little hearts all over the place. tl;dr: Synology NAS hardware is excellent and only narrowly eclipsed by the software ecosystem they have in place.

It’s great. Not perfect (because perfection is entirely subjective), but really pretty great. The great thing about administering a macOS Server install was always that it had a solid toolset that was easy to navigate and configure for a wide range of tasks, and that if you had to go and do something peculiar with it then you could root around in the depths of that toolset and pretty much always come up with something workable. Working with Synology hits the same kind of reflexive impulse – you need to do a thing and you automatically go and reach for a way to do it, and there’s an answer. Synchronizing with another NAS at a remote location? Boom. Done. Set the thing up to auto-encode media? No problem. Backing up vast tracts of data? Easy.

Okay, not easy, but reasonable. Back when I first started working with Synology I found connecting to some cloud backups moderately torturous, but with a little patience and practice it’s possible to work it out without actually pulling your own hair out in frustration. I like to use BackBlaze B2 as a backup destination for Synology installs because it’s fast, secure, and crushingly, mind-bogglingly inexpensive. It’s like one of those here-are-three-things-you-can-choose-two situations where (against all expectation) you actually get to keep all three.

So, to work. Let’s set up a BackBlaze B2 bucket to work with a Synology NAS.

First, you’ll need a BackBlaze B2 account, available here. Go sign up. I can wait. You signed up? Great. Welcome back.

Next order of business is to log in to your Synology NAS and download the Cloud Sync Client from the Package Manager.

Now, the nitty gritty.

• Log in to BackBlaze B2 and create a new bucket by choosing “Buckets” from the side bar and then clicking on “Create a Bucket.” It’s pretty straightforward.

• Give your Bucket a pertinent name. If, for example, you were backing up your New Business Client folder then you’d call the bucket “New-Client-Files” (note the name can only contain alphanumeric characters or a “-“. No spaces.)

• If this is your first time creating any kind of keys then you’ll want to choose App Keys from the sidebar and create a new Master Application Key. You’ll see that displayed once and once only, so make a note of that or take a screenshot. If you’ve made a Master Application Key before then you should skip this step.

• Still in App Keys you’ll want to make a new Application Key by choosing “Add a New Application Key”. (When this sort of thing is this self-explanatory then I feel a little silly writing it down, but better to err on the side of obsessive compulsion.)

• You can name the Application Key whatever you like, but on a practical level it’s probably wise to make it something in line with the Bucket you created earlier, so “New-Client-Files” would be a decent choice.

• Choose the Bucket you want that Application Key to be associated by from the drop-down menu, then the type of access you want. Note: You’ll almost certainly want to leave that as Read and Write and not mess with the other options before hitting “Create New Key”.

• You’ll get a success message with keyID, keyName, S3 Endpoint and applicationKey info. Make a note of all those and – ideally – leave that window open in your browser. It should look something like this:

• Navigate over to your Synology DiskStation and open up the Cloud Sync application, then hit the “+” icon to add a new Sync destination.

• Add the “keyID” data you got from the Application Key in BackBlaze to the “Account ID/applicationKeyId” field, and the “applicationKey” data from BackBlaze to the “Application Key” field. Watch out for extra spaces if you’re copy/pasting, as they’ll throw up authentication errors.

• From the “Bucket Name” drop-down menu you should be able to see the Bucket that you set up on BackBlaze. Most of the time this happens instantaneously, but if you have to wait a minute or two for it to show up then don’t be alarmed.

• Next, select the local shared folder you want to backup from the “Local Path” drop-down, and choose the Sync Direction you need.

Note: If you’re interested in a straightforward backup then choose “Upload local changes only” and check the box next to “Don’t remove files in the destination folder when they are removed in the source folder.” If you neglect this step then any time you delete a directory on the NAS it will magically reappear, which might sound good on first blush but is actually really annoying. Case in point: renaming a large number of directories on a share only to find out that duplicate copies (with the old names) are pushed back down and you end up with multiple copies of everything and a lot of gnashing of teeth.

• Click “Next”, “Confirm Settings” and “Apply”. And you’re done!

Way back in the good old days it was pretty straightforward to go and do some amateur spelunking in the depths of your Mac. Breaking important and vital things in the operating system was a – well, not trivial undertaking, but certainly a relatively simple one. Fortunately it was also very easy to go poking around in the Console.app to see what your Mac was up to so that you had at least a reasonable chance at deciding what you’d done wrong so that you could fix it.

And then, of course, Apple had to go and make it all better. Okay, the “better” there is a hair subjective, so I’ll clarify: Apple introduced a new, unified logging system whereby error logs were dynamically and intelligently supported as a matter of course, allowing you greater flexibility in being very granular in digging through logs as well as making the log files a lot smaller. Which was nice.

What wasn’t so nice is that it’s now terribly awkward to search through system logs. Sure, you can fire up the Console and watch error messages scroll by – and scroll back to look at them for the current session – but looking back through logs is a trifle more problematic, and requires a little command-fu.

Enter the log command, which allow you to (amongst other things) search through your log files to pull out user-defined strings, thus:

log show --predicate 'eventMessage contains "Previous shutdown cause"' --last 24h