@jubes Another reason to : 100 million debit/credit card users leaked from Amazon's credit card processor (who foolishly used AWS to store the data):

@resist1984 I'm not excusing Amazon's misbehaviours but from a technical perspective I don't think it's foolish, it was either poor design or ignorance. The article posted indicates the leak was from an open S3 buckets which is the end users issue not Amazon's.

@jubes Even if the containers are secure, the financial institutions are still exposing sensitive data to . Amazon is big, with untrustworthy insiders, proven by the Capital One .

@resist1984 Fair point, but insider threat is a risk which affects all businesses. You can also use standard Public Key Infrastructure to secure data so you don't need to trust Amazon if you're going to use them for storage. In addition, from what I understand the Capital One breach wasn't due to untrustworthy insiders, it was due to a misconfigured Web Application Firewall (ModSecurity) which in turn allowed for Server Side Request Forgery.

@jubes Is Capone, Amazon-Swiggy-Juspay, & Liberapay only using AWS for storage? AWS is also a hosting service, so I thought AWS was where these financial services ran their web server. The Capital One attack was executed by a contractor who worked for Amazon. Perhaps their insider access gave awareness of the malconfig.

Follow

@resist1984 I don't know and maybe. My point is, it's not unique to Amazon but I understand the need to make the points into beating sticks.

Sign in to participate in the conversation
Mastodon 🔐 privacytools.io

Fast, secure and up-to-date instance. PrivacyTools provides knowledge and tools to protect your privacy against global mass surveillance.

Website: privacytools.io
Matrix Chat: chat.privacytools.io
Support us on OpenCollective, many contributions are tax deductible!