8

It has become clear that asking users to regularly change their passwords does not improve security, and has thus been forbidden e.g. by NIST and BSI.

Does this advice also apply for technical passwords for e.g. service accounts, that are used only for inter-application communication?

Reasons for:

  • expecting regular changes for passwords can lead to mix-ups, sloppy handling (e.g. writing down old and new password for windows ctrl-alt-del dialogue)

Reasons against:

  • these are professionals changing passwords in a clearly specified setting
Improve this question
9
  • 1
    If and how often a password, access token, certificate or otherr kind of authentication need to be changed depends on how strong they are against guessing and brute-forcing and how well they are protected - including protection at client site, transit and server. It also might depend on the impact a leaked credential might have. Because of this there is no general rule covering all use cases, if and how often these credentials should be changed.
    – Steffen Ullrich
    Commented Feb 18 at 6:39
  • 3
    Something to bear in mind is that these type of passwords are often shared (or at least accessible) by multiple people. So even if you're not doing periodic changes, at a minimum they should be changed whenever someone who had access to them leaves or changes role.
    – Gh0stFish
    Commented Feb 18 at 16:56
  • Do you change service passwords via the ctrl-alt-del dialogue? I would rather suggest automating it via LDAP operations (or via kpasswd from WSL)...
    – grawity
    Commented Feb 19 at 9:45
  • @grawity: the script to do this stopped working (timed out, probably firewall), which prompted this question. IT security advised to use RDP , but the certificate did not validate
    – serv-inc
    Commented Feb 19 at 10:58
  • 1
    "and has thus been discouraged e.g. by NIST" NIST has made it a requirement: "verifiers and CSPs SHALL NOT require users to change passwords periodically." It's an instruction, not a recommendation as discussed here.
    – JimmyJames supports Canada
    Commented Feb 20 at 16:43

3 Answers 3

Reset to default
10

Not changing passwords for application/service accounts, particularly privileged accounts, is almost an academic discussion due to this would (hopefully/eventually) be flagged by an auditor for non-compliance.

Changing these passwords were typically one of the ways to surface unexpected usage. Today there may be other compensating controls, such as controls on where an account can authenticate from, depending on the platform.

Note that in practice it usually isn't possible to detect (audit) if a password is actually different, only that it was changed/reset.

Improve this answer
3
  • 11
    "Note that in practice it usually isn't possible to detect (audit) if a password is actually different, only that it was changed/reset." You can enforce that when setting a new password if you still keep the hashes+salts of older passwords around. That way you can check a new password if it also matches any of the old ones and reject it in that case. But retroactively it would of course not be possible to check that without knowing the clear text password, even with the hashes+salts.
    – Philipp
    Commented Feb 18 at 11:55
  • 1
    I'm a little unsure what you are asserting in the first sentence. If you are subject to audits based on NIST standards, then you would be flagged for not following the NIST standards. I'm not following why that's 'academic'.
    – JimmyJames supports Canada
    Commented Feb 20 at 15:46
  • What standard requires that service accounts change their passwords?
    – schroeder ♦
    Commented Mar 13 at 15:15
8

Normal practice is that service accounts such as lp, ntp, daemon etc. should not be accessible by password. If a user needs to become one of these, then it should only be via a carefully written setuid program or via sudo (which then provides appropriate logging).

Certainly no application should need to become another user by password authentication - it should be designed to work either via setuid programs or by interacting over sockets with a daemon running as the required uid.

Password authentication should not be possible for such accounts, particularly as this gives very little auditability (e.g. from login or sshd).

Improve this answer
6
  • 2
    @Ja1024 Not really, because it doesn't fully answer the question. The answer is restricted to Linux login accounts where access without a password is possible, but the question is broader than that and asks about "technical passwords for e.g. service accounts, that are used only for inter-application communication?". There are many services out there where it's not possible to avoid password access so the question remains whether they should be changed frequently or not.
    – Jon Bentley
    Commented Feb 19 at 16:41
  • @JonBentley, I never mentioned Linux. This answer is relevant to the whole Unix family of OSes.
    – Toby Speight
    Commented Feb 20 at 12:50
  • Also, the "many services out there where it's not possible to avoid password access" ought to be patched so that they are accessible by non-password means. It's a solved problem, and "not possible" sounds to me an excuse rather than a sober analysis. Perhaps you should give an example of a service account that requires interactive login other than via sudo.
    – Toby Speight
    Commented Feb 20 at 12:53
  • @TobySpeight "I never mentioned Linux." - a minor nitpick that, while correct, doesn't change the spirit of my comment. "ought to be patched so that they are accessible by non-password means." - sure, but in the real world we can't go around patching every third party service that we don't control. For example, what if your software needs to interface with some government server (e.g. to submit a tax return) and the only login method is with a password? You can't force the government to change its API. All we can do is decide on a sensible policy to secure the way we access that API.
    – Jon Bentley
    Commented Feb 20 at 13:07
  • Ah, I see @Jon - you're talking about the "service passwords" side of the question, but I'm only addressing the "system accounts" side in this answer. I hadn't interpreted the question the same way that you did.
    – Toby Speight
    Commented Feb 20 at 13:41
2

PAM platforms are set up to change passwords for key accounts after each use.

Service accounts can use max length random strings as passwords.

The advise is not to change user passwords because of the high likelihood of password mishandling.

If you are issuing passwords to service accounts via automated systems with strong password creation settings, then you are already satisfying the needs of those standards. So, no, you don't need to configure password expiry.

If you want the benefit of a changed password, then use a system that changes them constantly, not on an arbitrary schedule, and thereby get the maximum benefit for no extra cost.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.