1

We are in a mid-sized enterprise environment and are looking at forcing specific passwords for all users. I've found nothing recent or relevant about this.

Justification:

  1. The main reason is to ensure that personal passwords (often compromised) are not used in our environment. Go ahead and use your LinkedIn password for your bank account, just keep it out of my environment.

  2. IT is familiar with generating long, full charset, but still highly memorable passphrases. Whereas a user facing a 14 character minimum might immediately forget what they just entered. correct horse battery staple, baby!

  3. Entropy. What's better than generating your own passphrase? Having a password nerd admin who knows what "random" actually means do it for you.

  4. The company culture supports it. Users are coddled. Help Desk staff keeps an encrypted list of passwords because users assume we can log in as them on a whim. In our case, the risk of someone in IT setting the world on fire doesn't lessen by setting passwords. That risk is inherited by the trust bestowed upon us by users. They want (ugh, need) IT to have their password.

  5. Microsoft has just changed their tune about password expiration policies, placing more weight on length and charset. More of a selling point to the change. "Ok you don't have to change your password as often, but in exchange, we're going to set a secure one for you"

  6. All accounts still sit behind MFA, maximum login attempt policies, etc. No reason to stop using common sense now.

This all reeks of a "we know better than you" mentality but other than that, what are the pros and cons?

Improve this question
4
  • 3
    One big con: what is theoretically a "memorable" method may not in individual instances actually be very memorable. Maybe it's a word they consistently misspell, or it accidentally forms an offensive sentence. If you go this route, maybe consider giving the users a choice of a few generated phrases to pick from, rather than "thou shalt use exactly this one password".
    – Ben
    May 3, 2019 at 15:32
  • 1
    Offensive combinations were a concern as we've seen this in the past using diceware lists. And I agree with the 'mermorability' of certain phrases. I like your idea to present a few passwords and have the user decide which one they prefer.
    – jemibu
    May 3, 2019 at 16:00
  • All I can see is any knowledgeable user will start using password manager.
    – mootmoot
    May 3, 2019 at 16:18
  • 1
    I would hope that this encourages people to use a password manager. Correct, IT staff can change but the user cannot.
    – jemibu
    May 3, 2019 at 16:25

1 Answer 1

Reset to default
1

There are two massive cons: attribution and liability. Although this is currently a reality in your company, this does not mean that it should continue.

All it will take is for someone with access to the password to do something negligent or malicious with someone else's account, and you will need to change this policy instantly. You will have no idea, or even a reasonable understanding, about who did the negligent or malicious thing, and all it will take is a user to say, "it wasn't me - it must have been someone in IT".

So, as you suspect, in your current reality, choosing passwords for your users should actually make your passwords stronger against the outside threats against those accounts. But for the inside threat, you have a gaping maw of risk.

Improve this answer
5
  • 1
    Thanks for the feedback. I agree with everything you've said, especially liability. But I don't see a silver bullet here. It's an argument of internal threats against external ones. And in our culture, since we got the first Wang terminals, has leaned on the trust of internal IT. I agree with you that it needs to change.
    – jemibu
    May 3, 2019 at 16:23
  • You are absolutely correct. There is no silver bullet. Password policies exist to address risks. You need to have the policies and then the controls to enact those policies in such a way to address those risks, and then to have controls in place to minimize the residual risks after your controls.
    – schroeder ♦
    May 3, 2019 at 16:29
  • If IT having access to username/password combinations breaks the ability to attribute, then is there some "multi factor" equivalent possible? For instance, users have to log in with both their username/password and an RSA token that IT doesn't have access to. Or their username/password and an rfid badge. And so on. I know we may be getting away from the realm of what's possible for the OP in their specific environment, but it seems like there should be some way to attribute access even with shared credentials.
    – dwizum
    May 3, 2019 at 18:03
  • @dwizum Thanks for the thoughs. We use multifactor for all external connections. This works in our favor in a practical sense but I don't know that it fully addresses the concerns of the policy itself raised by schroeder. In theory, an insider with knowledge of the infrastructure may find a way to circumvent MFA. Regular external audits and pen testing mitigate this risk but it's not outside the realm of possibility.
    – jemibu
    May 3, 2019 at 19:14
  • If the concern is attribution or liability, then my point was, can you use a version of MFA that specifically addresses that? For instance, require that all employees have badges with smart cards. The card is generated by a third party and IT can't make their own version of your card. Anyone logging on (including IT) has to also insert their card. The authentication mechanism records the card that was inserted. This ties the use of any username to whichever person was logging in with it but still allows for your desired "IT knows your password" policy.
    – dwizum
    May 3, 2019 at 19:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .