Strong Authentication

Passwords do not provide an adequate degree of safety for systems that process or store data elements defined as restricted. Passwords, while easy to use, are vulnerable to a wide variety of attacks and weaknesses including guessing, impersonation, observing, borrowing, snooping and dictionary attacks. Strong authentication methods are needed to reduce the risk associated with these high value systems.

OCIS has adopted the authentication levels specified in NIST 800-63. This standard specifies four levels of authentication with Level 1 being the lowest level assurance and Level 4 being the highest level of assurance. UW Madison will require Level 3 authentication when access to restricted data other than one's own data is needed. Simple usernames and passwords are not acceptable to meet the Level 3 standard.

Instead, the Level 3 standard requires two factor authentication or strong authentication. When using two factor authentication, a user presents a token (something I have) and enters a password or phase (something I know). In addition, the application must know how to validate the token/password information in order to grant access to the restricted data.

This is similar to how an ATM card works. You are able to withdraw money from your account because of something you have (your bank card) and something you know (your PIN). If one of these items is lost/stolen or otherwise compromised, a miscreant could not withdraw money. They would have to possess both factors to access your account. Thus this is a much stronger authentication than simple user name and password.

OCIS has initiatives underway that will move us toward strong authentication.

  • Piloting strong (two factor) authentication to restricted data networks by system administrators, database administrators and application administrator using VPN.
  • Piloting strong (two factor) authentication to encrypted desktop or laptop devices by owners that store restricted data.
  • Evaluating possible two factor authentication to the Shared Financial System application for users who access restricted data.

We will rely heavily on using user certificates for one factor (what I have). Using a certificate stored in a computer’s certificate store on the disk or a certificate stored on a hardware token (e.g., a smartcard or Alladin etoken) both conform to NIST Level Assurance 3 requirements. Check back here for progress related to these projects.