Daily Archives: 12/08/2016

I’m never really finding the time to write. Or, as Calvin put it so eloquently:

There is never enough time to do all the nothing you want.

So let’s get right to it.

Imagine you’re working with an engineering team, and you need to distribute access for manipulating your deployment environment. For security reasons, you don’t want to give everybody who should be able to access it, full access.

But even limiting the access, e.g. by using IAM roles on AWS, doesn’t fully do the trick, because in order for your team to do anything meaningful, they do need reasonably strong permissions, and hence, are able to do reasonable damage.

What if we could at least limit the time they have access to the system? What if they at least need to ask every time they wanna access the system?

Modern authentication systems usually do not support this, but something very similar: two-factor authentication. The idea behind this is that, in order to sign into an account, you need two factors, usually “traditional” account details like username and password plus a so-called one-time token that is being generated by another device like a smartphone.

Let’s quickly look at how these one-time tokens are being generated. In most cases, these are time-based one-time passwords. They are based on a unique string that is being generated upon setting up the account, usually presented as a QR code, that is e.g. scanned and saved by an application on a smartphone. The application then computes, given the unique string s and the current time t (truncated to intervals of e.g. 60 seconds), a deterministic function f(s,t) that usually returns a 6-digit number.

This 6-digit number then has to be provided alongside the traditional account-details to sign in. Since this 6-digit number is only valid for about 60 seconds, it cannot be reused again. Clever.

So how can we turn this multi-factor-authentication into multi-people-authentication? Well, instead of storing the unique string on the team member’s device, we store the string (symmetrically encrypted, if we want to) in a database. Now when the team member wants to sign in, he/she provides the traditional account details and when being asked for a one-time token, the team member queries one of the administrators, and the administrator computes the time-based one-time password for the team member. Boom.

Now while this sounds cool in theory, how can we make sure that this is not an organizational pain in practice? By turning it into a Slack bot. Since your team is already on Slack, why don’t your team members just ask the slack bot to generate a one-time token for them, and the slack bot in turn queries the administrators whether to grant access to the token generation function for that specific account.