Eventually, I added crossword puzzles to the mix, largely due to the influence of my friend James. I watched him work through them and wanted to learn the tricks myself. On Sundays—usually parked on the couch watching NFL games—I’d have the Sunday crossword nearby (mostly unfilled). But week by week, I improved. One unexpected perk of getting the Sunday paper delivered (at least on our route) is that you also get a Wednesday edition.

A few years ago I suggested to James that we put these free Wednesday puzzle sections to good use instead of tossing them in the bin. What began as a casual, nerdy side quest quickly turned into a standing weekly ritual religiously observed every Wednesday—or as close to it as schedules allowed. Each session follows the same order: Sudoku first, then the New York Times crossword, and finally the United Media Daily Commuter crossword.

Then I had a silly idea: what if we timed ourselves every week and tracked it? At first it was just for fun. We documented dates, completion times, and a few notes about the puzzle. We ran some basic stats (mean, median, standard deviation) and made a simple graph.

At some point, this stopped being a joke spreadsheet.

Once the dataset got large enough to feel real—157 data points representing three years of Puzzle Wednesdays—I treated it like any other analysis problem: clean the data, normalize what needed normalizing, and then start asking questions without strong prior beliefs about the answers. The core dataset is intentionally simple—date, total completion time, and a handful of notes—which made it easier to experiment.

From there, I started merging in external data sources aligned to the same dates. Weather data came first, followed by broader environmental variables, market data, and a few intentionally absurd dimensions. The goal wasn’t to prove a hypothesis so much as to see whether anything showed a meaningful relationship with how fast we solved puzzles on a given Wednesday.

Most things didn’t.

This is exploratory analysis, not an attempt to publish a paper or claim causality. But it is a real dataset, collected consistently over three years, which makes it a surprisingly rich sandbox for asking questions you wouldn’t normally bother asking. If you think I missed an obvious (or ridiculous) data source to include, I’m open to suggestions.

The funniest result by adding in weather data: higher wind speeds correlate with slower completion times. Not rain. Not temperature. Wind.

I don’t have a theory for this. Maybe it’s noise. Maybe windy days are subtly distracting. Maybe it’s a proxy for something else entirely. Or maybe it’s just a reminder that humans are weird, rituals matter, and patterns will emerge whether we fully understand them or not.

That’s really the point of this whole exercise. This started as two friends doing puzzles to keep their skills sharp. It turned into a weekly ritual. Then it quietly became a three-year dataset. The analysis is fun, but the consistency is the interesting part—the discipline of showing up every Wednesday, starting the clock, and doing the work.

I now present to you the data, the methodology, and the charts—because of course there are charts. Here’s the analysis of our Puzzle Wednesday quests for the last three years (yes we will keep tracking and yes I will post updates!).

In my world, Twingate is used more in the “I need to access this resource at this time” mode, and not “All on, all the time.” I’ve had some issues with leaving Twingate open all the time (be it connected or not) as it sometimes plays with route tables in ways that prevent traffic from flowing. This is especially true in situations of IP conflict.

In order to have an always-on setup for the main Raspberry Pi, I have it VPN back into my network so I can see it just on the LAN like it’s hidden somewhere in my house (this happened once, but rest assured I found the rogue RPi). This way I can do maintenance without firing up Twingate, but it creates a small issue. I don’t want to have BOTH devices VPN back in, just one. This means that if I want to say update the Pi Zero, I need to first jump on the Pi, then ssh from the Pi to the Pi Zero.

A bit of a hassle, especially when I’m trying to automate things with Ansible.

I wanted a way to be able to touch the Pi Zero “directly” from hosts on my LAN. Thankfully, ssh provides a jump host proxy function natively, and I got it set up in less than a minute! Look below for config if you are in a similar situation, be it for work or pleasure.

To enable this functionality, you need to define both hosts in your ~/.ssh/config file. It will look like this:

