RE: bloomberg on supermicro: sky is falling

["Naslund, Steve" <SNaslund () medline com>]

Having gone through this I know that it's all on you which is why no one really cares.  You have to notice a fraudulent 
charge (in most cases), you have to dispute it, you have to prove it was not you that made the charge, and if they 
agree then they change all of your numbers at which point you have to contact everyone that might be auto charging your 
accounts for you.  It is a super pain in the neck.  So many merchants have been compromised that it seems to be having 
less and less impact on their reputation.


> They actually profit from fraud; and my theory is that that's why issuers have mostly ceased allowing consumers to 
> generate one time use card numbers via portal or app, even though they claim it's >simply because "you're not 
> responsible for fraud."  When a stolen credit card is used, the consumer disputes the resulting fraudulent charges.  
> The dispute makes it to the merchant account issuer, who >then takes back the money their merchant had collected, and 
> generally adds insult to injury by charging the merchant a chargeback fee for having to deal with the issue (Amex is 
> notable for not doing >this).  The fee is often as high as $20, so the merchant loses whatever merchandise or service 
> they sold, loses the money, and pays the merchant account bank a fee on top of that.
>
> Regarding CVV; PCI permits it being stored 'temporarily', but with specific conditions on how that are far more 
> restrictive than the card number.  Suffice it to say, it should not be possible for an >intrusion to obtain it, and we 
> know how that goes....
>
> These days javascript being inserted on the payment page of a compromised site, to steal the card in real time, is 
> becoming a more common occurrence than actually breaching an application or database.  >Websites have so much third 
> party garbage loaded into them now, analytics, social media, PPC ads, etc. that it's nearly impossible to know what 
> should or shouldn't be present, or if a given block of JS >is sending the submitted card in parallel to some other 
> entity.  There's technologies like subresource integrity to ensure the correct code is served by a given page, but 
> that doesn't stop someone from >replacing the page, etc.