It’s relatively common for incident response teams, in scanning the web for information about threats to their constituencies, to come across dumps of usernames and passwords. Even if the team can work out which service these refer to [*], it’s seldom clear whether they are the result of current phishing campaigns, information left over from years ago, or even fake details published by intruders who want to inflate their claims. There’s little benefit in warning people of compromises of accounts or credentials that are no longer live, so how can teams work out which passwords are real and current?
The obvious approach would be to try to log in to the account, but under most legal systems that’s likely to constitute (attempted) unauthorised access. In some countries such access may still be lawful if the person’s intention is not malicious, but UK law doesn’t contain that defence. Section 17(5) of the Computer Misuse Act 1990 says:
Access of any kind by any person to any program or data held in a computer is unauthorised if—
(a) he is not himself entitled to control access of the kind in question to the program or data; and
(b) he does not have consent to access by him of the kind in question to the program or data from any person who is so entitled
That leaves two options. If (under clause (a)) the incident responder is “entitled to control access” – for example because the account in question is on one of their own organisation’s systems – then the attempted access should be authorised. Alternatively (under clause (b)) the team could ask the operator of the system for permission to test some accounts. Note that it doesn’t seem to be necessary to get the permission of the account holder to make such a test lawful.
Asking for permission to test every account would involve as much work as simply passing on all the account details, but fortunately that probably isn’t necessary. Since the initial purpose is simply to determine whether the collection of account information is accurate and up-to-date, testing just a handful of accounts or services should be enough. If most of those don’t work, then the information is probably old or inaccurate and can be treated as a lower priority. If most of the tests do work then it’s likely that the password information is fresh, and it’s worth passing on all the details to relevant service providers – often using the team’s automated systems for distributing warnings to affected parties – with the assurance that the information appears to be current.
In this way incident response teams can identify the most urgent threats and pass them on to those best placed to act to remedy them.
[* UPDATE Brian Krebs has a fascinating article on the challenge of working out which site a password dump relates to]
