Many applications provide functions that require user authentication. The most common form of authentication involves passwords. There are a few principles that apply to application use and management of passwords, and some clear do’s and don’ts for application developers.
Principles For Application Password Management
Principle 1: Don’t touch the password!
It is best for an application to isolate itself from touching the password in any way. This is most commonly done through single sign-on (SSO) methods implemented by infrastructure components, using technology such as Shibboleth or Central Authentication Service (CAS).
At UCSB, both CAS and Shibboleth are available. CAS should be used when authentication is limited to users with UCSB NetIDs. Shibboleth may be used with federated IDs, i.e. users who authenticate to other trusted organizations, like other UCs. SSO has the benefit of reducing the number of times that a user must authenticate themselves to different applications. You can find information and code samples for leveraging CAS at https://secure.identity.ucsb.edu/inside/doku.php/sso_home. When you are ready to implement CAS or Shibboleth, contact the Identity support team at http://www.identity.ucsb.edu/help/.
Principle 2: Don’t enable password validation.
Sometimes it is not possible to use SSO methods, and the application developer has no choice but to ask a user for their password. This act places a great deal of responsibility on the application to safeguard the user’s secret, since anyone with knowledge of the password can impersonate a user. For this reason, passwords must never be cached or logged. The password must never be transmitted across a network in an unencrypted form. TLS offers the best protection in a standard implementation.
An application that must touch the password should use authoritative sources to validate it. This also removes the requirement to maintain the password from the application and puts it on infrastructure. An example is using a managed LDAP directory server to authenticate against. The user manages their password through the infrastructure and all the application is left to do is validate the password at the time of use. Scrubbing memory after the validation limits the possible exposure of a user’s password.
Principle 3: Never store passwords.
If an application must maintain and process its own passwords, then it is incumbent on the application developer to do this correctly. Passwords should never be stored directly in any database, nor should they be stored in a way that permits obtaining a password from an encrypted source. If you absolutely must store passwords, please review this OWASP guide.