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.
> 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.
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.
> And that's exactly how your typical SSL/TLS handshake works.
True.
> 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.
True again. In the SSL/TLS, this is the "trusted roots" certificates, that the browser was created with.
Why wouldn't the PS3 have a "trusted root" as such?
> 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.
Cool. But that doesn't let them decode _other_ clients' transmissions -- much like putting a new root certificate in your own browser doesn't make a session less secure for anyone else.
Sony made many mistakes here, most of them due to either extreme hubris or extreme incompetence.
But that doesn't let them decode _other_ clients' transmissions -- much like putting a new root certificate in your own browser doesn't make a session less secure for anyone else.
Right, we don't know that's happened yet, except we hear that Sony's backend systems were compromised too. That could be completely unrelated, or the client and server hacks could combine in a way that makes every PS3 compromised. I find it an interesting question but we probably have to wait for more details from Sony.
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
"in the clear over ssl instead of hashing them"? am i missing something here?
is ssl insecure? is there some way to charge a credit card that doesn't actually involve sending the number to anybody?
I'm not sure I understand you; CC numbers are not passwords. You can't salt and hash them on one end and then confirm on the other end; you need to send the whole number if you expect to process a charge against it.
The HN login sends your password over the internet. It doesn't even use SSL. It is in the clear, readily visible to anyone able to run a packet sniffer on your traffic.
No - parent mentioned SSL - originally people were claiming it was sent as a clear text POST - the part that people failed to recognize was that it was over SSL and that is what was debunked later on.
