9 ms·

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

• nsfmc 15y 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 15y ago
    The same way you're able to login to News.YC without sending your actual password via the intertubes.
    • dpritchett 15y 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 15y 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 15y ago
      You mean "not at all"? Just fire up a packet sniffer...
    • jonknee 15y 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 15y 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 15y ago
  Wasn't this debunked?
  • elliottcarlson 15y 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 15y 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 15y ago
    You can store 'authorizations' as a gateway instead and not store the actual number on your server.
    • pilif 15y 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 15y 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 15y 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 15y ago
  "In the clear" and "over SSL" are contradictory in this context.