Requirement 8: Assign a unique ID to each person with computer access
.This ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
8.1
Identify all users with a unique username before allowing them to access system components or cardholder data.8.2
Employ at least one of the methods below, in addition to unique identification, to authenticate all users:Password
Token devices (e.g., SecureID,
Biometrics.
8.3
Implement 2-factor authentication for remote access to the network by employees, administrators, and third parties. Use technologies such as RADIUS or TACACS with tokens, or VPN with individual certificates.8.4
Encrypt all passwords during transmission and storage, on all system components.8.5
Ensure proper user authentication and password management for non-consumer users and administrators, on all system components:8.5.1
Control the addition, deletion, and modification of user IDs, credentials, and other identifier objects.8.5.2
Verify user identity before performing password resets.8.5.3
Set first-time passwords to a unique value per user and change immediately after first use8.5.4
Immediately revoke accesses of terminated users.8.5.5
Remove inactive user accounts at least every 90 days8.5.6
Enable accounts used by vendors for remote maintenance only during the time needed8.5.7
Distribute password procedures and policies to all users who have access to cardholder information8.5.8
Do not use group, shared, or generic accounts/passwords8.5.9
Change user passwords at least every 90 days8.5.10
Require a minimum password length of at least seven characters We require 88.5.11
Use passwords containing both numeric and alphabetic characters We like to see a special character as well "! @ # $ % ^ & * ( ) _ +"8.5.12
Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used8.5.13
Limit repeated access attempts by locking out the user ID after not more than six attempts8.5.14
Set the lockout duration to thirty minutes or until administrator enables the user ID8.5.15
If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal8.5.16
Authenticate all access to any database containing cardholder information. This includes access by applications, administrators, and all other users.From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Monday, December 12, 2005 5:06 AM
To: [email protected]
Subject: RE: [WS_FTP Forum] User password security
From: Kevin Gillis - [EMAIL PROTECTED]
Sent: Monday, December 12, 2005 4:09 AM
To: [email protected]
Subject: RE: [WS_FTP Forum] User password security
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of [EMAIL PROTECTED]
Sent: Friday, December 09, 2005 1:12 PM
To: [email protected]
Subject: RE: [WS_FTP Forum] User password securityKevin,You asked: "How would you want expired passwords to be reset?"A brilliant solution would be a configurable "grace time period". If the user logs in during this time, he is advised that he still has (another configurable) n remaining logins, or he is asked to immediately change the password if n=0. If he has exceeded the n logins without having changed the password, or if he did not change the password immediately if n=0, or if the grace time period in general has been exceeded, then this user is locked out until an administrator resets him.Regards,Erich-----Original Message-----
From: Schuessler Doug - [EMAIL PROTECTED]
Sent: Friday, December 09, 2005 2:40 PM
To: [email protected]; [EMAIL PROTECTED]
Cc: Tripp Allen
Subject: RE: [WS_FTP Forum] User password securityI was planning that the user would be unable to logon once the password had expired, like any other logon. I had no considered an ability to allow logon but not any transfers.The new password features sound appealing. Would this be available for all user account DB options? Could the expire feature be set to expire after 'X' days, i.e. - if changed on Jan. 1, 2005, would it then be set to next expire March 31,2005 (90 days later)? Would there be an ability to warn, at logon, of impending password expire? Would there be an ability to force password change (or is this the reason for allowing logon after the password has expired?)?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Gillis
Sent: Thursday, December 08, 2005 5:48 PM
To: [email protected]; [EMAIL PROTECTED]
Cc: Tripp Allen
Subject: RE: [WS_FTP Forum] User password securityHi Doug,Excellent feature request. Turns out, we have a similar feature coming in the next release of WS_FTP Server for which the Beta is starting in January.It's not final, but we are looking to let you set the following requirements:1. # of former passwords to track2. Number of special characters (* & #, etc.)3. Number of numeric characters required4. Min number of characters required5. You can also set the expiration date for the password and also have it expire on a specific date (which you set).How would you want expired passwords to be reset? For example, would it be okay to let a user log into their account and just not allow any transfers (upload/download) until they change their password (provided you have that feature turned on)?Bye for now,kg-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Schuessler, Doug
Sent: Thursday, December 08, 2005 5:19 PM
To: [EMAIL PROTECTED]
Cc: WS_FTP Pro forum LISTSERV
Subject: [WS_FTP Forum] User password securityWe have been using FTP server with NT user database and only allowing users to change password by calling me to change them. The NT database was used to enforce our password content/complexity requirements (minimum 6 characters, containing at least one each of uppercase, lowercase and a number or special character), since this is not available when using Ws-FTP server to maintain the accounts. With our latest security audit, we are now required to expire the passwords every ninety days. This new requirement would mean manual password changes by me are no longer a workable process. With the loss of control of passwords, we also would then need a way to replicate the passwords to another system for disaster recovery purposes. I am looking for suggestions on how to support this new requirement.
<<[EMAIL PROTECTED]>>
