[bertil]

That would be an interesting development. It means that either:

- is it illegal to not have 2FA; I’m not against that, but it feels… excessive;

- every website, including small irrelevant ones, with a password (like HN) needs to crawl the darker internet to check for leaked lists of email/passwords; that would make those unsavoury forums crawl with solution vendors; it would also make it illegal to not find the most obscure ones; in other words, a non-option;

- ban the use of any password listed on https://haveibeenpwned.com/Passwords which feels more manageable, but… does the service offer an API?

Which one feels the most likely to happen in the short term?

[snowwolf]

Remember part 2 of that section:

"establish the likelihood and severity of the resulting risk to people’s rights and freedoms. If it’s likely that there will be a risk then you must notify the ICO;"

So if it's a small irrelevant website, there isn't likely to be a high or severe risk to that "breach", so they should be ok.

In terms of options, I think there are more, mostly around sites getting more sophisticated at defending against credential stuffing attacks - treat logins as more suspicious if they are from a new device, new ip, use a password that you know is in a breach list (have i been pwned), etc. and put in place a 2nd factor like email confirmation of the login even if they haven't turned on 2FA. Or at least restrict access to sensitive parts of your site if the login was suspicious until you can verify it was an authentic login.

[mannykannot]

'So if it's a small irrelevant website, there isn't likely to be a high or severe risk to that "breach", so they should be ok.'

To be clear, no website, depending on passwords alone, can know if an access was authorized by the person who is the subject of the account. Therefore, it would seem that the only sites that can use password-only authentication without risk are those that hold no personal information about their customers. According to your own interpretation of the law, some of your proposed mitigations would not be sufficient to eliminate the risk, if any personal information is held.

[snowwolf]

>> According to your own interpretation of the law

Look, I am not a laywer, and I am happy for someone to correct me here, but this is the wording of the law:

"A personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data."

Is there anything in that sentence that means a successful credential stuffing attack would not fit the criteria?

[randerson]

a) the data wasn't breached through the credential stuffing attack, it was breached at an earlier time on another site. b) the credential stuffing attack itself is authorized access (because from the site's perspective, the user provided the correct username and password), not unauthorized access.

[snowwolf]

>> a) the data wasn't breached through the credential stuffing attack, it was breached at an earlier time on another site.

Remember GDPR is specifically concerned with "A personal data breach" The original breach that led to the password being leaked was likely also a personal data breach (unless the only thing the hackers managed to access was the username/password database - and even then email address can constitute personal data in some cases), but there is definitely a personal data breach as a result of the credential stuffing attack (in the Deliveroo case, more than likely full home address, possibly other addresses too like work, possibly name, some level of credit card data, order history, etc.).

>> b) the credential stuffing attack itself is authorized access (because from the site's perspective, the user provided the correct username and password), not unauthorized access.

It's certainly authenticated access, but I think you'll struggle to convince a lawyer that it was authorised.

[mannykannot]

I am not disagreeing with your position that such an access is not authorized by the person whose confidentially is compromised, but the phrases from the UK ICO that you quote in making your argument do not say that the mitigations you propose would provide an adequate defense for the website provider, either. Taken in isolation and at face value (which is what you do to make your case), those phrases lead inevitably to the conclusion that password-only authentication cannot possibly suffice as ICO-compliant authorization for access to any personal data whatsoever.