> sum of the last 4

It's a chicken/egg problem of not wanting to give information first, but a one-way function (hash) is a fantastic idea. The collision possibilities in this particular function are worrisome, though.

It'd be unreasonable to ask someone to perform a hash of those last four digits (how would your mom respond if the bank asked her for the sha256 hash of her card number?), but it could be helpful to ask questions that don't reveal too much information, like, "is the sum of the last four digits even?" or "is the sum evenly divisible by 3?"

It would be difficult to come up with something you could reasonably ask an account holder to figure out on their own that also wasn't easy to randomly guess.

> like, "is the sum of the last four digits even?" or "is the sum evenly divisible by 3?"

Exactly. After only a few of these you have an equivalent security level to checking the four digits directly but at each step of the way there is a 50% chance that the attacker, not knowing the number yet, gets it wrong and you stop giving more info. If they do a thousand calls a day, they'll still get some people, but it's probably not you so that's at least a small win.

You might enjoy learning about PAKE/SPEKE, which has similar properties.

> An important property is that an eavesdropper or man-in-the-middle cannot obtain enough information to be able to brute-force guess a password without further interactions with the parties (Wikipedia: PAKE)

Just enough enjoyment to then get depressed wondering why nobody is using these nice things

My mom would only have a 50% chance of correctly adding four single-digit numbers, and if she had to divide them by 3, she'd be lost.

She's an intelligent woman who's just lousy at arithmetic. I'd guess hers would be approximately the median experience if something like this became standard.

What I was suggesting wasn't asking the account holder, but asking the bank. With a little training, the call center reps should be able to handle adding together the last few digits of a card number.

I agree that asking account holders for this would be confusing, but since the bank is the one calling in this case it makes sense that the caller (bank) should provide information first.

Of course, it appears that in this guy's case, not even this would have worked, since they apparently had his full card number.

If the account holder has to ask the bank for a piece of information, the account holder will also have to produce it for comparison.

Summing the last four digits could unintentionally leak information (what if those digits are all zeros?), so the challenge question should be carefully chosen by the bank, not just whatever the account holder comes up with.

Can you explain what the information leak would be? Also, I think it's not possible for a credit card to end in all zeroes.

There may be inferences you can make from the sum that aren't immediately obvious. If cards can end in four zeros, the sum and the last four digits contain equivalent information, but you would also confirm that three of the digits are zeros if the sum was 1. It's something that, if I were a bank, I would want someone with a background in number theory to weigh in on. If I were a paranoid bank exec, I wouldn't trust the low-wage customer support reps I had on staff to vet customer questions for how much information they might leak and would instead have blanket prohibitions on answering questions from customers until after the authentication phase of the call.

Questions like "is the sum even?" trade a lower opportunity for information leakage for a greater opportunity for a random guess to be correct.

I understand the perspective of the paranoid bank exec! But if the alternative is that their customers are trained to give out personal information whenever someone calls and says they're from the bank, that's quite possibly worse.

It would be nice if when someone called me from an institution, they gave me a code that I could enter after calling the number on the back of my card. That way I would have confidence I'm talking to the bank and would feel comfortable giving out verification information.

In the past, it has always been a headache to find my way back to the department that called me.

Don't forget the last digit is a checksum digit too. Which I still can't give you an attack, but I also agree that I definitely can't say I'm sure there isn't one.

That does reduce the number of possibilities greatly, which might matter for some attack scenarios, but usually not IMHO as rate limits should thwart any online brute force.

I'd be interested to know how greatly, if someone has the equation for that.

For sure. I wonder what the state of the art is in human-friendly challenges.

Please select pictures containing a boat.

"What is pictured on the front of my card?" might not be a bad question (assuming the bank allowed account holders to choose from a large variety of images or upload their own). It's data that the bank could capture on card issuance, that anyone who has been in the physical presence of the card could answer, and that would not be captured by payment systems.

The dataset for hashed credit card numbers is small enough that it can be easily represented in a static lookup table, or brute forced.

Brute forced by a human voice on a phone call? You must talk quickly.

He almost certainly meant that sha256(card number) can be bruteforced to figure out what card number was hashed. 10^12*256 bits is only 29 TiB.

So providing a hashed card number to a potential scammer is just as bad as providing the card number.

So just ask the other party to give you a salt they generate on the spot? And/or you do so on your end?

You can still get targeted for a direct attack but much less likely to end up caught in a dragnet approach.

That would prevent using a pre-generated lookup table but doesn't help much with brute force attacks. All possible card numbers is a finite set, and if you have the sha256(card number + salt), you can figure out which card number was used as input given the improbability of sha256 collisions within that set.

Keep in mind this in the context of an account holder asking the bank to authenticate themselves on a phone call using data only the bank and the account holder should know. sha256(card number) was an example of something that is obviously inappropriate, and I don't think sha256(card number + salt) is any different qualitatively.

Not to mention, how many bits of salt can you transmit by voice in this context without this turning into a whole song and dance?

> That would prevent using a pre-generated lookup table

Only for a healthy pinch of salt, not a couple grains, right?

This happens with my doctor's scheduling people all the time. "Hi I'm calling for $YOU, will you please verify the last 4 of your social and full DOB?" uhhhh... no I will not, random person

DOB made sense because 10,000 people in the world have the same birth date. DOB (without PII) didn't narrow enough to identity the person. Regarding that last 4 SSN, yea I would never give that out.

My doctor office required me to provide my DOB before I can schedule an appointment or questioning over the phone. My pharmacist required my DOB before I can get my meds from them. If I don't provide my DOB, they will turn me away and assumed that I'm a scammer.

DOB is often just to make sure they have the right person, and not an alias. But yeah, SSN, I wouldn't give it out like this.

Oooh, good way to abstract out names from stories! Stolen for my own future use.

I had a similar scam fraud call from my bank and I asked them to verify the last 4 of my SSN. They had it! But later they said they'd send a text verification but it was asking to add my card to apple pay. So I hung up and called my bank back and they had no record of the call. It was freaky that the scammer had so much info though.

Who cares if you've never come across it before. It happens.

How else do they prove they are a real bank???

You are making the same dumb mistake this guy made.