Skip links and keyboard navigation

Reducing password frustration for Queensland public servants

Document type:
Guideline
Version:
Final v2.0.0
Status:
Owner:
QGCIO
Effective:
February 2018–current
Security classification:
Public

Final | February 2018 | v2.0.0 | OFFICIAL-Public |QGCIO

Password frustration can be experienced by computer users who are required to remember multiple usernames and passwords, and is compounded when passwords must be changed frequently.

The result is often a less secure environment as users reuse credentials and store passwords insecurely.

Current QGEA guidance is that users should be required to change their authentication code after a predetermined period of time. It is a matter for each agency to perform a risk assessment and set the password change frequency, with more complexity requiring less frequency of change, taking into account other access controls.

The following recommendations are based on the advice in the most recent NIST guidelines on Digital Identity. The NIST guidelines are updated on a regular basis and represent better practice in this area.

Recommendations

A password lifetime of 12 months may be suitable provided:

the password has adequate strength so that it cannot be brute force cracked within 12 months by a motivated attacker using current technology

  • the password is not shared
  • the password is not sent over a network in unencrypted form
  • the user account is locked after a minimal number of unsuccessful password attempts (e.g. 5)
  • there have been no security compromises in the system when this occurs, it may be necessary for ALL passwords for the system to be changed immediately
  • system accounts and privileges are well managed for staff movements, especially removal of access at the termination of employment or change of role.

DO

  • Undertake a risk assessment to determine password policy. Security needs to balance confidentiality, integrity and availability of systems. Password complexity is only one control of many.
  • Make your password policies as user friendly as possible.
  • Explain to users as to why when chosen passwords are rejected (e.g., when it appears on a black list of unacceptable passwords or has been used previously). Advise users that they need to select a different secret because their previous choice was commonly used.
  • Implement account lockouts after unsuccessful attempts to protect against password brute forcing.
  • Use tools and techniques to support user password management, such as like password managers and single sign on.
  • Use multi-factor authentication (MFA) where a high identity assurance level is required, for example remote access and administrative consoles.
  • Mandate a minimum of 8 character passwords, but determine requirements based on risk. Increased system privilege should equate to increased minimum password length.
  • Allow a password maximum length of at least 64 characters.
  • Ensure that applications allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji!
  • Check new passwords against dictionaries of known-bad choices.
  • Let people choose freely, and encourage longer phrases instead of hard-to-remember passwords or deceptive complexity such as p@zzw+rdz.
  • Separate day to day user accounts from accounts with elevated privilege, such as administrative accounts.

DON'T

  • Reuse passwords across multiple systems
  • Reuse similar passwords over time
  • Expire passwords without reason If you want users to choose long, unique and hard to guess passwords, that they don't write down Don't make them change them unless they've forgotten them or you suspect the password has been compromised.
  • Have design rules for passwords that are imposed on users. No more arbitrary password complexity requirements needing mixtures of upper case letters, symbols and numbers. Like frequent password changes, its been shown repeatedly that these types of restrictions often result in poorer passwords.
  • Allow applications to store passwords in the clear text (salt of 32 bits or more, a keyed HMAC hash using SHA-1, SHA-2 or SHA-3, and the stretching algorithm PBKDF2 with at least 10,000 iterations)
  • Allow password hints
  • Allow Knowledge-based authentication (KBA). KBA is when a site says, Pick from a list of questions Whats your first pets name? Whats your favourite Netball team? and tell us the answer in case we ever need to check that its you.

Those agencies that are required to adopt the Federal Government Information Security Manual (ISM) for specific systems should follow the requirements outlined by ASD www.asd.gov.au

Other issues

  • NIST has published 800-63-3 Digital Identity Guidelines which are regularly updated. Agencies may find these guidelines of use.
  • Password managers may assist users to securely manage their passwords.
  • Password management policy can be dependent on the features of the specific application being accessed (e.g. password strength enforcement and lockout policy).
  • Applications that support proxy authentication schemes (e.g. Aurion 10 supports NTLM) can participate in single-sign-on regimes that reduce the burden of remembering multiple passwords that change regularly.

Examples

Passphrases easier to remember hard to crack

A random unique passphrase

Tree paddle diamond

Key length 19

Entropy (randomness) around 86 bits

285 Combinations hundreds of thousands of years to crack

Screw trowel truck

Key length 18

Entropy around 85 bits

285 Combinations tens of thousands of years to crack

paper sushi cat

Key length 15

Entropy around 55 bits

255 Combinations thousands of years to crack

tiger kinder

Key length 12

Entropy around 39 bits

239 Combinations hundreds of years to crack

Of course - don't use these exact ones!