Constantly Changing CVVs Could Prevent Fraud

[CreditInspired]

@Saeren

Discover allows you to deactivate and reactivate your card on a whim

[trusty]

---

@Anonymous wrote:

"The new cards have a small screen displaying a three-digit number, which replaces the usual static code on the back. A small lithium battery powers the system, and an algorithm determines when to change the code on display."

"The refresh rate will also affect the life of the card — a 60-minute refresh interval drains it after four years.."

Credit Cards With Constantly Changing CVVs Could Prevent Fraud

---

Cool article.

"Once it nails down the ideal refresh rate through this pilot trial, PNC plans to take the technology wide"

It seems to me that - if this idea were designed to prevent fraud - than the ideal refresh rate would simply be... to change the code after each transaction.

But, as already mentioned, this whole idea would cause major problems for anything setup on autopay. Which is why unique credit card numbers is better for autopay, and for that matter, online purchases; because it allows the consumer to control payment access.

Randomly changing the CVV code all the time just makes it harder for the consumer to re-use the card with each merchant... which is really just creating an additional unnecessary burden for the consumer.

This new tech is looking for a solution to a problem that doesn't even exist; and would more than likely cause more glitches and hold-ups than it would solve.

Also, How would the online system even know which CVV number the card just changed to? - If the card is not connected to the web, than it would have to be setup on a rotating pattern... that both the system and the card followed. Anytime there is a pattern, we're talking data breach city; because eventually the pattern would be figured by hackers.

A better idea would be to simply scan the Iris of the Eye to verify transactions; because, no two people have the same Iris. This way, there would only need to be a camera present to scan the eye. The actual credit card - or swiper - wouldn't need to be present, or even exist in physical form. The point is to verify the consumer in question. Then, the consumer could select any one of their accounts, and verify with their Iris. Consumers would be able to scan their own eye, with their smart phone, or use a scanner at the register to check out. Done and done.

We could also start with fingerprints, but scanning the eye (from afar) is better for sanitary reasons. The scanner would not need to come into contact with the consumer, whereas, a fingerprint scanner would need to be touched by everyone, and could easily spread germs.

Naturally, there would always need to be a backup system, where the consumer could simply pull out their ID card, or their credit card, to verify purchases.

[Ardecko]

Cryptographically secure random number generation is pretty standard in the banking industry, going back 20+ years.

It's basically a Google Authenticator attached to your credit card. This is a good thing.

[trusty]

---

@Ardecko wrote:
Cryptographically secure random number generation is pretty standard in the banking industry, going back 20+ years.

It's basically a Google Authenticator attached to your credit card. This is a good thing.

---

How does the payment system know which new CVV that the card just generated, if the card isn't connected to the web or swiped?

The system could only know - if the CVV generator was based on a pre-ordained pattern... which means it could be hacked.

Also, a mere 3 digit code can never be anywhere remotely as secure as a 6 to 8 digit Authenticator code.

[Anonymous]

---

@trusty wrote:

How does the payment system know which new CVV that the card just generated, if the card isn't connected to the web or swiped?

The system could only know - if the CVV generator was based on a pre-ordained pattern... which means it could be hacked.

---

 It's called 'Time-Based One-Time Password', and I use it daily for logins to several company servers. A form of this has been used for decades now.

Here are the details: https://medium.freecodecamp.org/how-time-based-one-time-passwords-work-and-why-you-should-use-them-i...

Short version:

TOTP stands for “Time-Based One-Time Password”.

A TOTP uses the HOTP algorithm to obtain the one time password. The only difference is that it uses “Time” in the place of “counter,” and that gives the solution to our second problem.

That means that instead of initializing the counter and keeping track of it, we can use time as a counter in the HOTP algorithm to obtain the OTP. As a server and phone both have access to time, neither of them has to keep track of the counter.

The mobile app encodes the time using a pre-shared secret key (usually a QR Code scan gets this into the app), and sends it to the server, which looks up that particular user's secret key key and encodes the current time itself, then compares. The time can be anything within a 30 second (or some other) interval - it does not have to match exactly with what the client sent.

