2 ms·

If you're a billion dollar company, your attack surface is insanely large. Just as per usual work, thousands of people need to have access to the data, hundreds

If you're a billion dollar company, your attack surface is insanely large. Just as per usual work, thousands of people need to have access to the data, hundreds of software developers write code processing it and it's distributed over a lot of places. Plus, if you lock it down too much, things like simple customer service become either insanely expensive or outright impossible (imagine you'd need to iterate all your account details and show your passport just to answer a question about your account in a store!). That's not to say that breaches like this should just get punished by a slap on the wrist; this clearly must not happen. But especially when the company is so large you simply have an insanely large attack surface that comes with it. And it only takes one weak spot on there for an attacker to get in. People have casually carried out all data from Facebook, LinkedIn and even the NSA (multiple times!) - security at that scale simply is hard.

YeBanKo 5y ago
> things like simple customer service become either insanely expensive or outright impossible This is true. It is hard to design a CS backend that user user friendly and privacy cognizant at the same time. However, the other issue is sticky habit of the companies to grab on to as much data as possible and keep it just in case. For example, this breach had SSN next to user's phone number, name and address. Why does it need to store SSN at the first place after initial verification? It is not necessary for most of it's operation. The only reason I can think of is if they want to report defaulted payments to credits bureau. Although, storing SSN can be avoided in a similar way, how payment APIs allow you to minimize handling of credit card number, of course you need support for this from credits bureau. If they aren't cooperative, you can still design the system in compartmentalized way, that simply does not keep an association between SSN and other user info in one place, because SSN is used in very narrow scenarios. There is not enough pressure on the companies right now to do that.

YeBanKo 5y ago

> things like simple customer service become either insanely expensive or outright impossible This is true. It is hard to design a CS backend that user user friendly and privacy cognizant at the same time. However, the other issue is sticky habit of the companies to grab on to as much data as possible and keep it just in case. For example, this breach had SSN next to user's phone number, name and address. Why does it need to store SSN at the first place after initial verification? It is not necessary for most of it's operation. The only reason I can think of is if they want to report defaulted payments to credits bureau. Although, storing SSN can be avoided in a similar way, how payment APIs allow you to minimize handling of credit card number, of course you need support for this from credits bureau. If they aren't cooperative, you can still design the system in compartmentalized way, that simply does not keep an association between SSN and other user info in one place, because SSN is used in very narrow scenarios. There is not enough pressure on the companies right now to do that.