8 ms·

"It said some records also included encrypted payment card information, but it could not rule out the possibility that the encryption keys had also been stolen.

"It said some records also included encrypted payment card information, but it could not rule out the possibility that the encryption keys had also been stolen." Oh dear.

nerdponx 8y ago
Is payment information not typically salted & hashed like a password?
- londons_explore 8y ago
  Imagine you could make payments with a salted and hashed credit card number. Except that doesn't really make anything better, because now an attacker could simply use that salted and hashed credit card number elsewhere to make payments too! The real solution is to use something like OAuth for payments. You authorize a merchant to take ongoing payments from you, and the card issuer gives the merchant a token which is only useful for making payments from you to them, and can't be used to make payments to anyone else.
  - zimpenfish 8y ago
    Isn't that basically what Apple Pay does?
    - londons_explore 8y ago
      Apple pay uses a card number per merchant, but that card number could still be used at any other merchant. Eventually that loophole could be closed, but payment systems move like molasses... Expect it to take 20+ years... It simply means if the card number is used for fraud, it'll be easier to track down who leaked the card numbers.
- spydum 8y ago
  Not if you need to reverse it to actually send to payment card processor.
- raesene9 8y ago
  Whilst you can't hash it like a password as you need to be able to transfer it onwards, modern systems make tokenisation possible, where you immediately pass the details to the card processor, don't store them at all, and get back a token that can be used for that transaction. https://squareup.com/gb/townsquare/what-does-tokenization-actually-mean https://squareup.com/gb/townsquare/what-does-tokenization-ac...
flavor8 8y ago
~"We encrypt sensitive data at rest. And we store decryption keys on our user facing app servers so that apps can decrypt the data. Cool, right?"
- londons_explore 8y ago
  Lets be honest, all reversible encryption schemes are some version of this...
  - willvarfar 8y ago
    I'm not quite sure whether irreversible encryption is a thing in this context (its sometimes used to talk about e.g. password storage, but I think that's a very different use-case), so I'll sally in with an interesting tangent: https://en.wikipedia.org/wiki/Homomorphic_encryption https://en.wikipedia.org/wiki/Homomorphic_encryption Homomorphic encryption is a form of encryption that allows computation on ciphertexts, generating an encrypted result which, when decrypted, matches the result of the operations as if they had been performed on the plaintext. Homomorphic encryption can be used for secure outsourced computation ...
    - brianberns 8y ago
      That's interesting, but how do you prevent bad guys from "generating an encrypted result" that you don't want?
      - heavenlyblue 8y ago
        If the variant of the homomorphic encryption you are using is secure, then the bad guys can not generate specifically crafted cyphertext that would decrypt into the result they specifically want.
    - lawnchair_larry 8y ago
      This doesn’t really exist yet.
  - 8y ago
no1youknowz 8y ago
Can anyone recommend solutions (for those that don't know). On how to have an encrypted database for sensitive information, i.e first name, last name, ip, geo data, etc and the encryption keys not be available to hackers when they have essentially gained root?
- hiccuphippo 8y ago
  Maybe keep the keys only in memory in each application? Pull them from some very well monitored service once at startup? Anyone who gained access to the server would have to check the program's memory to get them.
- raesene9 8y ago
  Depends on the use case :) If you don't need to decrypt the data on the same system, you could always use asymmetric encrpytion, so encrypt with the "public" key and then keep the private key elsewhere. If you require to be able to decrypt on the system in question then you need a key somewhere, so secure storage of the key is very important. One option, often deployed in banks, is to store the key in a hardware security module (HSM) and then ensure that it's not available outside of that. There's a load of tradeoffs to using HSMs but they can be useful where symmetric encrpytion is needed.
- jen20 8y ago
  I’m not sure there is a one-size-fits-all right solution here - but having a system where decryption keys should not be extractable by software alone (e.g. an HSM, a service such as AWS KMS or the equivalents in other clouds) sounds like it would have been an improvement in this case (though with no post-mortem it’s hard to know exactly what went wrong). Assuming a layered system, something like Vault transit encryption (perhaps with the master key in an HSM) should keep decryption keys away from front-end machines, though as ever, once you have root and can access the memory of a machine where the encryption keys are stored, most bets are off.