Now, technically, if you get the secret key from the user's phone you can get access to whatever TOTP is protecting, but that will only work for that particular user - not the rest of the system. It's an awful lot of work to hack just one person.

[trusty]

---

@Anonymous wrote:

---

@trusty wrote:

How does the payment system know which new CVV that the card just generated, if the card isn't connected to the web or swiped?

The system could only know - if the CVV generator was based on a pre-ordained pattern... which means it could be hacked.

---

 It's called 'Time-Based One-Time Password', and I use it daily for logins to several company servers. A form of this has been used for decades now.

Here are the details: https://medium.freecodecamp.org/how-time-based-one-time-passwords-work-and-why-you-should-use-them-in-your-app-fdd2b9ed43c3

Short version:

TOTP stands for “Time-Based One-Time Password”.

A TOTP uses the HOTP algorithm to obtain the one time password. The only difference is that it uses “Time” in the place of “counter,” and that gives the solution to our second problem.

That means that instead of initializing the counter and keeping track of it, we can use time as a counter in the HOTP algorithm to obtain the OTP. As a server and phone both have access to time, neither of them has to keep track of the counter.

The mobile app encodes the time using a pre-shared secret key (usually a QR Code scan gets this into the app), and sends it to the server, which looks up that particular user's secret key key and encodes the current time itself, then compares. The time can be anything within a 30 second (or some other) interval - it does not have to match exactly with what the client sent.

Now, technically, if you get the secret key from the user's phone you can get access to whatever TOTP is protecting, but that will only work for that particular user - not the rest of the system. It's an awful lot of work to hack just one person.

---

So basically, it's more simple than a random pattern. It's based on time. Something that any two bit hacker can figure. Now, that's an oversimplification to be sure; but, a 3 digit code is not going to be anywhere near as difficult to hack as a 6 digit one. It's light years apart.

The main point though, is that there's not really a whole lot of value in all of this obfuscation, at least for consumers. This protects the issuer, far more than the consumer. The consumer still has the card in their possession - to be potentially stolen and hacked. Still, it fails to account for autopay, as well.

[Anonymous]

---

@trusty wrote:

So basically, it's more simple than a random pattern. It's based on time. Something that any two bit hacker can figure. Now, that's an oversimplification to be sure; but, a 3 digit code is not going to be anywhere near as difficult to hack as a 6 digit one. It's light years apart.

 It's based on time, PLUS the main security ingredient: the pre-shared key. Without this key a hacker has nothing. They will just be sending randomly encoded time values that never match with what the server generates. They'll be locked out in 3 attempts or less anyway, without locking out the real authorized user.

The main point though, is that there's not really a whole lot of value in all of this obfuscation, at least for consumers. This protects the issuer, far more than the consumer. The consumer still has the card in their possession - to be potentially stolen and hacked. Still, it fails to account for autopay, as well.

---

I like the virtual credit card number idea the best. You make some valid points.

[OmarR]

---

@trusty wrote:

---

@Anonymous wrote:

"The new cards have a small screen displaying a three-digit number, which replaces the usual static code on the back. A small lithium battery powers the system, and an algorithm determines when to change the code on display."

"The refresh rate will also affect the life of the card — a 60-minute refresh interval drains it after four years.."

Credit Cards With Constantly Changing CVVs Could Prevent Fraud

---

This new tech is looking for a solution to a problem that doesn't even exist.

---

Depending on which report you read and how it "calculates" total loss, credit card fraud ranges from $15-$25 Billion annually, most of it being online. Yeah, that's a problem that does exist.

@trusty wrote:

 This protects the issuer, far more than the consumer. 

Considering that 99% of the time, the issuer takes the loss....Yeah, that's pretty much a given.

This pilot program may or may not be the answer. It may or may not put a dent into the problem. But expecting consumers to freeze and unfreeze after each and every use of each card just aint gonna happen. 

[Anonymous]

Honestly, this idea will probably work out well for everyone. No card should ever stay the same. It's static information and static is never good. lol