# Define the proxy host first.
Host remotepi
    HostName remotepi.example.com
    User username               # replace with your username
    IdentityFile ~/.ssh/id_rsa  # replace with your key

# Now define the Pi Zero attached to that same network.
Host pizero
    HostName 192.168.1.234
    User username
    IdentityFile ~/.ssh/id_rsa
    ProxyJump remotepi

This setup assumes you have ssh access from your LAN (via VPN) to remotepi. You can replace that hostname with a local IP on your network, or in my case, I just use a local DNS server to define the name. As long as you can ssh to remotepi then the next step going to the pizero is available to you. You need the IP on the remote network of pizero, but the magic happens with the “ProxyJump” config line under the pizero definition. This tells SSH to first go to remotepi, then seamlessly launch into pizero.

So there ya go! Seamless proxying of ssh via a jump host

I had one of those purge moments last week and remembered I had a tab open to check out Kasm Workspaces. This was an instance where I was glad I left that nagging to-do item waiting for me to revisit it.

Kasm is a disposable desktop infrastructure platform that is available for you on-demand when you need to perform tasks that you may not want on your primary, persistent machines. If you are a technology or security person, think of it as a way to spin up a containerized Linux distribution to run a few tests or an isolated Chrome to detonate a suspicious link. There are commercial and community versions available for use. You can test it out right on the website with a five minute timer to see how it works. The sheer number of tools you can provision with just a click is impressive!

I’ll leave some technical notes for those of you who want to try this in your own lab below documenting some minor issues I ran into and solved so you can get going faster.

The first thing I did once I got mine up and running was hit the Firefox Browser tile and detonate a phishing link that was reported to me. I was able to safely interact with the malicious webpage, see exactly what it was attempting to do (standard cred/token theft), download the malicious javascript (and subsequently beautifying it because you know it was all on one line with no spaces), and get the nitty-gritty of where things were being sent. It took less than a minute to do all of that.

After that, I started playing around with some of the tiles. Parrot OS was one of my new favorites and after a small configuration adjustment (noted below) I was able to launch a few scans against targets I was interested in without having to fire up a separate VM on my machine using these on-demand containers. The Alpine experience is super snappy, and even trying out other browsers like Vivaldi in a low-risk way was a good use of time.

Kasm has a ton of practical uses as well. On-demand desktops or jump hosts if you deploy it in a secured area, browser isolation (as I did above) to visit sites that may cause your machine harm, research, compliance, exploit testing, and even threat hunting (again, as I did above). If you are a security or technology professional, Kasm is a tool that should be deployed and ready for use in your toolbox.

If you are convinced and ready to get started, keep reading to get some tips and tricks that will speed your way to using Kasm!

The Technical Mumbo-Jumbo

Here are some tips and tricks that I used to get things going.

Base OS Choice: If you are ready to move from the cloud version to something on-prem, you need a new machine for the Kasm installer to set up your environment. My first failed try was with Ubuntu Noble Numbat (24.04). I have a faint memory of discovering that Kasm was only compatible up to Jammy Jellyfish (22.04), so that was completely on me for doing that. I switched to installing a minimalist Debian 12 (bookworm) server that was super stripped down and the installer worked perfectly.

When you are putting hardware specs on the machine, pay close attention to the amount of storage you will need. These containers are not small, so a 20G footprint won’t get you very far. You will also need to ensure you have enough memory for the number of simultaneous users who will be launching workloads.

If you are running Debian, you will need to ensure you have curl, tar, and sudo (properly configured for your account to elevate its privileges) before you run the four commands in the installation instructions at the link above.

Elevated Privileges: One thing you will notice quickly if you deploy a linux distribution, such as Alma or Parrot, is that you are running the OS as a user called kasm-user. This is intentional. The kasm-user (and root user) does not have a password, so if you want to elevate to root to run nmap as an example, you need to do a couple of things.

