What is the minimum number of days that must pass before the password can be changed?

chage(1) - Linux man page


chage - change user password expiry information


chage [options] [LOGIN]


The chage command changes the number of days between password changes and the date of the last password change. This information is used by the system to determine when a user must change his/her password.


The options which apply to the chage command are:

-d, --lastday LAST_DAY

Set the number of days since January 1st, 1970 when the password was last changed. The date may also be expressed in the format YYYY-MM-DD (or the format more commonly used in your area). -E, --expiredate EXPIRE_DATESet the date or number of days since January 1, 1970 on which the user's account will no longer be accessible. The date may also be expressed in the format YYYY-MM-DD (or the format more commonly used in your area). A user whose account is locked must contact the system administrator before being able to use the system again.

Passing the number -1 as the EXPIRE_DATE will remove an account expiration date. -h, --help

Display help message and exit. -I, --inactive INACTIVESet the number of days of inactivity after a password has expired before the account is locked. The INACTIVE option is the number of days of inactivity. A user whose account is locked must contact the system administrator before being able to use the system again.

Passing the number -1 as the INACTIVE will remove an account's inactivity. -l, --list

Show account aging information. -m, --mindays MIN_DAYSSet the minimum number of days between password changes to MIN_DAYS. A value of zero for this field indicates that the user may change his/her password at any time. -M, --maxdays MAX_DAYSSet the maximum number of days during which a password is valid. When MAX_DAYS plus LAST_DAY is less than the current day, the user will be required to change his/her password before being able to use his/her account. This occurrence can be planned for in advance by use of the -W option, which provides the user with advance warning.

Passing the number -1 as MAX_DAYS will remove checking a password's validity. -W, --warndays WARN_DAYS

Set the number of days of warning before a password change is required. The WARN_DAYS option is the number of days prior to the password expiring that a user will be warned his/her password is about to expire. If none of the options are selected, chage operates in an interactive fashion, prompting the user with the current values for all of the fields. Enter the new value to change the field, or leave the line blank to use the current value. The current value is displayed between a pair of [ ] marks.


The chage program requires a shadow password file to be available.

The chage command is restricted to the root user, except for the -l option, which may be used by an unprivileged user to determine when his/her password or account is due to expire.



User account information. /etc/shadow Secure user account information.

Exit Values

The chage command exits with the following values:


success 1permission denied 2invalid command syntax 15can't find the shadow password file

See Also

passwd(5), shadow(5).

Guidelines for Password Management


The purpose of this Guideline is to educate Carnegie Mellon University (“University”) students, faculty and staff on the characteristics of a Strong Password as well as to provide recommendations on how to securely maintain and manage passwords.

Applies To

This Guideline applies to all students, faculty and staff that have a username and password to at least one University system or application, independent of whether you are an end user or a system administrator for that system or application.


A Strong Password is defined as a password that is reasonably difficult to guess in a short period of time either through human guessing or the use of specialized software.


The following are general recommendations for creating a Strong Password:

A Strong Password should -

  • Be at least 8 characters in length
  • Contain both upper and lowercase alphabetic characters (e.g. A-Z, a-z)
  • Have at least one numerical character (e.g. 0-9)
  • Have at least one special character (e.g. ~!@#$%^&*()_-+=)

Strong Passwords do not -

  • Spell a word or series of words that can be found in a standard dictionary
  • Spell a word with a number added to the beginning and the end
  • Be based on any personal information such as user id, family name, pet, birthday, etc.

The following are several recommendations for maintaining a Strong Password:

  • Do not share your password with anyone for any reason

    Passwords should not be shared with anyone, including any students, faculty or staff.  In situations where someone requires access to another individual’s protected resources, delegation of permission options should be explored.  For example, Microsoft Exchange calendar will allow a user to delegate control of his or her calendar to another user without sharing any passwords.  This type of solution is encouraged.  Passwords should not be shared even for the purpose of computer repair.  An alternative to doing this is to create a new account with an appropriate level of access for the repair person.

  • Change your password upon indication of compromise

    If you suspect someone has compromised your account, change your password immediately. Be sure to change your password from a computer you do not typically use (e.g. university cluster computer). After resetting your password, report the incident to your local departmental administrator and/or the Information Security Office at .

  • Consider using a passphrase instead of a password

    A passphrase is a password made up of a sequence of words with numeric and/or symbolic characters inserted throughout.  A passphrase could be a lyric from a song or a favorite quote.  Passphrases typically have additional benefits such as being longer and easier to remember.  For example, the passphrase “My passw0rd is $uper str0ng!” is 28 characters long and includes alphabetic, numeric and special characters.  It is also relatively easy to remember.  It is important to note the placement of numeric and symbolic characters in this example as they prevent multiple words from being found in a standard dictionary.  The use of blank spaces also makes a password more difficult to guess.

  • Do not write your password down or store it in an insecure manner

    As a general rule, you should avoid writing down your password.  In cases where it is necessary to write down a password, that password should be stored in a secure location and properly destroyed when no longer needed (see Guidelines for Data Protection).  Using a password manager to store your passwords is not recommended unless the password manager leverages strong encryption and requires authentication prior to use. The ISO has vetted some password managers that meets these requirements.

  • Avoid reusing a password

    When changing an account password, you should avoid reusing a previous password.  If a user account was previously compromised, either knowingly or unknowingly, reusing a password could allow that user account to, once again, become compromised.  Similarly, if a password was shared for some reason, reusing that password could allow someone unauthorized access to your account.

  • Avoid using the same password for multiple accounts 

    While using the same password for multiple accounts makes it easier to remember your passwords, it can also have a chain effect allowing an attacker to gain unauthorized access to multiple systems.  This is particularly important when dealing with more sensitive accounts such as your Andrew account or your online banking account.  These passwords should differ from the password you use for instant messaging, webmail and other web-based accounts.

  • Do not use automatic logon functionality

    Using automatic logon functionality negates much of the value of using a password.  If a malicious user is able to gain physical access to a system that has automatic logon configured, he or she will be able to take control of the system and access potentially sensitive information.

The following are Guidelines for individuals responsible for provisioning and support of user accounts:

  • Enforce strong passwords

    Many systems and applications include functionality that prevents a user from setting a password that does not meet certain criteria.  Functionality such as this should be leveraged to ensure only Strong Passwords are being set.

  • Require a change of initial or “first-time” passwords

    Forcing a user to change their initial password helps ensure that only that user knows his or her password.  Depending on what process is being used to create and distribute the password to the user, this practice can also help mitigate the risk of the initial password being guessed or intercepted during transmission to the user.  This guidance also applies to situations where a password must be manually reset.

  • Force expiration of initial or “first-time” passwords

    In certain situations, a user may be issued a new account and not access that account for a period of time.  As mentioned previously, initial passwords have a higher risk of being guessed or intercepted depending on what process is being used to create and distribute passwords.  Forcing an initial password to expire after a period of time (e.g. 72 hours) helps mitigate this risk.  This may also be a sign that the account is not necessary.

  • Do not use Restricted data for initial or “first-time” passwords

    The Guidelines for Data Classification defines Restricted data in its data classification scheme. Restricted data includes, but is not limited to, social security number, name, date of birth, etc.  This type of data should not be used wholly or in part to formulate an initial password.  See Appendix A for a more comprehensive list of data types.

  • Always verify a user’s identity before resetting a password

    A user’s identity should always be validated prior to resetting a password.  If the request is in-person, photo identification is a sufficient means of doing this.  If the request is by phone, validating an identity is much more difficult.  One method of doing this is to request a video conference with the user (e.g. Skype) to match the individual with their photo id.  However, this can be a cumbersome process.  Another option is to have the person’s manager call and confirm the request.  For obvious reasons, this would not work for student requests.  If available, a self-service password reset solution that prompts a user with a series of customized questions is an effective approach to addressing password resets.

  • Never ask for a user’s password

    As stated above, individual user account passwords should not be shared or any reason.  A natural correlation to this guidance is to never ask others for their passwords.  Once again, delegation of permission is one alternative to asking a user for their password.  Some applications include functionality that allows an administrator to impersonate another user, without entering that user’s password, while still tying actions back to the administrator’s user account.  This is also an acceptable alternative.  In computer repair situations, requesting that a user create a temporarily account on their system is one alternative.

The following are several additional Guidelines for individuals responsible for the design and implementation of systems and applications:

  • Change default account passwords

    Default accounts are often the source of unauthorized access by a malicious user.  When possible, they should be disabled completely.  If the account cannot be disabled, the default passwords should be changed immediately upon installation and configuration of the system or application.

  • Implement strict controls for system-level and shared service account passwords

    Shared service accounts typically provide an elevated level of access to a system.  System-level accounts, such as root and Administrator, provide complete control over a system.  This makes these types of accounts highly susceptible to malicious activity.  As a result, a more lengthy and complex password should be implemented.  System-level and shared service accounts are typically critical to the operation of a system or application.  Because of this, these passwords are often known by more than one administrator.  Passwords should be changed anytime someone with knowledge of the password changes job responsibilities or terminates employment.  Use of accounts such as root and Administrator should also be limited as much as possible.  Alternatives should be explored such as using sudo in place of root and creating unique accounts for Windows administration instead of using default accounts.

  • Do not use the same password for multiple administrator accounts

    Using the same password for multiple accounts can simplify administration of systems and applications.  However, this practice can also have a chain effect allowing an attacker to break into multiple systems as a result of compromising a single account password.

  • Do not allow passwords to be transmitted in plain-text

    Passwords transmitted in plain-text can be easily intercepted by someone with malicious intent.  Protocols such as FTP, HTTP, SMTP and Telnet all natively transmit data (including your password) in plain-text.  Secure alternatives include transmitting passwords via an encrypted tunnel (e.g. IPSec, SSH or SSL), using a one-way hash or implementing a ticket based authentication scheme such as Kerberos.  Contact the Information Security Office at if you would like an assessment of your application’s authentication controls.

  • Do not store passwords in easily reversible form

    Passwords should not be stored or transmitted using weak encryption or hashing algorithms.  For example, the DES encryption algorithm and the MD-4 hash algorithm both have known security weaknesses that could allow protected data to be deciphered.  Encryption algorithms such as 3DES or AES and hashing algorithms such as SHA-1 or SHA-256 are stronger alternatives to the previously mentioned algorithms.  Contact the Information Security Office at if you have questions related to the use of a specific encryption and hashing algorithm.

  • Implement automated notification of a password change or reset

    When a password is changed or reset, an email should be automatically sent to the owner of that user account.  This provides a user with a confirmation that the change or reset was successful and also alerts a user if his or her password to unknowingly changed or reset.

The following are additional Guidelines for system or service accounts - those not designed to be used by humans:

  • Where possible, service accounts should be randomly generated, long ( >= 15 characters), and follow the same complexity requirements for strong passwords above.
  • Service accounts in Microsoft Active Directory with a Service Principal Name (SPN) should be randomly generated, long (>= 28 characters), and follow the same complexity requirements for strong passwords above. The longer length mitigates weak encryption ciphers. If software compatibility requires setting a shorter password, please contact the Information Security Office () to discuss compensating controls.

Additional Information

If you have any questions or comments related to this Guideline, please send email to the University Information Security Office at .

Additional information can also be found using the following resources:

  • University Computing Policy
  • Guidelines for Data Classification
  • Guidelines for Data Protection
  • Managing Your Password

Revision History

Version Date Published
1.0 12/01/2007 Doug Markiewicz Original publication.  Replaces Password Strength Guidelines and Password Sharing Guidelines.
1.1 05/14/2008 Doug Markiewicz Updated broken link in Additional Information.
1.2 09/12/2012 Doug Markiewicz Updated out of date references to supplemental resources.
1.3 03/24/2014 Wiam Younes Updated information on password compromise procedure and the example to verify user's identity.
1.4 09/14/2017 Laura Raderman Updated links to new Computing Services' site and formatted for new CMS templates
1.5 02/18/2022 Laura Raderman Added Guidance for service accounts.

Status Date Published 
Published:  12/01/2007 
Last Updated:  02/18/2022
Last Reviewed:  02/18/2022

What is the minimum number of days that must pass before the password can be changed Linux?

6 – number of days before a required change that warnings will be provided. 7 – number of days after password expires before it is locked (made inactive)

How many days can a password be used before it must be changed?

Most tech professionals recommend your password changes every thirty, sixty, or ninety days; depending on what the password is used for, how often the account is accessed, and how strong the password is to begin with.

What is the minimum length of a password?

Best practices. Set minimum password length to at least a value of 8. If the number of characters is set to 0, no password is required. In most environments, an eight-character password is recommended because it's long enough to provide adequate security and still short enough for users to easily remember.

Should passwords be reset every 90 days?

Many companies require their employees to change their password every 90 days. It's an inconvenient policy which leads people to ask: Is it really necessary? The short answer is no. Frequent password changes may have been a good idea in years gone by, but they're not necessary today.