- bkanber 8y ago
  Well, it's still tough. The question is always "gained root to what", cause at some point somebody needs a key. Envelope encryption is a good scheme. Under envelope encryption you have a master key and per-row or per-unit keys. You store the per-unit keys encrypted with the master key, and the master key is stored offsite. For example on an AWS environment, you would use AWS KMS with IAM authentication to handle the master key crypt for the individual keys, and the encrypted versions of the individual keys are stored in a database that you own. You encrypt your data with the individual keys (eg, one key per user, or one key per DB row, or one key per namespace, whatever), but the individual keys are decryptable only by KMS. Under this scheme an attacker must both be able to get ahold of the encrypted individual keys, and be able to decrypt them with the master key. Of course this leaves you very vulnerable if the master key is acquired, but KMS does not allow you to read the master key at all, you have to use the AWS API to make encryption/decryption requests. So the vulnerability is less about how secure the key is and more about how secure your IAM setup and instances are.
tyingq 8y ago
Curious if it matters much that the keys were stolen too. How long to brute force a 16 digit number? With a known subset of 4 digit leaders, and being able to cull the list first for ones with good luhn checksums. Edit: Ugh. Yes. My mind was apparently elsewhere. Keyspace would drive the time needed. Though it is a relatively short list of known plaintext. especially if you focus on the bin ranges for say the three most popular banks in the US. But, only interesting if Marriot was using some encryption with a small keyspace.
- ryanlol 8y ago
  Are you really suggesting that bruting cc #s would be a viable method of committing fraud? If yes, how much would you expect the bruteforcer to earn per successful attempt?
- bradleyjg 8y ago
  I don’t follow. Why is it the size or structure of what’s being encrypted that matters for brute force time rather than the key space of the encryption algorithm. Password hashing is different because there is no key space.
- raesene9 8y ago
  To construct a valid card identity you need more than just a 16-digit number that passes the luhn check. At the very least you'll need cardholder name and expiry to match up, and hopefully you'll need CVV/CVC as well. Of course I really hope the Marriott weren't storing CVV in a reversibly encrypted format.
  - leejo 8y ago
    > Of course I really hope the Marriott weren't storing CVV in a reversibly encrypted format. You're not allowed to store the CV2 in any form that could be recovered (i.e. plain text or reversibly encrypted) or brute forced (i.e. hashed/salted). PCI rules say you simply aren't allowed to store the CV2 after the call for an authorisation, as it's no longer required. If they were storing the CV2 then they're in trouble.
  - 8y ago
ryanlol 8y ago
How is that the "Oh dear."? Do you work for a bank? That seems like the least interesting bit of information here for individuals. It's really bizarre to me that people here seem to consider their credit card numbers more sensitive than their travel history or even contact information.
- raesene9 8y ago
  well possibly not. If the attackers got the keys to decrypt payment details that means that victims, in addition to the identity theft risks, may also face fraudulent transactions on those cards as a risk.
  - ryanlol 8y ago
    Even if the payment information is in plaintext it'll primarily be the banks who are affected, not the customers. I'd be far more concerned about my privacy than my banks money.
    - raesene9 8y ago
      Anyone hit with fraudulent charges has to a) notice them, b) dispute them and c) go through the annoying process of having your card re-issued. As to privacy, after the number of breaches of personal info. there have been, I'd be inclined to let the idea that this level of personal data is private :)
      - ryanlol 8y ago
        >a) notice them Don't you review your charges regularly? Even without fraud you're bound to be losing money to erroneous charges if you don't. >b) dispute them I've usually just had to submit a quick online form consisting almost entirely of checkboxes, while yeah that's some work it's still not going to take more than a minute of my time. >c) go through the annoying process of having your card re-issued. Seems like this is vastly more annoying with some card issuers than others.
Oras 8y ago
and according to the article: "It said an internal investigation found an attacker had been able to access the Starwood network since 2014." 4 years of access, surely the attacker didn't manage to get hold of these keys
codedokode 8y ago
Card information has no value because it is very easy to reissue a card. Things like name or phone number, or address, cannot be changed so easily and have much higher value.
- closeparen 8y ago
  Things like name, phone number, and address are not secret. They are published in the phone book.
