Authentication for a batch script

Question

It seems amazing that there is no industry accepted best practice for this problem yet (or maybe just one I'm not aware of):

What is the most secure way for a batch script, a program needing to connect to a resource (E.g. database) via a non user driven interaction to authenticate? Technology agnostic answers are best, but if there is a big different based on the OS (Windows, Unix, Mainframe etc), database or program language that is also useful to know.

It would be good if you can state why the solution (or options in preference order) is secure (e.g. it protects against malicious internal users, external attackers, malware in these ways). Also why it has a low operational impact (change, maintenence etc).

E.g. my list:

IMO best preference (most secure) to least:

• Certificate based authetication where the cert is stored in a HSM
• Certificate based auth where the cert is stored in a software crypto module
• Certificate based auth where the cert is the certificate store of the OS -- generally needs root to get access so game is up if this occures
• Externalised authentication based on an LDAP
• Password based where the password is encrypted and stored in a different server or password vault. Only service account is authourized to connect, decrypt and retrieve the password over secure transport (basically how TDE works with Oracle Wallet)
• Password based where the password is encrypted and stored on the server. Service account can decrypt only.
• Password based where password is stored on the server but protected by OS perms and is excluded from backup (manual backup in password vault).

Certificate is best by far and the defacto method for anything like Amazon EC2, Github etc.

Please close and redirect if this is answered already. I couldn't find it when I searched.

Answer 1

The answer depends upon the threat model, and what threats you are trying to prevent.

A standard strong method is to use public-key based authentication, such as the following examples:

• The client connects by SSH. The client authenticates using its personal DSA key (not protected by any passphrase). Or,
• The client connects over SSL. The client authenticates itself using a suitable client certificate. The client checks the server's certificate to make sure it is talking to the server it expected to talk to.

This approach is pretty good for most settings. It is secure against network-level attacks. Of course, the client's private key lives in the clear on the client machine. (It pretty much has to.) As a consequence, any attacker who breaks into the client machine can steal the client's private key.

If you need to detect against the threat of a compromise of the client machine, you could store the private key in a HSM or smartcard connected to the client machine and have it authenticate in that way. This provides modest security benefits: an attacker who compromises the client machine can no longer steal the client's private key, but the attacker can still make arbitrary connections to the server as the client and send arbitrary data, for as long as the attacker maintains its control over the client. Whether this is a security improvement or not (compared to just storing the private key in the clear on the client) depends heavily upon the application. Also, whether this is worth the extra cost and hassle of the HSM or smartcard is heavily dependent upon the application as well.

There are other approaches as well with some slight advantages and disadvantages compared to the above, but nothing that is overwhelmingly superior.