This post is the first in a three-part series. The remaining two:

• How does Google Authenticator work? (Part 2)
• How does Google Authenticator work? (Part 3)

When you’re accessing services over the WEB – let’s pick GMail as an example – a couple of things have to happen upfront:

1. The server you’re connecting to (GMail in our example) has to get to know who you are.
2. Only after getting to know who you are it’s able to decide what resources you are allowed to access (e.g. your own email inbox, your Calendar, Drive etc.).

Step 1 above is called authentication. Step 2 is authorization (server can authorize only after successful authentication).

Installing Debian/GNU Linux under bhyve on TrueNAS Core

I got myself a TrueNAS Mini X+ couple of months ago. I have it running TrueNAS Core based on FreeBSD. In that system you can run VMs under FreeBSD’s native hypervisor, bhyve. Since there are a couple of quirks around running Debian specifically, I decided to write up a quick article about setting up Debian-based VM there.

The quirks

The ones I’ve stumbled upon were:

I’d like to shed some light at the process of Authentication since it’s a fundamental building block in creating secure tools that need to communicate with other actors over the network. When tools and/or users interact with one another – e.g., through a web browser – both ends of the interactions need a way to make sure, they’re communicating with the right party. Some bad actor might for example create a web page that looks like your bank’s online banking portal. With additional DNS spoofing you might be connecting to the wrong website. When you’d be trying to log in you’d be prompted for username and password. If you entered them on that phony web page, you’d provide them to the attacker. It’s imperative for your browser to be able to make sure, that this is not the case here.