- jstarfish 8y ago
  Card information is literally cash money. It's volatile and subject to being rendered defunct, but it still has a lot of value if you can buy a bunch of prepaid gift cards with them before it's deactivated.

"It said some records also included encrypted payment card information, but it could not rule out the possibility that the encryption keys had also been stolen." Oh dear.

nerdponx 8y ago

Is payment information not typically salted & hashed like a password?

londons_explore 8y ago
Imagine you could make payments with a salted and hashed credit card number. Except that doesn't really make anything better, because now an attacker could simply use that salted and hashed credit card number elsewhere to make payments too! The real solution is to use something like OAuth for payments. You authorize a merchant to take ongoing payments from you, and the card issuer gives the merchant a token which is only useful for making payments from you to them, and can't be used to make payments to anyone else.
- zimpenfish 8y ago
  Isn't that basically what Apple Pay does?
  - londons_explore 8y ago
    Apple pay uses a card number per merchant, but that card number could still be used at any other merchant. Eventually that loophole could be closed, but payment systems move like molasses... Expect it to take 20+ years... It simply means if the card number is used for fraud, it'll be easier to track down who leaked the card numbers.
spydum 8y ago
Not if you need to reverse it to actually send to payment card processor.
raesene9 8y ago
Whilst you can't hash it like a password as you need to be able to transfer it onwards, modern systems make tokenisation possible, where you immediately pass the details to the card processor, don't store them at all, and get back a token that can be used for that transaction. https://squareup.com/gb/townsquare/what-does-tokenization-actually-mean https://squareup.com/gb/townsquare/what-does-tokenization-ac...

flavor8 8y ago

~"We encrypt sensitive data at rest. And we store decryption keys on our user facing app servers so that apps can decrypt the data. Cool, right?"

londons_explore 8y ago
Lets be honest, all reversible encryption schemes are some version of this...
- willvarfar 8y ago
  I'm not quite sure whether irreversible encryption is a thing in this context (its sometimes used to talk about e.g. password storage, but I think that's a very different use-case), so I'll sally in with an interesting tangent: https://en.wikipedia.org/wiki/Homomorphic_encryption https://en.wikipedia.org/wiki/Homomorphic_encryption Homomorphic encryption is a form of encryption that allows computation on ciphertexts, generating an encrypted result which, when decrypted, matches the result of the operations as if they had been performed on the plaintext. Homomorphic encryption can be used for secure outsourced computation ...
  - brianberns 8y ago
    That's interesting, but how do you prevent bad guys from "generating an encrypted result" that you don't want?
    - heavenlyblue 8y ago
      If the variant of the homomorphic encryption you are using is secure, then the bad guys can not generate specifically crafted cyphertext that would decrypt into the result they specifically want.
  - lawnchair_larry 8y ago
    This doesn’t really exist yet.
- 8y ago

no1youknowz 8y ago

Can anyone recommend solutions (for those that don't know). On how to have an encrypted database for sensitive information, i.e first name, last name, ip, geo data, etc and the encryption keys not be available to hackers when they have essentially gained root?

hiccuphippo 8y ago
Maybe keep the keys only in memory in each application? Pull them from some very well monitored service once at startup? Anyone who gained access to the server would have to check the program's memory to get them.
raesene9 8y ago
Depends on the use case :) If you don't need to decrypt the data on the same system, you could always use asymmetric encrpytion, so encrypt with the "public" key and then keep the private key elsewhere. If you require to be able to decrypt on the system in question then you need a key somewhere, so secure storage of the key is very important. One option, often deployed in banks, is to store the key in a hardware security module (HSM) and then ensure that it's not available outside of that. There's a load of tradeoffs to using HSMs but they can be useful where symmetric encrpytion is needed.
jen20 8y ago
I’m not sure there is a one-size-fits-all right solution here - but having a system where decryption keys should not be extractable by software alone (e.g. an HSM, a service such as AWS KMS or the equivalents in other clouds) sounds like it would have been an improvement in this case (though with no post-mortem it’s hard to know exactly what went wrong). Assuming a layered system, something like Vault transit encryption (perhaps with the master key in an HSM) should keep decryption keys away from front-end machines, though as ever, once you have root and can access the memory of a machine where the encryption keys are stored, most bets are off.
bkanber 8y ago
Well, it's still tough. The question is always "gained root to what", cause at some point somebody needs a key. Envelope encryption is a good scheme. Under envelope encryption you have a master key and per-row or per-unit keys. You store the per-unit keys encrypted with the master key, and the master key is stored offsite. For example on an AWS environment, you would use AWS KMS with IAM authentication to handle the master key crypt for the individual keys, and the encrypted versions of the individual keys are stored in a database that you own. You encrypt your data with the individual keys (eg, one key per user, or one key per DB row, or one key per namespace, whatever), but the individual keys are decryptable only by KMS. Under this scheme an attacker must both be able to get ahold of the encrypted individual keys, and be able to decrypt them with the master key. Of course this leaves you very vulnerable if the master key is acquired, but KMS does not allow you to read the master key at all, you have to use the AWS API to make encryption/decryption requests. So the vulnerability is less about how secure the key is and more about how secure your IAM setup and instances are.

