Since I’ve started working in Information Security space, I’ve been talking to a lot of people about the topics related to protecting ones’ identity online. Basically, trying to answer the question: What does it take to sufficiently secure my online accounts? Of course, the meaning of sufficiently is very subjective here, but I’ve always kept it vague to gauge what it means to them specifically.

I did make sure to talk people of various backgrounds – from deeply technical all the way to not technical at all. Surprisingly, many of them, even among the quite technical crowd, turned out to be lacking the understanding of some important fundamentals. In particular, it’s not always clear to them, what problems Multi-Factor Authentication (MFA) is targeting and solving. What threats do Password Managers are targeting and solving.

I’ve been wanting to use my brand new NitroKey 3, but TOTP is not supported yet. So, I’m looking to implement it myself, since firmware and tooling are open-source.

NitroKey 3’s firmware is based on Trussed framework. In essence, it’s been designed so that anyone can implement an independent Trussed application. Each such application is like a module that can be added to Trussed-based product. So if I write a Trussed app, I’d be able to add it to NK3’s firmware.

Part 3 is the last part in this short cycle. Here I’ll explain all the details around Time-based One-Time Password algorithm. I’ll finish up by also elaborating on things common to both, HMAC-Based One-Time Password algorithm:

• QR Codes used to easily transfer secrets from the server to the Authenticator app
• Base32 algorithm – used to store non-printable secret in a URI (effectively stored by the QR Codes mentioned above).

TOTP

One way to avoid the problems with lack of feedback between server and the app would be to shift from using a counter that is increasing with every authentication attempt to a counter based on, for example, a time stamp. This is what TOTP is actually doing.

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).