Drop the forced password change, and you have to detect leaks

The password change every 90 days has been dropped in many organisations, and rightly so. Anyone who has to invent a new password every three months appends a digit to the old one or writes it down. The BSI agrees. But the same paragraph contains a second sentence that is often missing when the change is dropped.

What IT-Grundschutz requires

Basic requirement ORP.4.A23 in the module on identity and access management first says what many want to hear: purely time-based changes should be avoided. And immediately afterwards, in German: „Es MÜSSEN Maßnahmen ergriffen werden, um die Kompromittierung von Passwörtern zu erkennen.“ Measures must be taken to detect the compromise of passwords.

Only if that is not possible should the organisation consider accepting the drawbacks of time-based changes after all. So the order is: detect instead of change, and change only where you cannot detect. What happens after detection is governed by ORP.4.A8: a password must be changed if it has become known to unauthorised persons or if this is suspected.

Whoever dropped the calendar change without introducing detection has not modernised. They have struck out a basic requirement instead.

Where the knowledge comes from

A password is rarely compromised inside your own network. It is lost where staff use it outside, and then turns up in three kinds of places:

• Known data breaches. A service where someone used the same address and possibly the same password is hacked. The credentials end up in collections that become public later.
• Stealer logs. Malware on a private computer reads out everything stored in the browser: passwords, but also session cookies. With a valid session cookie, the attacker needs neither the password nor the second factor.
• Forums, Telegram channels, paste services. Access is traded there or published as a sample, often before anyone knows about a breach.

From outside, you only see these places through providers who analyse them systematically. Searching forums yourself is neither a process nor a good idea.

What a hit has to trigger

A hit is the suspicion from ORP.4.A8, so the change is mandatory. But for a stealer log it is not enough: as long as the old session is valid, the new password helps little. So a hit calls for at least three steps: change the password, end existing sessions and check whether the account was used in the meantime. Whether this becomes a reportable incident depends on that third question. How to deal with the related case of a supplier appearing on an extortion site was covered in When the supplier is on the leak site.

How isidaten handles this

Dark web monitoring queries providers such as Intelligence X and Flare through their interfaces, under a contract with the respective provider and without accessing the Tor network itself. It searches for the domains and organisation names from the inventory, and for named persons only with explicit approval. isidaten stores nothing of the password, only whether the finding contained one; people are matched via the SHA-256 hash of the email address. For each hit, isidaten proposes the response, for example an incident and a reset task for the people responsible. This happens automatically only if it is switched on per response; by default it is off. isidaten does not reset the password itself; that stays in the directory service and with the people responsible for it. Known data breaches can additionally be queried by the leak check in attack surface management.

The test question

When did you drop the time-based password change, and what has detected a compromised password since then?

If the answer is "staff will tell us", ORP.4.A23 is open.

Sources

BSI IT-Grundschutz Kompendium, 2023 edition, module ORP.4 Identitäts- und Berechtigungsmanagement, requirements A8 and A23 (German).