All UC Berkeley IT Resources and all devices connected to the UC Berkeley network or cloud services must comply with the Minimum Security Standard for Networked Devices (MSSND). The recommendations below are provided as optional guidance to assist with achieving the Use of Authentication Requirements.
- Network services and local (console) device access must require authentication by means of passphrases or other secure authentication mechanisms (e.g. biometrics). Notably, the following network services must require authentication: proxy and gateway services, email (SMTP) relays, wireless access points, remote desktop, SSH shell access, and printer administrative interfaces.
- Services and devices that explicitly provide unauthenticated access to Protection Level 1 data (for example: public web servers and public kiosks) are an exception to this requirement, provided they can do so without allowing it to be used by attackers.
- Simple devices like printers, game consoles, DVR’s, media extenders, network attached storage, and router/firewalls that don't support local authentication are exempt from this requirement provided that physical access is restricted. This exemption does not extend to network-facing services running on the device.
- Wireless access points must require industry-standard, strong encryption to connect (such as WPA2), or use a captive portal or some other strong mechanism to keep casual users near the access point from using it to get full access to the UC Berkeley network. WEP or MAC address restrictions do not meet this requirement.
- All network-based authentication and stored authentication credentials (e.g. passphrases, SSH and TLS private keys, and API keys) must be encrypted using industry-standard, strong encryption mechanisms. Unencrypted services such as Telnet, FTP, SNMP, POP, and IMAP must be replaced by their encrypted equivalents.
- Authentication credential stores on servers must be salted and hashed according to NIST guidelines.
Authentication helps keep unauthorized people from using computers, electronic devices, IT services, and applications. It also provides a way to audit access to electronic systems and services.
Risks of not requiring authentication:
- Any computer or device on the campus network that runs unauthenticated network services is likely to be found by attackers and compromised or abused.
- Unencrypted network authentication exchanges present the possibility that credentials can be intercepted by attackers and used to gain unauthorized access to the system
- Devices that do not require authentication for physical access may allow unauthorized people to install malware or steal your data
- Full-featured operating systems like Windows, Mac OS, and Linux must be configured so that all user accounts have passphrases, and those passphrases are required to login to the system locally or to use the system remotely (e.g., via Remote Desktop, file and print sharing, or other services).
- Authentication using integrated biometric capabilities of supported devices from major vendors is also acceptable.
- Mobile devices must require authentication (passphrase, PIN, biometrics) to unlock the device. The Information Security Office recommends against using an unlock pattern to secure your mobile device.
- When logging on to web applications, always be certain that HTTPS is being used for the authentication session (look for a lock in the URL field); otherwise, credentials will be exchanged unencrypted and exposed to potential attackers.
- Remember to logout of browser applications to delete cookies and invalidate the session.
- Always logout of shared computers or kiosk systems when finished. Refer to the Campus Guidelines for Kiosk Workstations for detailed recommendations.
- Try to avoid “Remember me on this machine”, especially for services that deal with sensitive information.
- Whenever possible, use multi-factor authentication (MFA). The campus uses Duo for MFA for most campus services. If using cloud services and MFA is available, then it is recommended it be used.
For Service Providers:
- Email (SMTP) servers that do not support encryption and authentication (SMTP AUTH) must request an exception through the policy exception process.
- Proxy servers must also require authentication before forwarding or relaying traffic to other hosts.
- Network services that do not support authentication, e.g. printing, DNS, and NTP, should be evaluated for misuse and protected accordingly.
- Require re-authentication for access to sensitive applications in order to mitigate cross-site request forgery and session hijacking.