NIST 800-44 Version 2 Guidelines on Securing Public Web Servers
NIST 800-44 Version 2 Guidelines on Securing Public Web Servers
NIST 800-44 Version 2 Guidelines on Securing Public Web Servers
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
GUIDELINES ON SECURING PUBLIC WEB SERVERS<br />
• Length—a minimum length for passwords. Specify a minimum length of at least eight<br />
characters.<br />
• Complexity—the mix of characters required. Require passwords to c<strong>on</strong>tain both uppercase and<br />
lowercase letters and at least <strong>on</strong>e n<strong>on</strong>alphabetic character, and to not be a “dicti<strong>on</strong>ary” word.<br />
• Aging—how l<strong>on</strong>g a password may remain unchanged. Require users to change their passwords<br />
periodically. Administrator or root level passwords should be changed every 30 to 120 days. The<br />
period for user-level passwords should be determined by the enforced length and complexity of<br />
the password combined with the sensitivity of the informati<strong>on</strong> protected. When c<strong>on</strong>sidering the<br />
appropriate aging durati<strong>on</strong>, the exposure level of user passwords should also be taken into<br />
account. C<strong>on</strong>siderati<strong>on</strong> should also be given to enforcing a minimum aging durati<strong>on</strong> to prevent<br />
users from rapidly cycling through password changes to clear out their password history and<br />
bypass reuse restricti<strong>on</strong>s.<br />
• Reuse—whether a password may be reused. Some users try to defeat a password aging<br />
requirement by changing the password to <strong>on</strong>e they have used previously. If possible, ensure that<br />
users cannot change their passwords by merely appending characters to the beginning or end of<br />
their original passwords (e.g., original password was “mysecret” and is changed to “1mysecret”<br />
or “mysecret1”).<br />
• Authority—who is allowed to change or reset passwords and what sort of proof is required<br />
before initiating any changes.<br />
• Password Security—how passwords should be secured, such as not storing passwords<br />
unencrypted <strong>on</strong> the mail server, and requiring administrators to use different passwords for their<br />
email administrati<strong>on</strong> accounts than their other administrati<strong>on</strong> accounts.<br />
C<strong>on</strong>figure Computers to Prevent Password Guessing—It is relatively easy for an unauthorized<br />
user to try to gain access to a computer by using automated software tools that attempt all passwords.<br />
If the OS provides the capability, c<strong>on</strong>figure it to increase the period between login attempts with each<br />
unsuccessful attempt. If that is not possible, the alternative is to deny login after a limited number of<br />
failed attempts (e.g., three). Typically, the account is “locked out” for a period of time (such as 30<br />
minutes) or until a user with appropriate authority reactivates it.<br />
The choice to deny login is another situati<strong>on</strong> that requires the <strong>Web</strong> server administrator to make a<br />
decisi<strong>on</strong> that balances security and c<strong>on</strong>venience. Implementing this recommendati<strong>on</strong> can help prevent<br />
some kinds of attacks, but it can also allow an attacker to use failed login attempts to prevent user<br />
access, resulting in a DoS c<strong>on</strong>diti<strong>on</strong>. The risk of DoS from account lockout is much greater if an<br />
attacker knows or can surmise a pattern to your naming c<strong>on</strong>venti<strong>on</strong> that allows them to guess account<br />
names.<br />
Failed network login attempts should not prevent an authorized user or administrator from logging in at<br />
the c<strong>on</strong>sole. Note that all failed login attempts, whether via the network or c<strong>on</strong>sole, should be logged.<br />
If remote administrati<strong>on</strong> is not to be implemented (see Secti<strong>on</strong> 9.5), disable the ability for the<br />
administrator or root level accounts to log in from the network.<br />
Install and C<strong>on</strong>figure Other Security Mechanisms to Strengthen Authenticati<strong>on</strong>—If the<br />
informati<strong>on</strong> <strong>on</strong> the <strong>Web</strong> server requires it, c<strong>on</strong>sider using other authenticati<strong>on</strong> mechanisms such as<br />
biometrics, smart cards, client/server certificates, or <strong>on</strong>e-time password systems. They can be more<br />
expensive and difficult to implement, but they may be justified in some circumstances. When such<br />
4-5