5 ms·

This is interesting: "Traditionally the trust boundary for a web service exists between the server and the client. But Sony believes they own the client too, so

by praptak 16y ago

This is interesting: "Traditionally the trust boundary for a web service exists between the server and the client. But Sony believes they own the client too, so if they just put a trust boundary between the consumer and the client(can't trust those pesky consumers), everything is good. Since everyone knows the PS3 is unhackable, why waste money adding pointless security between the client and the server?" I wonder if he's purely speculating or maybe knows something more. It's also good to see he can at least still talk about Sony security in general (or can he?)

JoachimSchipper 16y ago
See http://news.ycombinator.com/item?id=2480141 http://news.ycombinator.com/item?id=2480141 - it has been suggested on HN that Sony can't keep hacked Playstations out of the dev channel. It's likely that GeoHotz is much more knowledgeable/better connected (on this topic, at least).
shareme 16y ago
its not speculation, they passed CC numbers in the clear over SSL instead of hashing them..
- nsfmc 16y ago
  "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?
  - scarlson 16y ago
    The same way you're able to login to News.YC without sending your actual password via the intertubes.
    - dpritchett 16y ago
      So some sort of public-key cryptography? I didn't realize that the HN login page didn't send a password on a login.
    - xsmasher 16y ago
      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.
    - JoachimSchipper 16y ago
      You mean "not at all"? Just fire up a packet sniffer...
    - jonknee 16y ago
      But you do send your actual password... The hashing occurs on the server. Also, this has nothing to do with credit cards. They are not passwords.
    - tzs 16y ago
      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.
- Indyan 16y ago
  Wasn't this debunked?
  - elliottcarlson 16y ago
    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.
- 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.
- jsight 16y ago
  Who sends hashes of credit card numbers instead of the #s themselves? And how is this passed through to the processor? I've not seen such a protocol for sending CC#s from the browser before.
- marshray 16y ago
  "In the clear" and "over SSL" are contradictory in this context.

by praptak 16y ago

JoachimSchipper 16y ago

See http://news.ycombinator.com/item?id=2480141 http://news.ycombinator.com/item?id=2480141 - it has been suggested on HN that Sony can't keep hacked Playstations out of the dev channel. It's likely that GeoHotz is much more knowledgeable/better connected (on this topic, at least).

shareme 16y ago

its not speculation, they passed CC numbers in the clear over SSL instead of hashing them..

nsfmc 16y ago
"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?
- scarlson 16y ago
  The same way you're able to login to News.YC without sending your actual password via the intertubes.
  - dpritchett 16y ago
    So some sort of public-key cryptography? I didn't realize that the HN login page didn't send a password on a login.
  - xsmasher 16y ago
    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.
  - JoachimSchipper 16y ago
    You mean "not at all"? Just fire up a packet sniffer...
  - jonknee 16y ago
    But you do send your actual password... The hashing occurs on the server. Also, this has nothing to do with credit cards. They are not passwords.
  - tzs 16y ago
    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.
Indyan 16y ago
Wasn't this debunked?
- elliottcarlson 16y ago
  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.
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.
jsight 16y ago
Who sends hashes of credit card numbers instead of the #s themselves? And how is this passed through to the processor? I've not seen such a protocol for sending CC#s from the browser before.
marshray 16y ago
"In the clear" and "over SSL" are contradictory in this context.