markarichards

I like to think of a breach as hole through into the hull... they don't mean the boat will sink or even ever will sink; just that the layers of security protections has been compromised.

In the case you mention it seems that happened too: internal actors could reach plaintext passwords and thus for safety the company responded by forcing password reset and disclosure (commendable as I know of companies that would not).

The term "personal data breach" is useful because it defines the range of breaches that the law focuses on (it's not interested in business data or incidents where the first layer of defence fell but the second kept it secure).

I feel it's a bit like having a determination for "road traffic incident". It helps the public, police, etc identify what is in scope... just because you have one doesn't mean you'll lose your licence or be fined - that depends on a range of factors regarding the lead up to the incident: what happened before, during and after. Similar with data breaches.

If a company has a breach it does not mean much in GDPR unless other factors are considered, so I wouldn't worry about being too focused on the term breach.

It's relatively common for publications to lazily only reference an action that resulted in a legal outcome, rather than the justification provided for the outcome.

For instance, Bob imprisoned for car bomb rather than Bob imprisoned after judgement rules deaths unlawfully resulted from Bob's malicious car bombing. Had Bob's car bomb been on a film set and no one hurt, Bob would hopefully be fine.

If you read coverage with this in mind, then what matters is more a case of how likely an action is to be unlawful and thus how lazy the publication is being.

If someone blows up a car, we'd assume it was unlawful. If a company stores passwords unlawfully we'd assume it was unlawful and hopefully for good reason...

From GDPR: "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 transmitted, stored or otherwise processed"

A typical security policy for securing passwords is to never store them in plaintext.

It would be a rare situation for the storage to not be accessible (what would be the point of storing it).

Thus it would seem fair to assume that in most cases plain text storage of passwords would be a breach of security (internal controls breach) would implicitly also be a breach of personal data (legal definition) as it would at the very least be accidentally accessible to staff, contractors or third parties (whoever hosts the storage).

So, it will likely fit the definition of a breach.

But, it still needs to escalate to a point where it would be recognised as serious enough to warrant action (like reporting to data subjects or regulators).

There are situations where storing passwords in plaintext may not warrant reporting or fines, such as if upon realising the breach it was evident that nobody had accessed the data and it was destructed before harm could be realised; but I doubt anyone would ever know about these situations happening in companies so it's fair to assume they wouldn't reach major news sites.

i read it twice and i still don’t understand the article.

Any recommendations to improve are welcome

is this site complaining about 3rd party analytics?

If a bank page includes a script tag that loads third party JavaScript from a non-bank server, then what is to stop that script from capturing data, submitting forms, spoofing page content?

The bank has effectively given these third parties unaudited remote access, via remote code execution, to consumers bank accounts.

A bank can safely use third party analytics if they adopt appropriate security measures, SRI is likely be one, but alone might not be enough.

In the cases found here, there is no SRI protection or similar to protect users from the third parties doing what they like on the page, acting as customers.

there is also a table further down that shows various banks sharing data with… themselves?

This is oddity due to the test suite spotting JS from a a separate domain for the same bank ( https://gitlab.com/markalanrichards/access-test/-/blob/main/... ): thank you for highlighting this and when I get time I hope to improve this I hope to filter it out.

Even if you do switch accounts, which bank do you choose, as most have this nature of vulnerability; hopefully with delivery providers that may be more trusted, but ultimately the bank has no control of the security and cannot distinguish their actions from customers: https://news.ycombinator.com/item?id=40112545

The technical fix to this exact issue is remove or SRI and review third party code. None of these features are a must have requirement for online banking.

However, the breadth of this problem indicates the fix is bigger, else this will just pop up again without being noticed and should be tackled from two directions.

Technically: in the context of non-repudiation, web browsers are insecure for users. Significant user requests (make a payment, consent to terms, etc) are not stored client side, not signed and were a user to discover an audit log feature there is no distinction between what JS did and what a user did. This should and must change for the web to evolve to protect users.

Business: the failure across most of the banking sector suggests that all who should be holding the banks to account (share holders, creditors, regulators, customers, etc) are failing to monitor the banks and given there has been prior warning of this for some (regulators) failing to act. If a third party uses their remote access to hack customers, then I'm sure they will react but that may be too late. When we want security in our physical environment we have watchdogs whose responsibility is not just to react, but to proactively monitor the environment: spot the river has chemicals in it. Banking is significant enough that it probably needs a watchdog tasked with specific objectives regarding information security.

The security breaches reported here have been detected by SRI checking bank websites using https://gitlab.com/markalanrichards/access-test/

If anyone wishes to help improve this test suite or fork it for other purposes, please go for it.

Some may trust Google, Microsoft and co, and I'm sure some used to trust Fujitsu. However, I encourage you to look at the companies in the list against the banks and see how broadly some banks give remote access to various types of third party companies.

Barclay's bank aren't on the list because the test suite didn't find anything. I might have to look into how to move my accounts there.

From the customer's perspective everything has been supplied to them.

However, from the bank's perspective, of their supply chain, the component shown to a customer has not been handled by them: they never received it, to supply it.

At best they can order a copy of it for quality assurance purposes and hope it is identical to what the customer will receive.

Instead, their web page sends an order to the third party for delivery (script src tag refers to a foreign location) and crosses their finger that all will be good.

There are mechanisms to reduce delivery chain risks, such as SRI, but they were not used.

For our systems we run, we have supply chain breaches.

But, when our code runs client side and depends on software artefacts being pulled from elsewhere by the client device, I feel like a supply chain paints a picture of a flow of control for that artefact that doesn't really exist.

Therefore, I phrased this post in the context of a "delivery chain" breach instead of a "supply chain" breach and I am curious to see what discussion flows.

Of course, I'm also trying to raise awareness to this particular breach and the odd events around it.

Sorry, I shortened the original title to fit.

Is it just me or is this like a finance regulator urging companies to adopt cryptocurrencies to harness the power of transactional integrity?

This is also an interesting read https://www.jewishvirtuallibrary.org/ibm-and-quot-death-s-ca...

I love this idea, but I didn't choose it when I kicked off because of my experiences of feature backlogs.

Too often seeing something along the lines of "we'd love to use your site, if only it worked in IE|Firefox|insert here" and the ticket forever being thrown further back... but it would sometimes work.

My initial complaint went down the road of, if you want to get something fixed in engineering real quick: then you get it into the incident board - so GDPR complaint to the DPO, cc the ICO, get your MP involved and make it clear they should respond within 72 hours, etc and that largely worked for their breaches of GDPR in the ad tracking they had on their site, but that aggressive approach makes it harder to try the other route, as the tone is already set.

I'd like to think that cost isn't the issue, that they aren't sacrificing their cause because of that.

I believe the charity has an income near £100m a year, so it could justify some cost (how much I don't know)

I would love to think that a respectable CDN would jump at the opportunity to support a cause like this at cost and could perhaps reach out and offer services.

Google presented pitches to customers and employees alike that it cares about things like sustainability https://sustainability.google/, along with a breadth of other commitments https://about.google/commitments/ and I'm sure you'll find more examples if you Google Google.

All employees, contractors and business partners who are working with or for Google have had those or similar pitches thrown at them. They are hopefully part of the reasons why they chose Google and each has a right to complain when they don't get what they signed up for.

If people apply their conscience anywhere then great, but surely one step at a time, maybe the author will run for president one day, fix homelessness and buy everyone SUVs, but we can only do one battle at a time and it seems like he's got some good domain knowledge about Google to tackle this one.

From what we’ve seen it appears many real-time bidding practices are unlawful. What we’re less sure about is whether industry players are aware that what they are doing is unlawful, or whether they do and are continuing to flout the law regardless.

Mozilla is warning about Privacy again this Christmas.

However, when it comes to Firefox, it has been invading user privacy for years and sharing referers without consent, visibility (to non-devs) or often even the websites asking them to.

This is from a new private browsing session, no page loaded (tabs only prefilled with urls to load).

Notice, no consent given on Facebook or the political party sites.

Facebook has been sent a wealth of data on who is a member of UK political parties, because UK political parties are mostly giving it away to them illegally.

The performance risks may not be so bad, if you're using a common CDN/library as it may be cached and save on download speeds: just hope most of your users don't have secure browsers, wiping caches regularly.

But there is still a problem with loading third party JS, even beyond the SaaS type that you expect to change regularly (where SRI+CORS becomes difficult-impossible to control), just loading Bootstrap has risks.

Although a good web developer hopefully knows how to add SRI, uses a validated third party library, will pick a fixed version and use a CDN with qualities as good as their hosting solution... they are rare to find and I doubt any data protection controller/officer responsible for GDPR should allow this risk.

The developer might: forget to add SRI; pick a CDN that allows tracking (read https://www.maxcdn.com/dpa/); pick a CDN registered or running servers outside of the EU.

So, the data protection office therefore has to check the terms of services of the CDNs, audit them regularly and then ensure there is appropriate staff training and QA to put in SRI and validate it it as needed.

Meanwhile, if the developer or data protection officer changes, there has to be enough documentation and process around to transition these practices to the next staff.. it all adds up.

Man power is often more expensive than CPU, so chucking the JavaScript in static hosting the company has control of is likely less for the DPO to worry about.

I'm not sure I can answer this, but it might help anyone who could if you know an example of an application that does the nature of tracking you are concerned with?

I should mention, that demanding tracking may well be okay in GDPR, in necessary contexts: for instance a banking service may have to do some natures of fraud prevention using tracking, perhaps of recent internet facing IP addresses used and may have a regulatory need to do something like this.

Also bear in mind that GDPR isn't the only law here. If you want to access data stored on a user's terminal (mobile device, laptop, etc), then you likely need consent too under ePrivacy: for example "Article 5" https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX...

Yes, I've added a focus on GDPR, but the article does state that this would often affect regulated contexts and I didn't intend the wording of that to be specific to the EU.

Finance, healthcare, etc are all likely to include requirements for information security controls that go as specific as demanding access controls and audit logs; which appear completely impossible to achieve with what Facebook offer with their SDK. As an example, ICH GCP applies internationally for pharma. However, these are much smaller areas of regulation than most of us are not exposed to

Whether all countries have more general provisions, like GDPR, that would apply to a very wide audience of businesses I don't know: but I know GDPR is now recognisable internationally and has parallels in many countries outside of the EU, so is hopefully a trigger for those in other areas to check what their privacy laws demand.

It's not just about GDPR. It's about any regulated environment that requires systems and controls in place to maintain information security.

Tools like http://panzi.github.io/SocialSharePrivacy/

Facebook who have the ability are not necessarily criminal.

It is the websites that invite them into a secure context that are often illegal.

In the physical realm, is it okay for an advertising company to be invited into a bank safe or customer records storage without any business controls to audit, monitor or check their actions? Same is true on websites.

I find it amusing too.

I don't hold user data or regulated data... so I'm hopefully one of the cases that isn't illegal, but if I'm wrong then please let me know a worthwhile wordpress.com -> static site tool. With a baby abusing my free time, new hosting has been a low priority.

Update: I don't like that Facebook gets told what you read on my site, but I'm not sure it indicates much to them, maybe they'll sack Facebook employees who read this? Let me know.

If encryption is enriched with appropriate identity, authorisation and authentication systems then...

Encryption at network level is a must. Corporate routers/firewalls have been very vulnerable before and the risk of grabbing everything is a lot easier if you've comprised the network.

Encryption at rest is a must, as at some point you need to replace those disks and it's a lot easier if you can be cavalier with the handling afterwards because you know it is unreadable.

Encryption at application level (object encryption and between services) is a must. Which means if a service is hacked or you dump the dB you may not be able to read any of it or only those records accessed whilst the hack happens. You replicate access control patterns, like in a secure building... These may come down to one or more common denominators (can you trust the security receptionist), but better that than the whole chain is vulnerable... You then only have one set of alarms, logs, metrics, etc to keep an eye on and to test very thoroughly.

In the physical world: for security scenarios we have very strict procedures with locks, boxes, safes, multiple security door/gate entry systems, multiple participants and signatures involved in every action, etc to mitigate internal and external error, failure or attack - all of these can have an electronic information system equivalent and we should start designing security in web systems with these ideas in mind when it as significant as Equifax.

How much do websites trust other companies with their reset password urls?

Many websites use third party assets on their pages, which for most doesn't matter too much: but for the reset password url often results in those parties getting a user access token.

In the time it takes to set your password: those receiving the reset password url can set their own, scrape your account and disappear.

If your attempt to reset the password failed... would you a) believe you'd entered it wrong b) think the site had gone wrong or c) report it to the website as a security problem.

It's easy to dismiss the problem... For most sites who cares? What are the chances someone is misusing this?

Ideally, web browsers should stop sending referer headers completely.

In the meantime, web developers should protect their users, not because it's likely to be abused (I have no reason to believe it is) but because it is their responsibility to look after any user token.