Hacker News Reader

Comment by jadedoto | Hacker News Reader

I dont think he is stressing the ease of doing this with credit card numbers. The sample space he is suggesting generating is far too large... You can usually identify the first several digits simply by the issuing organization, as they all use standardized numbers, the remaining digits must pass a certain checksum algorithm. So really generating a bunch of valid cc numbers is quite trivial. Matching exp dates with numbers and ccv numbers.. Different story.

But i wonder what the limits to effectiveness is on this attack. I usually randomly swirl around with a smear tool to blur out things...

View on HN

Bank of America uses a horrible method for generating debit card numbers. It's a standard prefix + account number + sequence number + check digit. If you have stolen someone's BofA debit card number then you can easily guess the replacement card's number (just increment the sequence number and recalculate the check digit). From there you just need to guess the expiration date (a comparatively trivial task).

Also they generate your PIN by running your account number through a DES encryption round. This method is known to be vulnerable to attack:

http://www.cl.cam.ac.uk/~mkb23/research/PIN-Cracking.pdf

Chase PINs are by default 3210 - guess how many people still have that pin.

Either you're skipping over a lot of information in the process of how that number's generated, or that's not how they do it anymore (and not how they've done it for at least the last couple of years).

I got a replacement BofA debit card a few months ago, and this is exactly how they did it — only the last two digits are different.

This may be only in Washington and Idaho though, as there are several different legacy BofA backends as a result of M&A bullshit.

But that's for debit cards - I think most banks include the account number in a debit card number. You would still need the CCV number from the back of the card for the attack to work.

I haven't noticed any other bank which had the same practice.

Also, not all online merchants use CCV. Also consider the risk of creating fake physical CCs, no address or CCV necessary.

Just checked— my credit union debit card number includes my account number.

CCVs aren't always required for transactions.

CCV proves the cardholder was present at the time of the transaction. Online merchants are never allowed to store CCV numbers.

edit: CCV proves that you at one time had access to the CCV number.

Online merchants are supposed to comply with PCI-DSS - not store your CCV ever, never transmit your number unencrypted, never store cardholder information unencrypted, plus tons of management controls and audit controls over the same.

In practice, let's just say lazy programming is everywhere. I've seen many people who handle online transactions and violate PCI-DSS to some degree, including storing CCV numbers.

They can ask for them though.

.. indeed, and they often do.

I'd expect random swirls to be reliable, or any obfuscation that introduces a reasonable amount of entropy. This whole attack relies on an almost-exact replication of the original blurred image. If you do something a computer can't easily reproduce over and over again, or something that looks the same no matter what the obfuscated content is (like blacking out), this attack cannot work.

Actually swirls are very reversible - http://news.bbc.co.uk/1/hi/7384834.stm (Paedophile caught from video with swirled obfuscation of his face.)

You're definitely right about adding entropy though, but why bother? Just blacking it out guarantees how much information is available - zero.

That's not a random swirl. Interesting though

Reply on news.ycombinator.com