Non-repudiation in IT security means being able to prove where something comes from or who did what. Although few people talk about it, it’s actually an essential part of a lot of technologies we use daily. For example, Apple makes all developers sign their applications before submitting them to the iOS store. That makes it possible for Apple to trace the origin of an App directly to a developer.

Which brings us to shared accounts. Having worked with hundreds of companies over the past couple of years, we’ve learned that shared accounts are ubiquitous, specially for infrastructure accounts (if your company uses SSH, chances are you have one Unix Login that all your admins/employees share). Which makes non-repudiation harder.

Yet you can still achieve non-repudiation if each employee uses a different SSH key on the authorized_keys. That way you can trace every action to a specific key. But now comes the hard part. What if you want add Two-Factor Authentication to this account?

The problem is essentially: you have one unix login (Eg: admin) that is shared by multiple employees and you want to add Two-Factor Authentication to this account. What can you do? The simple solution is to share a Two-Factor Authentication key among all employees. If you are familiar with Google Authenticator, you know it’s possible to embed the key on a QR-Code (or manually typed in). So one employee generates the key and then shares it with everyone else. He also keeps a stored copy of the key, so when a new employee starts, they also can get the key. The result is, you end up with one login and one Two-Factor Authentication key.

The fact that they store the QR-Code is bad by itself (securely storing secret keys is very hard and we’ve even seen companies which store it unencrypted on a shared Dropbox). But worse is that you are giving away non-repudiation and when (not if) you’re hacked you won’t know where it came from.

Let me explain. Obviously, you’ll know the QR-Code with the key was compromised, but the problem is you won’t know how. Was it Andrew’s android phone which was compromised? Or maybe it was Joe’s iPhone? Maybe it was the Dropbox account where the QRCode is stored?

So what do you do next? Do you perform a forensic analysis on every employees cellphone? Or do you simply generate a new key and share it with everyone again? But how can you be sure you are not sharing it with the hacker too? Because realistically, you probably are.

Look, getting hacked sucks, but staying hacked sucks even more. There’s nothing worse than continuously being monitored by a hacker who’s staying undetected for years and you don’t even know. Long gone are the great days when attackers would deface or bring down your site the minute they gained access. Today you’re lucky if the hacker even writes anything to disk.

But if you are one of the lucky few that discovers you were hacked, you want to at least make sure you can trace back where the attack came from, learn from it and shut it off. And that’s why non-repudiation is so important. That’s why, when one of our clients asks us to give them the Authy secret key we refuse (and we’ll continue to do so). That’s why you can’t type or see the secret key for an Authy account. And that’s why Authy enforces that each key is only available on one phone ever. Sure, it might make things a bit harder, but it enforces the right principles.

So next you are building or using a system, insist on non-repudiation. Make sure you are able to trace every action to a specific person. Never, ever give up non-repudiation for simplicity.

And if you happen to be sharing unix accounts and want to add Two-Factor Authentication the right way, you might want to give our latest SSH plugin a try.