Skip to content

security

ADP’s payroll check security absurdity

Warning: The following is nothing but a rant—no charts, no photos, nothing but text—about a piece of security absurdity I ran into the other day. I am 100% in favor of strong security in general regarding financial matters, but when it's false security that does nothing more than inconvenience legitimate users, that's when I get mad…and that's exactly what this was: a security absurdity.

————————————————

My daughter Kylie recently got a part-time job; her employer uses ADP to process its payroll. When her first check arrived, it was actually a debit card—which we didn't want to use—so she had to write herself a check (using a blank they provided), which she could then deposit.

Because Kylie had a busy day ahead of her (school then work then a post-work thing), I told her I'd write the check for her, then she'd just have to sign and deposit it. But to make the check usable, I needed a six-digit authentication code that ADP provides via a phone call. And that's when I entered a hellhole of security absurdity thanks to ADP…

[continue reading…]



Encrypt files then backup to a cloud service via script

Most cloud services tell you that their data stores are safe, that your data is encrypted in transit and on their drives, that employees don't have access, etc. For the vast majority of the stuff I store in the cloud, this is more than good enough for me—the data isn't overly sensitive, and if someone were to hack their way in, all they'd get are a bunch of work and personal writing files and some family photos.

For other files—primarily financial and family related—those assurances just aren't enough for me. But I still want the flexibility and security that comes from having a copy of these files in the cloud. So what's a paranoid user to do to take advantage of the cloud, with added security, but with a minimum of hassle?

The solution I came up with involves using local encrypted disk images and a shell script. Using this script (and some means of scheduling it), you can automatically encrypt and back up whatever files you like to a cloud service.

[continue reading…]



Behind OS X’s modern face lies an aging collection of Unix tools

Note: This article has been heavily modified, as I was a total knucklehead and completely forgot about GPL v3—thanks to Geordie Korper for pointing it out in the comments. Basically, the cause of the aging Unix tools in OS X is GPL v3. I've updated the following table to include the license information. In every case but one (nano), GPL v3 is the license on the non-updated apps. So that's that…I'll leave this up, though, in case anyone's curious about this stuff.

As I covered recently, the version of bash that ships with OS X is quite old, and as such, is vulnerable to the recently-revealed bash security hole.

At some point, Apple will release an OS X update containing a patched version of bash. (Update released.)

So while Apple has patched bash, this version of the shell is simply ancient. Just how old is it? bash 3.2.53(1) is roughly seven years behind the current version, 4.3.25. Seven years is like, well, forever, in Internet time!

With that bash age gap in mind, I took at look at a number of common Unix apps—in both Mavericks and Yosemite—to see which versions were in use. Then I checked the same apps in MacPorts, a tool that makes it simple to install many Unix apps.

(MacPorts doesn't necessarily have the absolute latest version of every Unix app, but they do stay relatively current. For instance, they already have a patched version of bash that fixes the above vulnerability.)

The results were interesting, to say the least—many of the core Unix utilities in OS X are years and multiple versions behind their open source, er, sources. You can thank GPL v3 for that, as noted above (and covered in more detail below). But that still leaves the big question:

Does it matter?

That is, should we care that these tools aren't keeping up with their latest and (presumably) greatest versions? Is it a problem, or merely a statement that what we have works well enough for the majority of users? (For those who don't want to bother reading, my general opinion is no, it doesn't matter.)

[continue reading…]



A [possibly dangerous] fix for the bash security exposure

In case you missed the news, there’s a big security hole in the bash shell. If you’re using an OS X machine and it’s not exposed to the internet (and even then, not running a publicly-facing service that communicates with bash), you shouldn’t have much of anything to worry about. In theory, anyway.

In practice, because I like to live dangerously, I decided I wanted to make my machine safe. Or at least try. What follows is the how-to for how I did it.

Note: Please exercise extreme caution if you're going to follow my how-to! I am replacing a couple of key system-level files with a new, untested-by-Apple version. It's quite possible this may break my system in ways I haven't yet discovered. Also, given that there's probably not any exposure for a typical user not running web-facing apps that interface with bash, this really isn't worth doing for most users.

With that disclaimer out of the way, read on for my how-to…

[continue reading…]