Rationales

• Use of them makes auditing access difficult:
  • multiple users appear in audit logs as one user and different users actions are difficult to differentiate.
  • the number of audit logs that need to be searched increases.
  • correlation of events across different systems is impossible if multiple people are creating event records with a single shared account across multiple systems at the same time.
• Revoking access to a subset of the users of a shared password requires a password change that affects all users.

• Using the same password for a class of accounts/sites, for example, using one single password for multiple high value financial accounts, but a different single password for multiple low value forums and wikis.
• Using a consistent reproducible method of password generation for each site, for example, every account/site has a password which begins with the same characters and ends with name of the site ("rosebud0facebook", "rosebud0linkedin")

Password reuse is discouraged because:

• When a site is compromised by an attacker, the attacker can easily take the user's password that has been reused on other sites and gain access to those other sites. For example if a user uses the same password on a car forum website as they use on Facebook, when that car website gets compromised, the attackers can then takeover the user's Facebook account.
• Unethical administrators of any sites where a password is reused may/can gain access to accounts using the reused password.

Note that it is dangerous for a user to rely on a site being able to effectively prevent an attacker from obtaining that user's password once an attacker has compromised the site.

Since it's difficult/impossible for a user to memorize a distinct password for every account/site, a common solution is to use a password manager.

• Manual user account creation by administrators.
• Automated user account creation from scripting or configuration management that creates accounts based on a static list of users.

This practice is discouraged because:

• When a user's access status changes due to leaving the company or changing teams, the associated change in the system which uses decentralized user account management is not automatically made resulting in unintended system access.
• When a user changes an attribute of their account in the centralized account management system, for example their email address or password, that change is not reflected in the systems which use decentralized user account management. Conversely when the user changes an attribute in the systems which use decentralized user account management, that change is not propagated to the centralized account management system.

Requiring the use of MFA for internet accessible endpoints is encouraged because by requiring not only something the user knows (a knowledge factor like a memorized password) but also something that the user has (a possession factor like a smartcard, yubikey or mobile phone) the field of threat actors that could compromise the account is reduced to actors with physical access to the user.

In cases where the possession factor is digital (a secret stored in your mobile phone) instead of physical (a smartcard or yubikey), the effect of MFA is not to reduce the field of threat actors to only those that have physical access to the user, because a secret can be remotely copied off of a compromised mobile phone. Instead, in this case, the possession factor merely makes it more difficult for the threat actor since they now need to brute force/guess your password and compromise your mobile phone. This is, however, still possible to do entirely from a remote location. In particular, storing both first and second factor on the same device (for example: mobile phone) is strongly discouraged.

• identify when a host has been compromised by the network traffic it emits.
• understand the commonalities in a distributed network attack.
• provide incident responders with data needed to quickly diagnose security issues.