If no one knows a password, is there a reason to change it?

Question

Scenario: A high level access account on a single machine, where the account is created by the system/application with a secure password, without exposing the password to a human or to any other machines.

No one knows or can know the password. (Hypothetically the password could be extracted but only if the system is already compromised at the level of access the account has.)

Assume you are watching for and reporting on failed login attempts, you would know if anyone was trying to brute force the password.

The Real scenario where this occurs, the argument is presented that changing the password, could/would raise the risk.

This leads to an argument where there is no good reason to actually change the password on a regular bases. You might want to change it on day one, if you don't trust the random password generation, but even that could add more risk then it removes, as now the password has been seen and processed with human contact.

If no one knows a password, is there a reason to change it?

Note: The example account exists as there is an alternate configuration of this solution, where the account is used to communicate between machines. In the alternate solution the password is known by humans, and shared across devices. The current question is only about the single machine scenario.

Answer 1

If you believe human contact to be the ultimate security risk, then what you're saying makes sense.

But if you don't regularly change a password, then someone who was able to access the machine from an unknown vulnerability will have unlimited access to the system, forever.

Ultimately, I believe human contact to be necessary even if it's risky, maybe impose laws and bind a single senior security engineer to a contract that would put them in heaps of trouble if the password were to ever reach any sort of exposure?

( Either way, I believe it's impossible to have a no risk solution )

Answer 2

If no one knows a password, is there a reason to change it?

As long as that assumption holds, then no, there is very little reason to (periodically) change the password. In fact, even the NIST has done away with that requirement for a while now, as described in section 5.1.1.2 of this publication. And Microsoft has stated pretty much the same back in May:

Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem.

So, then when do you change a password? If there is evidence, or at least a reasonable assumpion, that the secret has been compromised. In that case, change it immediately after the vulnerability has been patched. On an unpatched system, any new secret should be considered compromised immediately.

Answer 3

This is the rare case where password changes may not be necessary.

You would need to have bulletproof monitoring for both failed and successful logins because if an unauthorized person does discover the password, they would never be locked out by a regularly-scheduled password change.

The auditing of successful logins should include at a minimum the source of the authentication so you can identify remote access, and ideally it would correlate transactions to each auth session for review in case anything unusual occurred.

Of course, following the guideline about changing passwords during personnel turnover would still be wise. If an admin who could recover the password either moves to another role or leaves the company, the password should be changed immediately thereafter.