35

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?

  • 2
    Assume for the moment the service you're authenticating against is 3rd party. That means you'll have to automate 2FA for a service intended for a human, but now needs to be automated. That sounds like something just waiting to break if the 3rd party changes the way the 2FA works where I human wouldn't care, but automation might rely on the old structure. – Steve Sether Jul 31 at 19:14
  • 2
    In some environments it's possible to set up service accounts where either interactive login is impossible, or the login can only be done by key credentials of some sort. – pjc50 Aug 1 at 10:39
54

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.

  • 23
    Agree! A 2FA token is just another password. Make the service password a random, large password, and you are done. 2FA will not bring much security, and will be a moving part waiting to break. – ThoriumBR Jul 31 at 21:24
  • The significant difference between a password and a TOTP token is that the OTP seed is never transmitted. So if there is a risk of interception and replay, an automated OTP would act as a kind of nonce, rendering intercepted traffic much less useful to an attacker. However, this would only be required if the system you're connecting doesn't implement a stronger authentication system anyway. – IMSoP Aug 2 at 14:03
  • Definitely, if you have a choice of authentication mechanism don't go for password. The most practical choice would be to use some form of public key crypto. – Geir Emblemsvag Aug 2 at 15:32
  • There are of course password-based authentication systems that do not transmit the password itself, eg zero-knowledge proofs. – eggyal Aug 3 at 18:10
27

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.

  • Actually there are a number of schemes to use Biometrics for authentication over networks. Though, I think its really that the biometrics are used on device only and under the hood everything is really PKI. fidoalliance.org/how-fido-works – Joe Aug 1 at 11:08
  • There could probably be ways to create a non-reusable retina-scan with a single service. You could record a video of the retina and send it to the server for authentication and the server could use some (currently probably not available) hashing technique to check if the same video was reused or is an original new recording (the technique to verify this would need to be able to differentiate a true new recording from an old recording with some photo shopped changes) – Falco Aug 1 at 13:18
  • So if I understand you correctly, allowing a connection from only a specific IP or computer name and using a service account/PW would be considered MFA? – Jammin4CO Aug 1 at 14:25
  • 1
    @Jammin4CO, if that connection was completely unrelated to the connection that you're trying to authenticate through, was originated from the authentication server, and set up in order to send an out-of-band one-time-use token, then yes... It's not just a new connection, but the fact that it's out of band and out of control of the client that makes it a separate factor from just something you know. – Ghedipunk Aug 1 at 15:29
  • @Falco How do you do a retina scan without a human being involved? If a human has to be involved, it's not automated, and therefore is not a [software] service account. (It's just a regular, human account, where a software service happens to provide the password (one of the factors).) – jpaugh Aug 2 at 19:36
8

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.

  • I was going to answer myself. You did it! Uncopyable credentials (i.e. certificates, TPM, hardware attestation) are the way. And I am actively working on that – usr-local-ΕΨΗΕΛΩΝ Aug 2 at 8:03
4

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:

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.

1

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.