Most modern Linux operating systems that would have a desktop element have sudo pre-installed, but by default the kasm-user is not in the /etc/sudoers file. In the Kasm admin portal, go to your installed workspace list and select the tile you want to modify (Alma in my case). Select the pencil icon to edit, and scroll down to “Docker Exec Config.” In that box, you want to drop in some JSON configuration that will add kasm-user to the /etc/sudoers file.

{
 "first_launch":{
      "user":"root",
      "cmd":"bash -c 'echo \"kasm-user  ALL=(ALL) NOPASSWD: ALL\" >> /etc/sudoers'"
  }
}

Click Save. Now for most *NIX workspaces you deploy, this will be sufficient (provided sudo is installed) to allow kasm-user elevate to root. Keep in mind, this may break some of the isolation controls (I have not tested all of this) so do this with care. You could also add commands here to create a password for the kasm-user account, and then you could remove the NOPASSWD: ALL section of the JSON above for a traditional sudo experience.

Running Privileged Workloads: Parrot OS requires additional config to be passed to the Docker subsystem to allow tools like nmap to run—even without root privileges. All you need to do is edit the workspace again like above, and go to the Docker Run Config Override section. You will want to add the following there and click Save.

{
  "privileged": true
}

If you also want to elevate to root, you will need to make the Docker Exec Config update above as well.

Problems with Tiles: As of this writing, the default Kali tile will not install. I’ve filed a bug on this but I’m guessing this will work itself out based on the errors I am getting. Be sure to check the logs when things are not working, and refer to this Troubleshooting Guide to get things resolved.

Edit, Jan 26: If you look at that bug report above, one user suggested just using the rolling-weekly image until the normal one is fixed. This works fine for me in what I’m doing, so that’s how I solved that one tile. If you are in a similar situation and don’t mind a little bit of volatility, do that to get your tiles working (Kali is up and running nicely!).

Additional Kasm Registries: There are third party registries you can add to your Kasm setup to bring in other tools. I was able to get a Kali tile to work by doing that, but be intentional about adding those registries and do your due diligence.

Thus, pgMail was born.

The history is all on Github now, and it’s generally been stable over the years. There were some bugs that needed to get fixed over time such as issues with SMTP Pipelining, adding support for MIME Multipart emails that would offer HTML formats as are the norm these days. But today I had someone request to turn on utf-8 encoding to ensure the expanded character set is processed properly. Surprised that had not been requested yet, but here we are.

That’s been released today with some additional updates to the README and sample code that reflects PostgreSQL v15+ installations. You can get all the details here.

What you want to do is configure a hook. They come in three varieties: pre-hooks (commands to run prior to running the re-issue), deploy-hooks (commands to run immediately after the cert is issued but prior to deployment), and post-hooks (commands to be run after deployment). You can find command line options pretty easily, but there is another trick if your system has all the automation built in (say, via the SNAP subsystem).

You will find some options in the /etc/letsencrypt/renewal-hooks directory if you have global commands you want to run. This is an easy way to script actions when your machine is single use. But if you have a web server on the same machine you are running email on, you might not want to run global commands when every certificate renews, just commands for unique to that one certificate.

The way to accomplish this is via the /etc/letsencrypt/renewal/your.cert.name.conf config file. At the bottom of the [renewalparams] section, you want to add the following lines:

# Add this to the /etc/letsencrypt/renewal/your.cert.here.conf
pre_hook = /bin/systemctl stop <ONE OR MORE SERVICES TO STOP, such as 'apache' to ensure you can do the renew>
post_hook = /bin/systemtl start <ONE OR MORE SERVICES TO START, such as 'apache'>; /bin/systemctl restart <ONE OR MORE SERVICES TO RESTART, such as 'dovecot postfix'>

So there you go. Now if you wanted to use letsencrypt certs for email or stunnel, it’s easily accomplished with these options.

He got me good.

