Bsrgvty

See the title. I'm involved in a security audit right now, and am wondering whether 2FA should be enabled on not just human login accounts but also on service accounts (non-human accounts)? If so, how is this normally managed? Someone must still be at the other end to confirm the 2FA right? And would this be mainly a one time thing at setup or would they need to reconfirm the 2FA request periodically?

The trouble with requiring MFA on service accounts, is that it would have to be fully automated. For instance, a time based OTP.

But as this OTP is based on a secret seed, it is effectively just another password stored in a config available to the service account. And it therefore gives no real additional security above that of just a single factor such as a password.

Multi-factor authentication is certainly possible without human intervention.

However, it requires a frame challenge.

When dealing with humans, the three typical factors for authentication are something you know (password), something you have (TOTP device/program, phone with SMS, access to an email account, etc.), and something you are (biometrics). You can not combine different things from the same factor and call it multifactor authentication. I.e., a fingerprint and a retina scan is not 2FA, but a fingerprint and a password is 2FA.

Biometrics doesn't work over a network, whether you're scanning a human's fingerprints or you're "fingerprinting" a computer, since you can't verify that the client isn't lying unless you have a trusted agent standing by. "The client is in the hands of the enemy." -- Raph Koster (Game designer, not security expert, but the advice is well applied.) Without that trusted agent, biometrics are only useful for identification, not for authentication(*).

The next authentication factor, something you have, is usually indistinguishable from something you know when you're a computer. TOTP seeds, passwords, session tokens, RSA private keys, and so on are just bytes to a computer, and at some point will reside in RAM. Humans can get away with having TOTP seeds, session tokens, cryptographic keys, and the like be second factors, because humans are very unlikely to be able to memorize these, so they need access to separate hardware (or at least something written down).

However, there are things that a computer can't "know" ahead of time. If you have a hardware device that performs cryptographic operations and stores the private key inside in a way that can't be copied (without obvious evidence of tampering), such as a U2F dongle, then this qualifies as something the computer has but doesn't know. Similarly, information sent out-of-band can also be considered something the computer has, rather than something it knows. For instance, a token can be emailed, FTPd, or sent through SMS. Depending on your threat model, simply opening a connection on a different port may be good enough to fool automated surveillance tools, though I wouldn't trust it against an active eavesdropper.

Speaking of threat models, the current threat models against users using passwords isn't the fact that it's just one factor. The threat model is that most users reuse passwords, have low entropy passwords, and that nearly every human's data has been included in multiple data breaches, including many data breaches that have never been detected or reported. Since computers don't have any problem memorizing very long and truly random passwords, and can memorize every password that's given to them, it is trivial to set up a unique, high entropy password for every service account.

Footnotes:

(*) Identification is different from authentication in that, I can identify myself as the queen of Mars, but I can't be authenticated as the queen of Mars. A username is identification, but a username and password is authentication. A fingerprint is identification, but a fingerprint taken with a trusted agent overseeing the process is authentication.

Network location as "something you are"

One way to improve the security of services that need automated connection to specific accounts is to augment secure authentication (e.g. a tls/ssh client certificate) with strict networking limits - if an automated service needs to connect twice a day from system A to system B, then system B should not only authenticate the request, but refuse any connections for that service/port/account that aren't coming from the IP address of system A.

Uncopyable credentials

Another way to approach the secrets of automated services is to have them be uncopyable, i.e. that the software running the business logic doesn't have full access to these credentials, but only a link to a 'signing system' on a HSM or "software-HSM", which generally don't allow extracting the secrets but only their usage in a restricted way. In that case if the main system is compromised, it still can't copy the secrets to be used at will later, they can only access them real-time without being able to circumvent logging, rate-limits, and other restrictions.

2FA for service accounts is not needed and it would be a pain if you would actually set it up.

Imagine you would potentially have like 100 service accounts, every time your system would shut down and you would have to re-authenticate, you would have to confirm the 2FA every time by yourself, if you wouldn't do this, the 2FA would be pointless.

Ways to secure a service account:

• Rotate passwords frequently (there is no human that needs to remember the passwords, you could potentially rotate them every week)


• Make password complexity high (you can potentially use like 24+ characters)


• If it's a Windows environment use Windows service accounts, this option should provide you with enough security.
  https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/service-accounts
  

I am really unsure what the auditors are after with requesting this, but if you provide them with enough proof that your service accounts are secured, you should be fine.

So the crux, certainly in the context of the question, is what level of protection is needed for such service accounts ? What are the risks ? And how can you mitigate these ? And, given the audit angle, can you show how you made that tradeoff ? And are you tracking any residual risks ?

I usually make a simple actor & threath model - paying specific attention to non-functional requirements such as uptime, access in exceptional cases, robustness, governance and organisational fluidity.

In general I find that service accounts then fall into three blocks 1) those which are widely used in the organisation and whose 'power' you can minimise to an extent where the risks of 2FA or other complexity start to outweight the risks of a `shared secret'. 2) Those who are routinely quite powerful as they are what service maintenance, upgrades and what not revolves around and 3) those who are really your ultimate/last resort exceptions - and, while rarely used, where you want to prevent inadvert loss - even when things are dire.

The first class is often shared secrets with good monitoring, governance and what not as mitigators. Or leads you to build a well secured bastion/webinterface on something with solid security - that only allows a few very specific routine operation to be triggered.

For the third class - analysis often finds the introduction of 2FA or similar very undesirable - as they need to work in extreme situations where fragility is an issue. So one often resorts to offline passwords in sealed envelops in safes - to minimie disclosure & theft risk. And get robustness (and salted/hashes on the validation/server end) in return. You then pair this with your physical gouvernance and audit process.

But it is that middle class that is always the issue - very powerful, often used. And sometimes by multiple people. But you really do not want impostors or loss of that level access. Even, or especially, when you are changing staff, learn of a security breach, and so on.

So here the tradeoff is between the `pain' of 2FA versus usability.

In my experience you often find that some sort of 2FA mitigation helps in your overall risk assessment - as it can bring non-clone-ability to the picture while removing the need to cycle things like passwords or the risk of disseminating acces too widely.

Common solutions are sets of x509 or SSH keys on USB tokens or chipcards (sometimes even without a PIN). As these anchor the authentication to a point in time and space.

No to 2FA, yes to Client Certificates

As per Geir Emblemsvag answer, 2FA is only another password. It's somewhat workaround for meat bags humans and their low entropy passwords.

But machines are fast, and could (or better, should) work with very high entropy in every access. No data should ever pass in plain text.

Client Certificate validation on server/service it's a way to guarantee that. It's ensure that data is always encrypted, and you get a service auth and identify for free.