The LSST security policy, LPM-121, states “[LSST] is inherently multi-site...established organizations providing extant security policies and procedures that apply to LSST activities at their sites”. Thus, for the Project Office in Tuscon, AURA’s password policy would apply to accounts created on the Project Office’s identity provider (i.e. Active Directory). This is captured in LPM-97, “Project Administration Policies”. Additionally, LSST accounts at the NCSA must adhere to NCSA’s identity and access management policy which contains the password policy (see https://wiki.ncsa.illinois.edu/pages/viewpage.action?pageId=33791874).
Currently, the LSST Project Office and the NCSA are working on a project to unify LSST’s identity management and access systems. The goal of which is to create one system to manage LSST staff and user accounts and groups across multiple sites. This includes allowing federated identities by linking offsite identities with a LSST account. Due to the multi-site nature of this new identity and access management system, a consistent password policy must be adopted. It should be noted that the beginnings of a identity and access management policy already exists in the form of LSE-279, “Concept of Operations for Unified Authentication and Authorization Services”. However, this document does not contain a password policy.
A. LSST passwords are case-sensitive with the following properties for passwords between 8 and 15 characters:
- contains at least one uppercase and one lowercase letter
- contains at least one number or special character
- does NOT contain 4 sequential characters of your login ID
- does NOT contain dictionary words longer than 3 characters
- is NOT the same as the previous password
B. Passwords greater than 15 characters need only: # contain at least one uppercase and one lowercase letter
- NOT contain 4 sequential characters of your login ID
- be different than the previous password
The LSST Information Security Officer or LSST system administrators may require password changes at any time. Often this is due to a change in the unlaying cryptographic hash/algorithm or in the event of an account compromise.
Note that this policy adheres closely to NIST 800-63B’s guidelines on Memorized Secrets in section 18.104.22.168 with the exception of requirements A.1., A.2., and B.1. above.
As many have pointed out, the guidelines in NIST 800-63, “NIST Special Publication 800-63-3 Digital Identity Guidelines”, recommend a password policy that does require frequent password changes (see section 22.214.171.124 in 800-63B). However, it should be noted that this recommendation assumes that the NIST 800.53 framework is being used w.r.t. security controls. For example, single factor authentication is only appropriate for Authenticator Assurance Level 1 (AAL1, see section 4.1 in 800-63B) which maps to a SP 800-53 Low Baseline. Many LSST systems, esp. at the base/summit, do not fall under the SP 800-53 Low Baseline if we map LSST security controls to 800-53. Rather, they fall much closer to SP 800-53 Medium Baseline which recommends AAL2: Memorized Secret plus Singler Factor OTP Device (i.e. Duo). This stance will significantly mitigate against attacks using stolen credentials.
If we assume that LSST will deploy 2-factor authentication in a manner consistent with the NIST security frameworks, we can adopt a password policy that is less onerous than the AURA Password Policy and be assured that we are not increasing LSST’s security risk.