Working through *nix in those days was made easier (and still is today) through Manual Pages, or manpages for short. It’s the thing that people would expect you to go do when they replied “RTFM” when you asked a question that was clearly pointed out in the manpage. You type man <command> and you get a fully formatted text usage guide. Some can be long, some are quite short. By reading the manpage, you should have a good idea on how to use that particular piece of software on your *nix machine.

I recently worked to contribute to an open source package to address and issue I’m having with a remote server and how it phones home. Specifically, when internet connections would go down, sometimes it would get stuck in a loop until it was rebooted, emailing me faithfully—EVERY HOUR—that the task of reconnecting failed because there was already a reconnection in process.

It was stuck.

So I started poking around. Was there a way in a BASH script to put a time limit on the execution of a command so that it could be killed if that time limit exceeded? Why yes, a tool that is part of the GNU CoreUtils package will do exactly this. The tool is called timeout.

So what do I do first? Pull up the manpage. This looks like it will work perfectly! But upon trying it, I got an error message. It was not working. I was attempting to pass the -k flag with a 10 second limit, but no joy. After banging my head on the desk a little bit and honing my Google-fu, I realized that the manpage does not accurately represent the functionality of the tool. When using the -k flag, you must immediately pass a timeout duration for that signal. The tool will first send SIGINT, and if the process does not quit, after the duration you pass into -k, it will send a SIGKILL. This is trying to gracefully shut down the process before killing it. You can also send in other signals with -s.

According to my read of the docs, this should work: timeout -k 10s ping example.com

But in order to send a SIGKILL to the command, you have to also send a second timeout for sending SIGKILL: timeout -k 10s 10s ping example.com

Otherwise, timeout will give you this error: timeout: invalid time interval 'ping‘

You can obviously replace ping with the actual command you are trying to run.

I’m posting this not only for my own documentation so I can refer back if I get stuck here again, but also for others who are trying to use that tool and realizing the help docs don’t match the functionality of the tool. Edit: Also yes, I did file a bug report, and it was closed because the code is doing what it is supposed to, but the manpage is a little ambiguous.

Edit 2: As it turns out after some back and forth on the bug report, it’s just my poor understanding on how the tool actually works combined with a lack of examples and some ambiguous language in the manpage.

I.e., my bad. Not a bug.

After looking at the code again and hearing back from the maintainers, there isn’t a logic bug but more confusion on my part between -s, -k, and the order of steps in what timeout is actually doing. In the pull request to the synology-scripts repo, the maintainer suggested a couple of other options and I think we’re in a good place as far as what the go-forward plan is. In retrospect, clarification on the manpage and usage is probably the best thing to do, plus adding in examples at the bottom of the manpage. They would be something like this:

EXAMPLES
       timeout 2s sleep 10
              Send SIGTERM to sleep after 2 seconds.

       timeout -s 9 2s sleep 10
              Send SIGKILL to sleep after 2 seconds.

       timeout -k 10s 1d ping -i 60 example.com
              Send SIGTERM to ping after one day of data, and if the process 
              does not end within 10 seconds, send SIGKILL.

       timeout --preserve-status 15m <some_process_that_may_get_stuck>
              Send SIGTERM to a some process after 15 minutes, but preserve 
              the exit code of that process.

In a previous role, I was responsible for a complete CIAM modernization at a large bank. More recently, I modernized an entire IAM system for a premier identity company. In both cases, my guiding principle was making the user experience easier while generating more data to create usable telemetry for risk engines and blue teamers (your internal cybersecurity defenders). Over the last seven years, I’ve learned a few things about how customer identity should be done.

In 2024, here are ten things that companies get wrong about customer identity and access management (workforce is a whole other basket of grasshoppers):

