14 ms·

You can store 'authorizations' as a gateway instead and not store the actual number on your server.

• pilif 16y ago
  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.
  • Natsu 16y ago
    I hope you're kidding about the MD5 thing. 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.
    • pilif 16y ago
      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
• tzs 16y ago
  You can do a credit card transaction through the gateway, and then do subsequent on-file transactions by referencing the previous transaction. The initial transaction cannot be a reference transaction. You have to actually send the CC number to the gateway for that first transaction.
  • tibbon 16y ago
    Right, and I'm unsure why Sony would store anything past that initial transaction. Once they have a reference, trash the initial number.