Skip to end of metadata
Go to start of metadata

UH Secure Passwords Practices

  • Password policy version: 12/07/2009
  • Password policy implementation date: 04/08/2010 06:30 AM
  • Password policy: password strength
    1. Passwords must be a minimum of eight characters long, maximum length is 32 characters long.
    2. Passwords must contain at least one lowercase, one uppercase, one number, and one special character (see reference).
    3. Passwords must not be obvious (e.g. not be a: dictionary word or combination of words, your name, your UH Username, etc.).
    4. The owner shall be required to change temporary passwords at the first logon or within 7 days.
  • Password policy: personal responsibilities
    1. Passwords shall be kept confidential at all times.
    2. Passwords shall not be used in any unsecured automated logon process.
    3. Passwords shall be changed as soon as possible if there is an indication of possible system or password compromise.
  • Password policy: password administration
    1. Require strong passwords for all UH Usernames.  As of this policy's effective date, strong passwords will be required for all new passwords and all password resets.
    2. Require as part of the password reset process a confirmation that the owner understands and agrees to the applicable policies governing usage.
    3. Provide guidelines for creating strong, yet easily remembered passwords:  Password Selection Guidelines.

Questions and Answers

  • Question: why do we need stronger passwords? They are harder to create and remember.
    • They are much more secure and do a much better job of protecting your privacy. The UH ITS Security office has seen a number of UH Username compromises. Weak passwords are one of the reasons why UH Usernames get compromised. There is an abundance of software on the internet designed to probe our services and test for weak passwords.  Additionally, the University is preparing to join the InCommon Federation so that members of the UH community can, in the future, access additional resources with their UH credentials (UH Username and password).  The InCommon Federation provides operational guidelines specifying, among other things, strong passwords.
  • Question: do passwords expire? Are we going to have to change our passwords periodically?
    • No.  At this time passwords are not aged and do not expire.
  • Question: I already have a strong password.  Will I have to change it when the new policy is implemented?
    • Not at this time.  At some point in the future you may be required to change your password so that we have recorded the fact that you have created a strong password.  
  • Question:  If I change my password now, will it have to be one of the new, strong passwords?
    • Yes.  Once this policy is in effect (see effective date above), all new and newly changed passwords will adhere to the strong passwords rules.

Guidelines for Applications Developers

  • LDAP Authentication:  when designing an application that includes authentication logic, implement logic to resist brute force attacks by detecting and responding to a failed authentication event. With each failed consecutive authentication add 5 additional seconds delay between processing of a new password attempt. The delay between the first and second password attempts for a single user would be 5 seconds, between the second and third would be 10 seconds, etc.
    • On a related note: LDAP returns err=0 for successful authentications, err=19 if LDAP is resisting a brute force attack and has temporarily suspended the password (usually for a few minutes), err=49 if the credentials are invalid.
  • CAS Authentication:  UH provides authorized developers with a centralized authentication solution based on CAS technology, the UH Web Login Service. This is the recommended solution for authentication with UH credentials (UH Username and UH Password) and provides users with the best security.
  • Application Testing: Users have fairly wide latitude in selecting passwords of varying lengths and character composition.  If your application imposes limitations on either, the limitations should be mitigated if possible, or else documented.  For example, Wireless authentication on the ITS RADIUS server limits password lengths to 48 characters; UH Webmail has a bug that disallows the use of '(' and ')'.
    • Your application should be tested to ensure that password limitations are known and mitigated or documented.  VIA accounts may be established and used for testing.  (VIA)
  • No labels