I really enjoyed his Javascript credit card generator page. It says, "This is just an example for educational purposes. Don't use these numbers for anything ever," and is surrounded by A LOT of Google AdSense boxes. It's practically contemporary art.
This article misses quite a few important details.
Most importantly, the first 6 digits of a Visa numer constitute a "BIN" (Bank Identification Number). I have heard that MasterCard uses variable number of digits for BIN, but I don't have proof. Some places will have lists of BINs (there's really not that many) and reject "card numbers" that don't have a correct BIN.
Secondarily, MasterCard numbers start with "51", "52", "53", "54" or "55". AmEx starts with "34" or "37", and Discover Cards start with "6011" or "650".
Generating a good "fake" CC number is a bit more complex than the first digit, and getting the Luhn checksum correct.
One of the other commentors is correct in having a huge number of checks around the format of a "credit card number". In practice, all kinds of rubbish ends up in the card number field, and every once in a while, it will pass the Luhn checksum and cause problems down stream.
Absolutely. The article glosses over the other security features that are required to create a card number that would pass the extensive authorization process in the card networks. The information in the article is already in the public domain, so the 'exposure' doesn't increase fraud risk to anyone other than the companies offering 'free trials' for merely providing a number that passes a checksum test.
The amount of security in a particular system is typically proportional to the value of what is being secured. If the companies using a mere checksum test thought the process needed to be more secure they could do a real authorization against the number.
There was a time in the past when some services online wouldn't immediately authorize the card - it would only check if the value was a "valid" number.
So, you could, hypothetically, get 1-3 hours of shell internet access based on a generated number.
I've written at least 3 versions of this algorithm in various flavors of RPG for the iSeries (AS/400).
The most complete one weighs in at 251 lines (175 w/o comments) but it also does a lot of checking to make sure that the CC number matches the CC type.
I did too at a previous job where we had a network scanner that could identify (in theory) credit card numbers on the fly as they were accessed or stored into database and file shares.
The app I wrote was a few dozen lines of perl and was used as a QA tool. You could tell it to generate X number of credit card numbers, and also specify flags for generating a mix of numbers (all common US and Int'l formats) as well as a mix of valid/invalid numbers (based on checksum data).
It was a fun spend of a couple hours, and it was amazing to determine how simple it was to generate valid numbers, but then they're also useless without CVV, billing zip and street address for the most part.
I remember the days when cvv/cvc was not asked for by websites. These 'credit card number generators' were in huge demand and sold for a lot of cash. Of course you could always dig around and get them for free.
The latest of these programs was written in vb4, which I could decompile to look at the source (the algorithm wasn't easily available then).
CVV/CVC doesn't have much to do with it (I can process cards with nothing more than the number). The issue was that sites were not authorizing cards in real time.
