Delta Dental should be rightly and truly f'd for that one. Storing security codes at all is totally forbidden by PCI rules. Delta Dental should have their ability to process credit cards completely revoked for this egregious breach.
In my current role at a startup, when a conflict between schedule/time or convenience conflicts with proper data security, I ask people to envision how our processes would look as a news headline or would fare in a legal discovery.
Not the OP. One place, a few times when I was doing an integration with a large company, I discovered a grave security flaw in the customer's systems.
One time, had I done the integration despite the flaw, it would've required me to knowingly code some obviously 100% wrong use of cryptographic protocol.
When I started to tell the director to whom I reported, I felt an initial "oh no..." mixed with skepticism, from hints in their voice. So I explained, and answered their questions.
Then they seemed to switch from dread, to solving it. Instead of quietly taking the client's money, they halted integration, and put together a presentation for the customer, telling them how part of their security had a grave problem. (Possibly awkward, because it might've been a team internal to the customer who had made such a mistake on something so sensitive.)
I'd say that the dynamic in that case was what you'd like to imagine from engineers who'd risen in influence: acknowledging the problem, understanding and doing the right thing, when it had to be done, even when they wish it didn't.
I assume that the most common in business as a whole is a variation on: someone doesn't want to hear about it, because (put broadly) acknowledging it would conflict with business goals or their individual goals. Example conflicts: don't get a sale, slip the schedule, fail to meet some individual OKR/KPI, or expose an earlier mistake of the individual.
Also, the dynamic doesn't have to come down to conflicts between plausibly rational motivations (for business or self). Egos and irrational cognition are also parts of our collective human situation, and an individual's particular traits (or a personal challenge they're going through) can sometimes lead to that taking over decisions. It happens, and we should try to realize when that's the cause (rather than just an attempt at cover for some rational motive they don't want to state), so that we can try to get to rational decision-making.
A different thing, or a complication: There are also be dynamics in which an 'ambitious' person in an org, not naturally involved in the situation, uses the situation to grandstand or hit a rival. And obviously this can affect the dynamics for people who are involved (e.g., person A would normally do the aligned thing for the company, but it's more complicated now that B will twist that to gun for their job). Fortunately, I don't immediately recall seeing an egregious example first-hand, but have heard of it.
At the time I joined, the existing goals were around compliance and checking boxes on security questionnaires, which is exactly the problem I'm trying to solve. Specifically, compliance was driven by the IT/Infra teams and mostly around access to access to cloud infra. That's obviously useless if a db server is locked down and change managed, but the software access the data isn't.
So, the bulk of my efforts in this area have been around bridging the gap from checking boxes to actual compliance with various standards. Fortunately, we rely heavily on data, so it's not a hard sell to properly protect things.
In general, people receive the questions well, as it makes the strong point that there's a big gap between checking a box that people in sales & marketing care about, vs. how any issues arising from not having "real" compliance would be catastrophic and business ending for a company of our size.
I'd be curious what reason they had.
It is not directly related, but as a hopefully funny semi-related anecdote, the federal government stopped states from putting social security numbers on drivers licenses in 2004. Renewals frequency depends on the state, but it is typically in the 4-8 year range, so plausibly until 2012 people were going around showing their SSN to anybody that needed to see ID.
I specifically remember this caused stressful situations as a teenager working retail, people justifiably didn’t want to show an ID when doing returns because it had their SSN. A credit card number is hardly anything comparably!
This all seems absurd nowadays, but the past is not really that long ago.
No joke-- credit card numbers, billing addresses, CVV codes, all stored in plaintext in an Access database. Tiny shop though; I don't know if they were big enough for PCI to even apply.
“Information Acquired - Name or other personal identifier in combination with: Financial Account Number or Credit/Debit Card Number (in combination with security code, access code, password or PIN for the account)”
How does my CC info get transferred to the insurer? There’s no such transaction afaik.
Like you mentioned, it's probably different for those who purchase their own insurance.
California is not the entire world, believe it or not.
There have been very few dental practices who have paid fines for HIPAA violations and one that stands out is one who hired a document shredding firm to destroy old paper patient records. The shredders pick up a bunch of files and just drove around the corner and hucked them into an open dumpster where they were found. The dentist was fined as the result of their assumption that a document shredding firm would, you know, shred documents.
https://decisions.ipc.on.ca/ipc-cipvp/phipa/en/item/135056/i...
Another where a manager lit a big bonfire at home but put in too much at a time and they asteroided around in burnt and unburnt manner.
Pre-tech breaches :)
Does SiteLink have issues too? I think they do.
I feel like we all deserve this somehow for allowing bad practices like this to proliferate in the favor of business objectives
We never stored CVVs or any of that insane nonsense though. Our systems only ever saw CC info in transit but they were never stored on-site.
God I miss that company. Working with smart people is great.
Why on earth you'd want to deal with credit card information and the attacks it attracts is beyond me. It's not like you're locked to the your provider, the tokens can be transferred... Not easily, but it can be done.
And no, companies would never pay Stripes asking price. You can negotiate much much lower rates with companies like Valitor/Rapyd or certain banks.
That seems like the likely explanation. I don't know what the additional cost would be, but with 7 million customers, it could be a million dollars a year in saving. That would require you to be able to be PCI compliant for less than that amount and the risk is still considerable, you could lose your VISA or MasterCard contract pretty quickly and then you're out of business.
We had a situation where scammers would use our site to check stolen credit cards, we got at most 7 days to handle the problem or VISA would close our account. I'd imagine that failing out of compliance would hit equally hard.
It's kind of silly though. They are no more "secret" than your credit card number itself or expiration date. Once you give it out once or hand your credit card to literally anyone, it's out. Now instead of acquiring N numbers, the hacker needs to acquire N+3 (or N+4) numbers.
Our payment system needs something like:
struct {
string credit_card_number;
string expiration_date;
string insecurity_code;
};
We are living in a world with bozos in charge who can't seem to develop a secure payment system, so we as users need to simply assume that all information required to make a purchase on our behalf is public knowledge, and instead diligently check our records for inaccuracies. I don't sweat these "breaches" because I freeze my credit and review all my bank and credit card transactions daily now.
It's not supposed to solve every potential vulnerability, but there is a whole class of exploits, exactly like the one in the article, that result from stolen storage, that this rule is designed to protect against.
This seems almost as reductive as suggesting my mechanic should keep her customers' key(k) in their cars(c) in her parking lot because instead of just acquiring c, now the thieves just need to acquiring c+k.
If we were talking about 3 extra digits on the card number, that would be one thing. But we're talking about a separate authentication factor, which seems pretty worthwhile to me. Getting that info isn't exactly a snap if you don't just find it laying around-- it's not like you can brute force it. I'd be pretty astonished if a credit card company didn't cancel someone's credit card if someone was tried a handful of transactions with random security codes, let alone enough to guess one number in a thousand.
Sure, there are undoubtedly better ways to handle these transactions, but lacking magic wands to change a giant dinosaur of an industry that should have wanted to change on its own, this is a prudent policy-based strategy to mitigate harm. Whether or not you sweat these breaches is a good way to gauge your own processes, but it's not a useful way to gauge industry-wide processes.
If you have a whole database of them, the trick is to try one code with a thousand cards. Even so, that was a major improvement over the status quo before, which was to use the expiration date, meaning you only had to try about 24 or 36 cards with one month/year.
That still sounds like a crapshoot... Of those 1,000 cards, there might be 14 that have 982 as CSV, 9 that have 307, and none with 118. In other words, there's no guarantee whatsoever that any given CSV will be used in a batch of 1,000 or even 10,000 cards.
It's not really another factor in the sense of the three types of factors: Something you know, something you have, something you are. It's just more digits of "something you know" so it's the same factor. It's why 2-factor auth isn't just 2 separate passwords.
There are better ways to handle it. Policy is a good interim step to mitigate damage before they're implemented.
Apple Card rotates the CCV (fixed time interval, AFAICT, not per transaction), so it is a secret, even if only temporarily.
Once you give it out once or hand your credit card to literally anyone, it's out.
Sure, the cashier now has it, but they're not supposed to be entering it into a database so that everyone has it, hence the "PCI" part.
Also some clearer rules/expectations in place that nobody should ever persist the data on disk?
Actually, the credit card system is very secure to you the consumer.
By regulation, you're not liable for anything if your card number is abused in a card not present transaction (typically the case here for numbers stolen over the internet).
I don't have any other form of payment that is as secure, so good job credit cards.
(As a cryptography and security nerd, it took me a long time to learn that while mathematically guaranteed security is very cool, sometimes you can achieve an equal result just by passing a law.)
Online, perhaps credit cards will disappear into password managers and mobile payments (Google and Apple Pay, etc.) with ordinary businesses storing very little.
[1] https://www.theverge.com/2021/8/17/22628455/mastercard-magne...
To put it another way: the value of those extra three digits is that they are indeed "more secret". They exist on far fewer hard drives.
https://randomoracle.wordpress.com/2012/08/25/cvv1-cvv2-cvv3...
I totally see why it just seems like "moar numbers" though, and I find them unnecessarily annoying. I wish they could reduce the complexity (maybe letters, colors or shapes, something more human-compatible), but there's just too much legacy code with too little benefit.
perfect is the enemy of good.