Last updated: 
3 months 2 weeks ago
Blog Manager
One of Jisc’s activities is to monitor and, where possible, influence regulatory developments that affect us and our customer universities, colleges and schools as operators of large computer networks. Since Janet and its customer networks are classified by Ofcom as private networks, postings here are likely to concentrate on the regulation of those networks. Postings here are, to the best of our knowledge, accurate on the date they are made, but may well become out of date or unreliable at unpredictable times thereafter. Before taking action that may have legal consequences, you should talk to your own lawyers. NEW: To help navigate the many posts on the General Data Protection Regulation, I've classified them as most relevant to developing a GDPR compliance process, GDPR's effect on specific topics, or how the GDPR is being developed. Or you can just use my free GDPR project plan.

Group administrators:

Validating Password Dumps

Friday, June 3, 2016 - 09:29

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]