Wow, TIL that strong passwords are actually a part of GDPR (I was aware of the policies around deleting data, being clear about the data that you're storing, but not about passwords).

That's actually great that industry standards are being codified with actual deterrents for failing to strongly store secure passwords.

> If passwords are being used, they should not be accessible and should be securely stored to avoid them being visible to unauthorized individuals. Some sort of standard such as encryption or an equivalent should be used to protect the passwords.

quote from some random blog [0]

[0] https://www.compliancejunction.com/gdpr-password-requirement...

> That's actually great that industry standards are being codified with actual deterrents for failing to strongly store secure passwords.

What would be better is for us folks to do this to ourselves first. If self regulation works well, the government will never need to step in. The GDPR seems to be pretty good, but it's not unimaginable that some assholes in office who are looking to get reelected respond to a high-profile data breach by making a shitty set of regulations to govern all software developers in the country for all time.

W.R.T. enforcing compliance, having a licensing board that oversees this would provide incentive to developers to not cut corners, and would also provide a way to resist management that is intent on releasing a shitty product quickly in the hope of making a quick buck before it all crashes down / padding their resume.

So, in terms of self-enforcement, I have pretty much every poorly built PHP webapp from 1996-2014 as evidence that this won't happen. People are bad at security, including big people with lots to lose (see... I don't know, any high profile breech ever) so regulating this is quite necessary. Sometimes it'll even empower developers to push back on deadlines with the comment that cutting security corners will violate laws.

I don't think this is a practical solution at all. What would a licensing board certification entail? Thousands of certifications already exist, and we don't take any of them seriously. Why would the licensing board have any power? We'd need software engineers to form a union or have government regulate that companies hire certified engineers. Either way, there needs to be some enforcement mechanism.

Shifting the onus on security away from the companies and onto the developers also seems like a bad idea. With GDPR, there is a financial incentive for companies to use good practices. With a licensing board, companies will care far less if Joe Q Developer might lose his license. Why would they care unless there is financial or legal incentive? I just don't see how this would work without getting back to government regulation. I'll definitely reconsider my view point if you have a solution to this hurdle.

Yeah, I disagree. Most companies would just not sign up to the licensing board. Also, from a practical standpoint, imagine trying to license every site on the internet!

I've never built a website that doesn't securely store passwords. I've definitely _used_ websites that do though [0]. Up until now my only choice is to stop using any of these sites and just hope they magically fix their crap.

It's obvious which would be a better motivator for any of these sites, either receiving an email stating "what you're doing is wrong, and unsecure" or one stating "what you're doing is wrong and unsecure and, by the way, you could be fined €50,000" [1]

[0] https://plaintextoffenders.com/

[1] https://www.gamingtechlaw.com/2019/04/first-gdpr-fine-italy....

As long as data is private, I don't think so. Although, it is pointless to discuss that since keeping passwords in plaintext is, well, :)

Probably not, because the passwords were encrypted (with a google-owned key)

I'm not a GDPR expert, but I've done a fair bit of work making old systems GDPR compliant. With my understanding of GDPR, yes, this is a violation since part of GDPR requires you keep customer data secure using "appropriate technical and organizational measures". I would argue that this violates the "appropriate technical measure" part.

Again, I'm not a lawyer or expert in this domain, so I could be wrong.

They seem to be hammering home the point that the passwords were always stored on ‘secure encrypted infrastructure’ but the data was not hashed, so anyone with access to googles ‘secure encrypted infrastructure’ could read the data.

The encryption is most likely enough to be within GDPR compliance.

>The encryption is most likely enough to be within GDPR compliance. //

Why do you think that, allowing staff to read plaintext passwords is contrary to standard security practice; companies are expected to make reasonable effort to secure PII and allowing staff to read your password doesn't appear to be "reasonable effort" by even the casualist of readings.

I don't think the EU courts are that stupid.

FWIW I don't think there is a case here particularly, as it appears to be a genuine error and being fixed.

I would be surprised if a bug constituted a violation. The intent was clearly to have them be hashed. Once the bug was detected it was quickly patched and appropriate incidence response taken. That wouldn't violate other security standards, so I'd be very surprised if it violated GDPR.

I believe a bug would still cause them to be in violation, but it likely means there would not be any punishment for being in violation. GDPR has a lot of leeway for companies that are making an effort to be in compliance, but have failed for one reason or another. In this case, I would assume the punishment for the bug would just be "fix the bug".