tyingq 8y ago

Curious if it matters much that the keys were stolen too. How long to brute force a 16 digit number? With a known subset of 4 digit leaders, and being able to cull the list first for ones with good luhn checksums. Edit: Ugh. Yes. My mind was apparently elsewhere. Keyspace would drive the time needed. Though it is a relatively short list of known plaintext. especially if you focus on the bin ranges for say the three most popular banks in the US. But, only interesting if Marriot was using some encryption with a small keyspace.

ryanlol 8y ago
Are you really suggesting that bruting cc #s would be a viable method of committing fraud? If yes, how much would you expect the bruteforcer to earn per successful attempt?
bradleyjg 8y ago
I don’t follow. Why is it the size or structure of what’s being encrypted that matters for brute force time rather than the key space of the encryption algorithm. Password hashing is different because there is no key space.
raesene9 8y ago
To construct a valid card identity you need more than just a 16-digit number that passes the luhn check. At the very least you'll need cardholder name and expiry to match up, and hopefully you'll need CVV/CVC as well. Of course I really hope the Marriott weren't storing CVV in a reversibly encrypted format.
- leejo 8y ago
  > Of course I really hope the Marriott weren't storing CVV in a reversibly encrypted format. You're not allowed to store the CV2 in any form that could be recovered (i.e. plain text or reversibly encrypted) or brute forced (i.e. hashed/salted). PCI rules say you simply aren't allowed to store the CV2 after the call for an authorisation, as it's no longer required. If they were storing the CV2 then they're in trouble.
- 8y ago

ryanlol 8y ago

How is that the "Oh dear."? Do you work for a bank? That seems like the least interesting bit of information here for individuals. It's really bizarre to me that people here seem to consider their credit card numbers more sensitive than their travel history or even contact information.

raesene9 8y ago
well possibly not. If the attackers got the keys to decrypt payment details that means that victims, in addition to the identity theft risks, may also face fraudulent transactions on those cards as a risk.
- ryanlol 8y ago
  Even if the payment information is in plaintext it'll primarily be the banks who are affected, not the customers. I'd be far more concerned about my privacy than my banks money.
  - raesene9 8y ago
    Anyone hit with fraudulent charges has to a) notice them, b) dispute them and c) go through the annoying process of having your card re-issued. As to privacy, after the number of breaches of personal info. there have been, I'd be inclined to let the idea that this level of personal data is private :)
    - ryanlol 8y ago
      >a) notice them Don't you review your charges regularly? Even without fraud you're bound to be losing money to erroneous charges if you don't. >b) dispute them I've usually just had to submit a quick online form consisting almost entirely of checkboxes, while yeah that's some work it's still not going to take more than a minute of my time. >c) go through the annoying process of having your card re-issued. Seems like this is vastly more annoying with some card issuers than others.

Oras 8y ago

and according to the article: "It said an internal investigation found an attacker had been able to access the Starwood network since 2014." 4 years of access, surely the attacker didn't manage to get hold of these keys

codedokode 8y ago

Card information has no value because it is very easy to reissue a card. Things like name or phone number, or address, cannot be changed so easily and have much higher value.

closeparen 8y ago
Things like name, phone number, and address are not secret. They are published in the phone book.
jstarfish 8y ago
Card information is literally cash money. It's volatile and subject to being rendered defunct, but it still has a lot of value if you can buy a bunch of prepaid gift cards with them before it's deactivated.