Xjyuk

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.