4 ms·

And how would you use that hashed CC number on the server? Unhashing (impossible)? Send the hash to the CC company (good luck)? Do you mean they should have pr

by pilif 16y ago

And how would you use that hashed CC number on the server? Unhashing (impossible)? Send the hash to the CC company (good luck)? Do you mean they should have pre-encrypted the CC number before encrypting it again in the standard SSL transaction? Would that have helped? Because if the PS3 knows how to encrypt and you own the server, decrypting is as trivial as just looking at the plain text For people who don't own the server and are listening in SSL is enough and for people with access to the server neither SSL nor any other encryption is enough. They have done a lot of things wrongly, but this IMHO is not one of them.

tibbon 16y ago
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.
beagle3 16y ago
> Do you mean they should have pre-encrypted the CC number before encrypting it again in the standard SSL transaction? Would that have helped? Because if the PS3 knows how to encrypt and you own the server, decrypting is as trivial as just looking at the plain text You are wrong; They could have done that. That's the whole premise of public key cryptography (google/wikipedia if you are not familiar). It's possible, (and easy) for the client to encrypt something that a client cannot in general decrypt, nor can anyone else without the decryption key. And it is actually a good idea to not put the decryption key on the server you talk to - only on a server that actually talks to the payment gateway. > And how would you use that hashed CC number on the server? Unhashing (impossible)? Send the hash to the CC company (good luck)? Many credit card processors let you do something similar - i.e. you register the CC details once, get a "reference id", and then use that reference id to charge. I'm sure Sony could have used one of them if they cared. > For people who don't own the server and are listening in SSL is enough and for people with access to the server neither SSL nor any other encryption is enough. That is true. However, that is just one facet that needs defense, and one that has had almost no attacks in the last 5 years -- because SSL (if practiced correctly, which it rarely is) solves that problem, and attacking the server is usually easier than listening on the pipes. > They have done a lot of things wrongly, but this IMHO is not one of them. Everything they have done about this is wrong. And the fact you think they didn't, implies that you shouldn't be working on systems that have any sensitive information in them. I sincerely hope you don't, for the sake of your users.
- marshray 16y ago
  It's possible, (and easy) for the client to encrypt something that a client cannot in general decrypt, nor can anyone else without the decryption key. And that's exactly how your typical SSL/TLS handshake works. The problem is how does the client know he's encrypting to the correct public key? He has to have something stored giving him the key in advance or telling him how to authenticate the public key he's asked to use. This is how the protocol messages were decrypted. The hackers modified their own console to trust a new public key, one to which they had the private key.
  - beagle3 16y ago

by pilif 16y ago

tibbon 16y ago

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.

beagle3 16y ago

> Do you mean they should have pre-encrypted the CC number before encrypting it again in the standard SSL transaction? Would that have helped? Because if the PS3 knows how to encrypt and you own the server, decrypting is as trivial as just looking at the plain text You are wrong; They could have done that. That's the whole premise of public key cryptography (google/wikipedia if you are not familiar). It's possible, (and easy) for the client to encrypt something that a client cannot in general decrypt, nor can anyone else without the decryption key. And it is actually a good idea to not put the decryption key on the server you talk to - only on a server that actually talks to the payment gateway. > And how would you use that hashed CC number on the server? Unhashing (impossible)? Send the hash to the CC company (good luck)? Many credit card processors let you do something similar - i.e. you register the CC details once, get a "reference id", and then use that reference id to charge. I'm sure Sony could have used one of them if they cared. > For people who don't own the server and are listening in SSL is enough and for people with access to the server neither SSL nor any other encryption is enough. That is true. However, that is just one facet that needs defense, and one that has had almost no attacks in the last 5 years -- because SSL (if practiced correctly, which it rarely is) solves that problem, and attacking the server is usually easier than listening on the pipes. > They have done a lot of things wrongly, but this IMHO is not one of them. Everything they have done about this is wrong. And the fact you think they didn't, implies that you shouldn't be working on systems that have any sensitive information in them. I sincerely hope you don't, for the sake of your users.

marshray 16y ago
It's possible, (and easy) for the client to encrypt something that a client cannot in general decrypt, nor can anyone else without the decryption key. And that's exactly how your typical SSL/TLS handshake works. The problem is how does the client know he's encrypting to the correct public key? He has to have something stored giving him the key in advance or telling him how to authenticate the public key he's asked to use. This is how the protocol messages were decrypted. The hackers modified their own console to trust a new public key, one to which they had the private key.
- beagle3 16y ago