I (and shareme I was responding to) wasn't talking about storing the numbers. I was talking about transmitting them. You can't transmit hashes of credit card numbers and then expect to do anything useful with them.
This is, for example, the md5-hash of my credit card number with "salt" prepended: 8cc8f5b89ae1ce45a8efce26c88b69e7.
Now good luck doing anything useful with this.
My point was just that it's totally fine to rely on SSL for securely transmitting the credit card number. There's no need to encrypt twice and salting isn't possible.
Storing the numbers (or, as you say, authorizations) is something else I a) know nothing about, b) wouldn't want to have to do (see a) and c) didn't comment about.
It should be feasible to hash a whole bunch of credit card numbers looking for a hash collision, especially when the first four digits depend only on the card type and the last one is a check digit or something. I'd have to look up the details, but that leaves me with just over a billion things to hash?
This is roughly the way password crackers work, incidentally. And why they keep telling people to use slow hashes, like bcrypt.
No worries. That's what I was thinking too. The hash isn't my credit card number. Still. This is a very impractical way to "encrypt" a credit card number for transmission
This is, for example, the md5-hash of my credit card number with "salt" prepended: 8cc8f5b89ae1ce45a8efce26c88b69e7.
Now good luck doing anything useful with this.
My point was just that it's totally fine to rely on SSL for securely transmitting the credit card number. There's no need to encrypt twice and salting isn't possible.
Storing the numbers (or, as you say, authorizations) is something else I a) know nothing about, b) wouldn't want to have to do (see a) and c) didn't comment about.