Possibly. It looks like they've found a way to accurately 'guess' the codes Apple has already generated and distributed to be sold. The only thing for Apple to do now is recall the cards with the possibly compromised numbers and re-issue new ones with a randomly generated number.
This reminds me of when Vista came out. Someone found a way to get legitimate activation keys to activate their pirated copies, which meant that people buying them off of the shelf couldn't activate because that key was already used.
I'm actually working on a project involving large numbers of unique codes. While we're actually going with the random system and a web service to do lookups for the end point system, that approach can introduce a lot of cost and risk.
Perhaps they want the redemption side to not be reliant upon a backend code lookup and validation system (due to uptime, performance, etc...). Perhaps they thought no one would break it, and that would save them from having to build a high availability, low latency, high throughput, lookup system with some amazingly large database tables.
But doesn't it require a live validation system anyway? Otherwise, your friend could reuse your code.
And, uh, redeeming an iTunes gift card ain't much use if the iTunes store is down. Also, I don't see why the system would have to be particularly low latency or high throughput.
One advantage of, say, a hash function over (pseudo)random numbers is that the same input guarantees the same output. It doesn't seem that important in the case of gift cards, though.
Suppose you're running the team at Apple that works on the iTunes gift codes. What do you do here to cut your losses?
Obviously change the algorithm used to generate the codes for a start. And even though the codes themselves are indistinguishable from real codes, you can probably detect patterns in their use (ie, someone from a town in China who's never had an iTunes account before suddenly buys $100 of music) and prevent a subset those codes from being redeemed (with some very small amount of false positives).
It might've been not the algorithm that got broken, but, say, a private (RSA) signing key was recovered. It all really depends on how exactly the whole thing is designed.
What? No, just store every key that you officially sell in an internal database. Now if someone enters a key you check if it's in your DB, therefore if the key has been legitimately issued. Everything else gets rejected and your now 100% counterfeit safe, unless someone hacks your database, which is unlikely. Don't wanna pick on apple, but that's pretty much how things like that are done.
Should Best Buy report back to Apple whenever a card is sold?
Many gift cards sold at retail have to be "activated" at the register (presumably to cut down on shoplifting); I don't know what this involves but there may already be some communication.
Well, in case of retail cards the keys are registered before shipping. You give the manufacture a set of registered keys, which are then printed on the cards. If done right you won't have any issues - that's exactly what people are doing with CD-Keys or Prepaid-Cards. However, if you mess up (can't always avoid mistakes) and have shipped invalid keys or may be the key-printer didn't work right, you have the customer send you the certificate card and you can refund him.
It's by far the better system than using just a algorithm-based genuine check, especially for things that directly translate into money, like gift certificates.
> No, just store every key that you officially sell in an internal database.
My point is that such keys can now be generated independently of the sale. In other words, key_A is generated by a sale and key_A is generate by the algorithm. When key_A is presented, what do you do?
> My point is that such keys can now be generated independently of the sale.
I'm pretty sure his suggestion is to have the keys generated randomly, so that they cannot be generated independently of the sale. If we are to believe him, this is standard operating procedure for businesses that are not apple.
Many serial number protected commercial applications have had their algorithms for validating a SN cracked and Key Generators spit out any number of valid serials for them.
Why would they use an fixed algorithm like that instead of using a good random generator and maintaining a database of valid codes? Perhaps they want the redemption side to not be reliant upon a backend code lookup and validation system (due to uptime, performance, etc...). Perhaps they thought no one would break it, and that would save them from having to build a high availability, low latency, high throughput, lookup system with some amazingly large database tables.
Is it possible that Apple might not mind so much if this encourages people to buy more iPods at the expense of music sales? Depends on the relative margins, I guess.
A $200 gift card going for the equivalent of $2.60 (and zero of that 2.60 going to Apple)? I would expect that right there is higher than the profit margin of an iPod.
Since Apple has to turn around and pay 70% of that $200 to the copyright holders of the purchased content, I'm sure they stand to lose quite a lot more than they could possibly gain.
Sounds like sloppy design.