I'll need to use an hardware token, specifically the SafeNet eToken 5110 that comes with DigiCert's EV certificates, for code-signing on Windows.
I know that they issue a prompt to manually enter the token's password at each signing attempt (or at each session, if you enable the single logon option).
How safe are those prompts from keylogging or other password interception techniques?
And thus how much would I increase security by really filling those prompts manually vs. automating them with methods such as those listed here ?
I know that by automating the process I would increase the attack surface, by the fact that the password will probably be stored on disk and for sure on various additional memory locations, but I have a feeling that these software password prompts are nonetheless mostly "security theater", and that there are easy ways to intercept the password (and thus have it later entered programmatically by a malicious program) even if manually typed .
Here I assume that the computer where the token will be used will be an up-to-date Windows 10 system reasonably hardened, so for sure at least not running under an administrative account. It certainly won't be fully isolated though (one way or another I'll have to pass the files to be signed to the system).
I realized that this environment description might be too vague, if that's the problem for the time being we can assume instead a fresh Windows 10 installation, running under a limited account, with decent passwords for that and the administrator's account, connected to the internet through a lan and let's say even joined to a domain.
The rest of the lan is not to be considered really safe.
Let's just add that Windows' privacy options have been all set to deny, just to take out the possibility that Windows sends out the password to its servers to "improve typing", which wouldn't surprise me too much.
I'm not concerned about physical attacks here.
I found the eToken 5110's FIPS 140 security policy. I gave it a quick look but I didn't get too much from it, it doesn't seem to be concerned with the part of the password entry from its typing to when it gets sent to the device.
I think (but not 100% sure) that it is a USB CCID device and that it uses the Microsoft Class Drivers for USB CCID Smart Cards, and that this entails that the password entry is handled mostly by the operating system, rather than by code from the vendor (but again not 100% sure).