Passwords
Each (human) user of a system component needs to be identified and authenticated for all access. For that purpose, passwords can be used.
Further authentication methods can be, for example, biometrics (e.g. finger print scanner, face recognition), tokens, physical keys, key cards or evaluating the geographic location of the user.
You must set up a User and Role Management accordingly. There, authorizations are granted to each user role which define the access type and permitted operations to system components or data.
Password rules
- Definition of a password policy
A policy which rules the definition and handling of passwords should be defined and implemented for your ICS. This policy should fulfill the following requirements:
- Users are forced to define strong passwords by technically preventing the definition of weak passwords. Strong passwords result from their complexity: a combination of upper and lower case letters, numbers and special characters and a minimum length should be mandatory.
Especially with regard to brute force attacks, the length of a password is decisive. (Brute force attacks refer to the software-supported "finding out" of a password by trying out all possible combinations of letters and digits.)
Example: A password consisting of, for example, 7 lowercase letters corresponds to 267 possible combinations. A powerful software tool may determine such a password within only a few seconds. By using all uppercase and lowercase letters plus digits and special characters and extending the password by one character to 8, the same attack needs up to a day. When using 15 characters, a "successful" attack may take years. - Passwords should have a time-limited validity, i.e. they must expire after a reasonable period of time. Before a password expires, the affected user must be prompted to change the password. At this point, the change algorithm should not accept the same password again.
- The number of incorrect password entries can be limited. If the defined value of goodwill logins is exceeded in such a scenario, the user can be blocked and must contact the administrator.
Note: This measure may not be suitable for all ICS types. Blocking after a brute-force attack would prevent the user from logging on (even in an emergency case where a quick reaction is necessary).
- Users are forced to define strong passwords by technically preventing the definition of weak passwords. Strong passwords result from their complexity: a combination of upper and lower case letters, numbers and special characters and a minimum length should be mandatory.
- Handling of default user names/passwords
If possible, delete or at least deactivate (factory-set) default users/passwords from any component involved. If not deletable, change preset passwords to secure passwords which comply to your above mentioned password policy.
Note: Prior to modifying, deleting or deactivating default user names/passwords, make sure that the plant is still operable/controllable afterwards.Note: Never transmit passwords unencrypted (see topic User Management for details). Even without central user management, users tend to use the same password for multiple applications. As a result, a compromised password could have security consequences in multiple systems.Note: Passwords are usually stored "self-encrypting" on systems and servers, so they cannot be decrypted, but only disclosed through systematic guesswork or brute force. Also read the remarks in section Pre-shared Keys (PSK).
Use cases
Practical use cases for authentication using passwords