1. Relying on username/password for security. It’s 2024. Using usernames and passwords as your sole method to identify something coming in from the Internet is irresponsible and risky. It’s especially terrible if you are forcing a password policy with complexity requirements for your customers. It’s been seven years since Bill Burr (not the angry comic) apologized for creating password complexity rules. You will be spending too many resources fighting bots and credential stuffing attacks.
2. Using Email or SMS-based One Time Passwords (OTP). I had someone tell me once that “Well SMS or Email OTP is better than nothing.” No. No it is not, Billy. If you think that Sally Smith’s password hygiene is bad enough that you want to add in an OTP, do you think their email or phone security is somehow better? It’s not, and we saw lots of Account TakeOver (ATO) events happen specifically due to Email- or SMS-based OTP (some with multi-million dollar losses). SMS-based OTP is also punitive to people who are unable to receive one (for example, if they are traveling internationally or on an airplane). Don’t waste money investing here.
3. One Channel thinking. Chances are you will have multiple ways customers might interact with you (Multi/Omni-Channel). Your CIAM experience should be seamless across all methods of customer interaction. As a bonus, high adoption of your mobile app enables push notification for MFA—an excellent way to step your authentication game up.
4. Ignoring risk signals. Not all login attempts are equal, just like not all account actions are equal. Financial Services firms capabilities outpace nearly all other industries because they need to evaluate the risk related to the movement of money at scale. Your user experience will be better if you use a risk-based engine to streamline authentication. Remove friction on harmless actions if they fit within your risk profile. There is a certain hotel brand is driving me absolutely bananas right now as every time I log in I am required to have an Email or SMS OTP. Not only are those terrible authenticators, but the company is not consuming any risk signals on this activity. If I’m using the same browser, logging in from the same IP, and using the same machine, a basic login should happen without a step up. I can’t imagine how much this company is wasting on unnecessary SMS delivery right now.
5. Ignoring context. This is where authorization comes in and that’s a distinct difference from your authentication, but it is a part of the CIAM user experience. Viewing information is low risk and should not have the same level of attention or protection as moving money or redeeming stored account value.
6. Not using Passkeys. Passkeys are a fantastic option for MFA step up that fix the biggest weakness associated with Time-Based OTP (TOTP, a.k.a, Google Authenticator) and also give you a pathway to a passwordless experience.
7. Not having a passwordless path and strategy. Passkeys can be used for MFA, or they could be used as a 100% passwordless experience. No username, no password, just presenting the passkey (which is considered a strong authentication on its own). A passkey is far superior to a username and password combination as it is a stronger, phishing resistant factor (unlike a password).
8. Not providing risk-appropriate options for MFA. Not all people are mega authentication nerds like me and carry hardware keys around with them, and not all websites or actions should require that kind of MFA. But adding options for customers to use factors you have already performed risk evaluations on and deem acceptable is a must. At the Bank, my vision was to roll out “Bring Your Own Authenticator.”
9. Trying to roll your own authentication engine. Are there open source options to avoid paying third parties for CIAM services? Yes. Should you use them? Absolutely not. Unless you are a company providing CIAM services, you don’t make money by writing and maintaining CIAM solutions. Direct your precious development resources toward revenue-generating code.
10. Ignoring high-assurance account recovery. Your accounts are only as secure as their recovery methods. Using ID Verification technology is an option to consider for high-assurance account recovery that scales and can be done in real time with minimal human intervention (combined with other items to resist ATO).

Every CIAM strategy must at a minimum cover these ten points to be high functioning, low cost, and business enabling.

Before you freeze, get in a habit of requesting your report annually. Some bureaus partner with apps you can use as well (such as Credit Karma, Credit Sesame) that are free to download and set up. You want to make sure nobody opened a line of credit in your name without you knowing.

One thing you need to know about freezing your credit report is anytime you take an action that requires a hard inquiry, you will have to temporarily unfreeze the report at the credit bureau the company you are working with uses. So if I apply for a new credit card, I need to ask the bank which bureau they use (such as, Experian) so I can unfreeze it for the day. Just remember that when you apply for something and it denies you because it can’t get your credit report.

