Say obfuscation = encrypted.
> It's vulnerable to cookie jacking over non HTTPS
That's why you use the secure and httponly flag for the cookie.
> It's vulnerable to theft if you have access to a computer where someone has logged on
Pretty much everything is vulnerable to theft if you have access to a computer where someone else has logged on.
Are there any actual crypto experts reading who'd comment on the dangers of encrypting multiple credit card numbers with the same key? Keep in mind for a single bank the first 4 digits of a credit card will all be one of two choices (their Visa or Mastercard prefix) and for a single branch I think the first 6 digits will be the same for every customers Visa card, which only leaves 9 digits (and the checksum).
Surely a naive approach like:
$encrypted_cookie_text = any_encryption_function($sixteen-digit-cc-number,$global_key);
could be brute forced pretty readily, with a knowledgeable guess at the first 6 digits and an understanding of the checksum algorithm, you're only left with one billion possible numbers. (In fact, I wonder if rainbow tables already exist for this for various values of any_encryption_function()?I don't see how that follows. Storing credit card details on the server is generally a bad thing to do and takes a lot of work to get it to be PCI compliant.
What would be wrong with a different key/salt per user stored on the server, with the credit card number stored in a short-lived, secure, httponly cookie?
Also you didn't address the most important point, PCI compliance.
The method Santander employs is unquestionably a bad way to do things.
- I have no idea if it's PCI compliant (I would hazzard a no here)
- Obfuscation is such weak security it should be considered as pretty much worthless
- It's vulnerable to cookie jacking over non HTTPS
- It's vulnerable to theft if you have access to a computer where someone has logged on
There are other ways of doing it, putting it in a short live cookie is one of the worst ways