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.
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.
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
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.
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.
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.
Questions like "is the sum even?" trade a lower opportunity for information leakage for a greater opportunity for a random guess to be correct.
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.
I'd be interested to know how greatly, if someone has the equation for that.
So providing a hashed card number to a potential scammer is just as bad as providing the card number.
You can still get targeted for a direct attack but much less likely to end up caught in a dragnet approach.
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.
> That would prevent using a pre-generated lookup table
Only for a healthy pinch of salt, not a couple grains, right?