CWE-262 is an unusual entry, because the weakness comes with an honest caveat attached. The product does not have a mechanism in place for managing password aging. MITRE describes the entry as not language specific.
Password aging, also called password rotation, is a policy that forces users to change their passwords after a defined period, such as every 30 or 90 days. The argument for it is simple: as passwords age, the chance that they have been compromised grows. That is the consequence MITRE lists, under access control.
How it happens
A product ships with authentication and nothing that tracks how old a credential is. There is no expiry date, no prompt to change, no way for an administrator to require a change. Accounts created years ago keep working with the first password they were given.
MITRE's own demonstrative example is one line: a system does not enforce the changing of passwords every certain period.
This tends to matter most in a few settings:
- Service and shared accounts that nobody owns day to day.
- Products under compliance regimes that require rotation. MITRE names the Payment Card Industry Data Security Standard as one reason aging is still in use.
- Systems where an incident may have exposed credentials and administrators need a way to force a reset across the board.
The honest caveat
MITRE says plainly that password aging was once considered an important security feature, but has since fallen out of favor with many, because it is not as effective against modern threats as other mechanisms, such as slow hashes. It adds that forcing frequent changes can unintentionally encourage users to select less secure passwords.
Both points are real. A user who must change a password every 90 days often picks a small variation of the old one, or writes it down. A rotation policy on its own does little against a password that is already weak or reused. And it does nothing about a credential stolen today and used tomorrow.
So treat this entry as a design question and not a checkbox. Does your product need aging, and if so, which kind?
What an attacker gains
The record lists access control, gaining privileges or assuming an identity. With no aging, a password that leaked long ago stays valid. The attacker has no deadline.
How to find it
The record lists no detection methods. Practical checks:
- Ask whether the product stores a password change date, and whether anything reads it.
- Find the oldest active credentials in your system and see how old they are.
- Check whether administrators can force a reset for one user or for everyone.
- Review compliance requirements that apply to you, to see whether rotation is mandated.
How to fix it
MITRE's mitigations show the tension.
- In Architecture and Design: as part of a product's design, require users to change their passwords regularly and avoid reusing previous passwords.
- In Implementation: developers might disable clipboard paste into password fields to discourage copying a password to the clipboard. MITRE marks this as discouraged common practice. It may push users toward weaker passwords that are easier to type, and it reduces the usability of password managers.
A balanced approach, built from the record:
- Where a regime requires rotation, implement it, and block reuse of previous passwords.
- Where it does not, consider how much weight to put on aging relative to the stronger measures MITRE mentions, such as slow hashes for stored passwords.
- Give administrators a way to force a reset, so you can respond to an incident.
- Do not block paste into password fields. Let password managers work.
- Make the change flow easy, so rotation is not a reason to pick a weaker password.
If your service accounts hold passwords that nobody has changed in years, treat that as a finding in its own right, whatever your policy says about users.
Questions to ask before choosing a policy
Before deciding how to handle aging, answer a few plain questions about your own product.
First, who owns the accounts? Personal accounts and shared service accounts need different handling. A service account password is easy to forget about, which makes it an ideal candidate for scheduled change, ideally automated.
Second, what do your compliance obligations say? If a standard you must meet requires rotation, that settles the matter for the accounts in scope, and MITRE names PCI DSS as one example.
Third, what is your recovery path after an incident? Even where routine rotation is not required, the ability to expire credentials on demand is useful, since it turns a breach response from a manual hunt into a single action.
Last, how will users cope? If the change flow is awkward, people will pick passwords that are easy to remember and easy to guess. Make the flow smooth, support password managers and block reuse of old values.
Quick check
Is password aging still recommended?
MITRE says it has fallen out of favor with many because it is less effective against modern threats than other mechanisms, and frequent changes can lead to weaker choices. It remains in use partly for compliance, for example PCI DSS.
Should you block pasting into password fields?
No. MITRE marks that as discouraged. It can make passwords weaker and hurts password manager use.
What does MITRE list as the consequence?
Access control: as passwords age, the probability that they are compromised grows.