On to the instructions! There are four bureaus and you need to freeze both your report and your spouse/partner/parent/child at each one. If you are asked to create an account, be sure you are using a unique password and storing that in your password manager (with a PIN as well if it asks for one).

• Experian Freeze <— Sign up for an account and freeze.
• TransUnion <— Add a freeze.
• Equifax <— Place a security freeze.
• Innovis <— the credit bureau everyone forgets. Request security freeze.

There ya go! I actually thought I wrote this blog post years ago. Better late than never!

Yep, rookie mistake on my part. Should have set things up so that domains forwarding to my spam filtering service can only be delivered locally if they come FROM that service. So I turned to the extremely helpful Postfix Users group.

Essentially, they suggested leveraging access(5) rules to define this in main.cf. You could throw the domains into a hash table as well, but since my config isn’t really changing that much at all I did not go that route.

The first part of the config is to set up the CIDR blocks in question that you want to allow mail from:

    smtpd_restriction_classes = reject_unfiltered

    # Allow the filtering service IPv4/IPv6 CIDR blocks and reject
    # everything else.
    reject_unfiltered =
        check_client_access cidr:{
            {192.168.2.0/24               permit_auth_destination},
            {2001:dead:beef:cafe::/64    permit_auth_destination},
            {0.0.0.0/0                  REJECT 5.7.1 MX bypass attempt},
            {::/0                       REJECT 5.7.1 MX bypass attempt}
        }

Then, you need to add to your existing smtpd_client_restrictions block a check to make sure email destined for the domains you wish come from your provider.

    smtpd_client_restrictions =
        check_recipient_access inline:{
            {filtereddomain.com = reject_unfiltered},
            {filtereddomain.net = reject_unfiltered}
        }, 
    # Just insert this at the top of your list of client
    # restrictions and you can keep processing/restricting
    # after that.

That’s all there is to it. Worked instantly and does not affect mail delivery for domains that are not listed in the second config block. Thank you to Viktor Dukhovni for helping!

Version 4 of the standard pushed the remainder of TLS version requirements to your routine vulnerability scans—prioritized by the resulting CVSS score. You will find only a single reference in the twelve requirements (it’s in the guidance section of 4.2.1) and specific guidance on outdated TLS in Appendix A2 to be used in extremely limited scenarios. Encryption is all over the standard (found on more than 40 pages), but the specifics are pushed out to a more real-time threat landscape.

PCI DSS requires that scan vendors properly scan for and identify vulnerable versions of SSL and TLS while coding them properly for remediation. Specifically¹, ASVs must:

• Catalog protocol versions, encryption algorithms, signature signing algorithms, and key strengths,
• Report on certificate elements like validity, authenticity, and expiration date, and
• Check for common name mismatches (a valid certificate installed on the wrong domain/URL).

What this means for someone complying with PCI DSS is you must be on top of your configurations, library versions, customer usage (so you don’t turn off a customer by changing an algorithm or version), internal defenses (such as proxying via TLS Peeking), and certificate validity. Small shops may be able to manage this manually, but larger shops (such as DigiCert) can benefit from a third party vendor to manage trust for them².

TLS management is an IT function that is backed and checked through security policies and procedures. Operationalizing it as such will ensure you maintain high security (confidentiality/integrity) while keeping systems up and running (availability).

Enterprises who need to manage TLS should look for (at a minimum) vendors that can do the following:

• Manage the lifecycle of certificates (issuance, production, revocation), and provide guidance on re-issue where required,
• Discover certificates that do not meet enterprise requirements (non-internal CAs, self-signed certificates, or certificates that come from public CAs you do not use) and provide automated reporting to first responders,
• Automate installation,
• Ensure certificates are not on the verge of expiration which may cause an outage, and
• Cover more than just websites, but anywhere you might want to secure communication using TLS (like with VPNs or eMail).

Following this guidance will ensure you do not run into challenges with your QSA over encryption, and elevating a rapid response team to address issues found in ASV scans will maintain your compliance with PCI DSS.