Improving Password and Authentication Security

Improving Password and Authentication Security
	Chapter 12. Administering User Accounts

AFS provides several optional features than can help to protect your cell's filespace against unauthorized access. The following list summarizes them, and instructions follow.

Limit the number of consecutive failed login attempts.
One of the most common ways for an unauthorized user to access your filespace is to guess an authorized user's password. This method of attack is most dangerous if the attacker can use many login processes in parallel or use the RPC interfaces directly.
To protect against this type of attack, use the -attempts argument to the kas setfields command to limit the number of times that a user can consecutively fail to enter the correct password when using either an AFS-modified login utility or the klog command. When the limit is exceeded, the Authentication Server locks the user's Authentication Database entry (disallows authentication attempts) for a period of time that you define with the -locktime argument to the kas setfields command. If desired, system administrators can use the kas unlock command to unlock the entry before the complete lockout time passes.
In certain circumstances, the mechanism used to enforce the number of failed authentication attempts can cause a lockout even though the number of failed attempts is less than the limit set by the -attempts argument. Client-side authentication programs such as klog and an AFS-modified login utility normally choose an Authentication Server at random for each authentication attempt, and in case of a failure are likely to choose a different Authentication Server for the next attempt. The Authentication Servers running on the various database server machines do not communicate with each other about how many times a user has failed to provide the correct password to them. Instead, each Authentication Server maintains its own separate copy of the auxiliary database file kaserverauxdb (located in the /usr/afs/local directory by default), which records the number of consecutive authentication failures for each user account and the time of the most recent failure. This implementation means that on average each Authentication Server knows about only a fraction of the total number of failed attempts. The only way to avoid allowing more than the number of attempts set by the -attempts argument is to have each Authentication Server allow only some fraction of the total. More specifically, if the limit on failed attempts is f, and the number of Authentication Servers is S, then each Authentication Server can only permit a number of attempts equal to f divided by S (the Ubik synchronization site for the Authentication Server tracks any remainder, f mod S).
Normally, this implementation does not reduce the number of allowed attempts to less than the configured limit (f). If one Authentication Server refuses an attempt, the client contacts another instance of the server, continuing until either it successfully authenticates or has contacted all of the servers. However, if one or more of the Authentication Server processes is unavailable, the limit is effectively reduced by a percentage equal to the quantity U divided by S, where U is the number of unavailable servers and S is the number normally available.
To avoid the undesirable consequences of setting a limit on failed authentication attempts, note the following recommendations:
- Do not set the -attempts argument (the limit on failed authentication attempts) too low. A limit of nine failed attempts is recommended for regular user accounts, to allow three failed attempts per Authentication Server in a cell with three database server machines.
- Set fairly short lockout times when including the -locktime argument. Although guessing passwords is a common method of attack, it is not a very sophisticated one. Setting a lockout time can help discourage attackers, but excessively long times are likely to be more of a burden to authorized users than to potential attackers. A lockout time of 25 minutes is recommended for regular user accounts.
- Do not assign an infinite lockout time on an account (by setting the -locktime argument to 0 [zero]) unless there is a highly compelling reason. Such accounts almost inevitably become locked at some point, because each Authentication Server never resets the account's failure counter in its copy of the kaauxdb file (in contrast, when the lockout time is not infinite, the counter resets after the specified amount of time has passed since the last failed attempt to that Authentication Server). Furthermore, the only way to unlock an account with an infinite lockout time is for an administrator to issue the kas unlock command. It is especially dangerous to set an infinite lockout time on an administrative account; if all administrative accounts become locked, the only way to unlock them is to shut down all instances of the Authentication Server and remove the kaauxdb file on each.
In summary, the recommended limit on authentication attempts is nine and lockout time 25 minutes.
Limit password lifetime.
The longer a password is in use, the more time an attacker has to try to learn it. To protect against this type of attack, use the -pwexpires argument to the kas setfields command to limit how many days a user's password is valid. The user becomes unable to authenticate with AFS after the password expires, but has up to 30 days to use the kpasswd command to set a new password. After the 30 days pass, only an administrator who has the ADMIN flag on the Authentication Database entry can change the password.
If you set a password lifetime, many AFS-modified login utilities (but not the klog command) set the PASSWORD_EXPIRES environment variable to the number of days remaining until the password expires. A setting of zero means that the password expires today. If desired, you can customize your users' login scripts to display the number of days remaining before expiration and even prompt for a password change when a small number of days remain before expiration.
Prohibit reuse of passwords.
Forcing users to select new passwords periodically is not effective if they simply set the new password to the current value. To prevent a user from setting a new password to a string similar to any of the last 20 passwords, use the -reuse argument to the kas setfields command.
If you prohibit password reuse and the user specifies an excessively similar password, the Authentication Server generates the following message to reject it:
```
   Password was not changed because it seems like a reused password
```
A persistent user can try to bypass this restriction by changing the password 20 times in quick succession (or running a script to do so). If you believe this is likely to be a problem, you can include the -minhours argument to the kaserver initialization command (for details, see the command's reference page in the OpenAFS Administration Reference. If the user attempts to change passwords too frequently, the following message appears.
```
   Password was not changed because you changed it too recently; see 
   your systems administrator
```
Check the quality of new passwords.
You can impose a minimum quality standard on passwords by writing a script or program called kpwvalid. If the kpwvalid file exists, the kpasswd and kas setpassword command interpreters invoke it to check a new password. If the password does not comply with the quality standard, the kpwvalid program returns an appropriate code and the command interpreter rejects the password.
The kpwvalid file must be executable, must reside in the same AFS directory as the kpasswd and kas binaries, and its directory's ACL must grant the w (write) permission only to the system:administrators group.
If you choose to write a kpwvalid program, consider imposing standards such as the following.
- A minimum length
- Words found in the dictionary are prohibited
- Numbers, punctuation, or both must appear along with letters
The AFS distribution includes an example kpwvalid program. See the kpwvalid reference page in the OpenAFS Administration Reference.

To limit the number of consecutive failed authentication attempts

Issue the kas setfields command with the -attempts and -locktime arguments.
The Authentication Server performs its own authentication rather than accepting your existing AFS token. By default, it authenticates your local (UNIX) identity, which possibly does not correspond to an AFS-privileged administrator. Include the -admin argument to name an identity that has the ADMIN flag on its Authentication Database entry. To verify that an entry has the flag, issue the kas examine command as described in To check if the ADMIN flag is set.
```
   % kas setfields <name of user>  \
                   -admin <admin principal to use for authentication>  \
                   -attempts <maximum successive failed login tries ([0..254])>  \
                   -locktime <failure penalty [hh:mm or minutes]>
   Administrator's (admin_user) password: <admin_password>
```
where
name of user
Names the Authentication Database entry to edit.
-admin
Names an administrative account that has the ADMIN flag on its Authentication Database entry, such as the admin account. The password prompt echoes it as admin_user. Enter the appropriate password as admin_password.
-attempts
Specifies the maximum consecutive number of times that a user can fail to provide the correct password during authentication (via the klog command or an AFS-modified login utility) before the Authentication Server refuses further attempts for the amount of time specified by the -locktime argument. The range of valid values is 0 (zero) through 254. If you omit this argument or specify 0, the Authentication Server allows an unlimited number of failures.
-locktime
Specifies how long the Authentication Server refuses authentication attempts after the user exceeds the failure limit specified by the -attempts argument.
Specify a time in either hours and minutes (hh:mm) or minutes only (mm), from the range 01 (one minute) through 36:00 (36 hours). The kas command interpreter automatically reduces any larger value to 36:00 and also rounds up each nonzero value to the next-higher multiple of 8.5 minutes.
It is best not to provide a value of 0 (zero), especially on administrative accounts, because it sets an infinite lockout time. An administrator must always issue the kas unlock command to unlock such an account.

To unlock a locked user account

Issue the kas command to enter interactive mode.
The Authentication Server performs its own authentication rather than accepting your existing AFS token. By default, it authenticates your local (UNIX) identity, which possibly does not correspond to an AFS-privileged administrator. Include the -admin argument to name an identity that has the ADMIN flag on its Authentication Database entry. To verify that an entry has the flag, issue the kas examine command as described in To check if the ADMIN flag is set.
```
   % kas -admin <admin principal to use for authentication>  
   Administrator's (admin_user) password: <admin_password>
   ka>
```
where -admin names an administrative account that has the ADMIN flag on its Authentication Database entry, such as admin. The password prompt echoes it as admin_user. Enter the appropriate password as admin_password.
Issue the (kas) examine command to verify that the user's account is in fact locked, as indicated by the message shown:
```
   ka> examine <name of user>
   User is locked until time
```
Issue the (kas) unlock command to unlock the account.
```
   ka> unlock <authentication ID> 
```
where
u
Is the shortest acceptable abbreviation of unlock.
authentication ID
Names the Authentication Database entry to unlock.

To set password lifetime

Issue the kas setfields command with the -pwexpires argument.
The Authentication Server performs its own authentication rather than accepting your existing AFS token. By default, it authenticates your local (UNIX) identity, which possibly does not correspond to an AFS-privileged administrator. Include the -admin argument to name an identity that has the ADMIN flag on its Authentication Database entry. To verify that an entry has the flag, issue the kas examine command as described in To check if the ADMIN flag is set.
```
   % kas setfields <name of user>  \
                   -pwexpires <number days password is valid  [0..254])>  \
                   -admin <admin principal to use for authentication> 
   Administrator's (admin_user) password: <admin_password>
```
where
name of user
Specifies the Authentication Database entry on which to impose a password expiration.
-pwexpires
Sets the number of days after the user's password was last changed that it remains valid. Provide an integer from the range 1 through 254 to specify the number of days until expiration.
When the password becomes invalid (expires), the user is unable to authenticate, but has 30 more days in which to issue the kpasswd or kas setpassword command to change the password (after that, only an administrator can change it). Note that the clock starts at the time the password was last changed, not when the kas setfields command is issued. To avoid retroactive expiration, have the user change the password just before issuing the command.
-admin
Names an administrative account that has the ADMIN flag on its Authentication Database entry, such as admin. The password prompt echoes it as admin_user. Enter the appropriate password as admin_password.

To prohibit reuse of passwords

Issue the kas setfields command with the -reuse argument.
The Authentication Server performs its own authentication rather than accepting your existing AFS token. By default, it authenticates your local (UNIX) identity, which possibly does not correspond to an AFS-privileged administrator. Include the -admin argument to name an identity that has the ADMIN flag on its Authentication Database entry. To verify that an entry has the flag, issue the kas examine command as described in To check if the ADMIN flag is set.
```
   % kas setfields <name of user> -reuse < permit password reuse (yes/no)>  \
                   -admin <admin principal to use for authentication> 
   Administrator's (admin_user) password: <admin_password>
```
where
name of user
Names the Authentication Database entry for which to set the password reuse policy.
-reuse
Specifies whether the Authentication Server allows reuse of passwords similar to any of the user's last 20 passwords. Specify the value no to prohibit reuse, or the value yes to reinstate the default of allowing password reuse.
-admin
Names an administrative account that has the ADMIN flag on its Authentication Database entry, such as admin. The password prompt echoes it as admin_user. Enter the appropriate password as admin_password.