4 ms·

Doesn't seem too awful to store obfuscated credit card details in a short-lived cookie with httponly and secure set. (Say, in a checkout flow where you have to

Doesn't seem too awful to store obfuscated credit card details in a short-lived cookie with httponly and secure set. (Say, in a checkout flow where you have to hold the credit card details somewhere for a couple minutes).

krapp 14y ago
Maybe a naive question/response on my part but why not rather encrypt it and hold it in a session? Or if you have to put something in a cookie, just a reference that points to some data on the server like an id, which has no real meaning to the end user?
- joevandyk 14y ago
  That means holding the credit card information on the server. Seems safer to hold it temporarily on the client.
- sopooneo 14y ago
  I may be missing something, but what does it mean to "hold something in a session" if not to either (1) store it in a cookie (encrypted or not) or (2) store it server-side with a token stored in a cookie pointing to it?
  - krapp 14y ago
    I meant storing it on the server - just preferring not to have any actual cc data on the cookie, even obfuscated or encrypted. It may be a distinction without a difference, though, I honestly have never dealt with anything more complex than your basic 'hash username and password and check the hash when they login' scheme.
TomGullen 14y ago
It's terrible - I have no idea if it's PCI compliant (I would hazzard a no here) - Obfuscation is such weak security it should be considered as pretty much worthless - It's vulnerable to cookie jacking over non HTTPS - It's vulnerable to theft if you have access to a computer where someone has logged on There are other ways of doing it, putting it in a short live cookie is one of the worst ways
- joevandyk 14y ago
  > Obfuscation is such weak security it should be considered as pretty much worthless Say obfuscation = encrypted. > It's vulnerable to cookie jacking over non HTTPS That's why you use the secure and httponly flag for the cookie. > It's vulnerable to theft if you have access to a computer where someone has logged on Pretty much everything is vulnerable to theft if you have access to a computer where someone else has logged on.
  - krapp 14y ago
    At the very least, the data (encrypted or no, but it should probably be encrypted) on the server related to a session lives outside the webroot, whereas in a cookie, even if it is encrypted, it's still essentially public. If there's no reason to have that data, explicitly, exposed in the client then why put it there?
  - chris_wot 14y ago
    Obfuscation is not the same as encryption. Do not make that mistake!
    - garethadams 14y ago
      True, but encryption is merely a computationally unfeasible form of obfuscation
  - TomGullen 14y ago
    I don't trust a site that stores my CC information in a cookie to always serve HTTPS pages. Also you didn't address the most important point, PCI compliance. The method Santander employs is unquestionably a bad way to do things.
    - snikch 14y ago
      If the cooke is set to secure it won't be sent in a non https request.
  - 14y ago

krapp 14y ago

Maybe a naive question/response on my part but why not rather encrypt it and hold it in a session? Or if you have to put something in a cookie, just a reference that points to some data on the server like an id, which has no real meaning to the end user?

joevandyk 14y ago
That means holding the credit card information on the server. Seems safer to hold it temporarily on the client.
sopooneo 14y ago
I may be missing something, but what does it mean to "hold something in a session" if not to either (1) store it in a cookie (encrypted or not) or (2) store it server-side with a token stored in a cookie pointing to it?
- krapp 14y ago
  I meant storing it on the server - just preferring not to have any actual cc data on the cookie, even obfuscated or encrypted. It may be a distinction without a difference, though, I honestly have never dealt with anything more complex than your basic 'hash username and password and check the hash when they login' scheme.

TomGullen 14y ago

It's terrible - I have no idea if it's PCI compliant (I would hazzard a no here) - Obfuscation is such weak security it should be considered as pretty much worthless - It's vulnerable to cookie jacking over non HTTPS - It's vulnerable to theft if you have access to a computer where someone has logged on There are other ways of doing it, putting it in a short live cookie is one of the worst ways

joevandyk 14y ago
> Obfuscation is such weak security it should be considered as pretty much worthless Say obfuscation = encrypted. > It's vulnerable to cookie jacking over non HTTPS That's why you use the secure and httponly flag for the cookie. > It's vulnerable to theft if you have access to a computer where someone has logged on Pretty much everything is vulnerable to theft if you have access to a computer where someone else has logged on.
- krapp 14y ago
  At the very least, the data (encrypted or no, but it should probably be encrypted) on the server related to a session lives outside the webroot, whereas in a cookie, even if it is encrypted, it's still essentially public. If there's no reason to have that data, explicitly, exposed in the client then why put it there?
- chris_wot 14y ago
  Obfuscation is not the same as encryption. Do not make that mistake!
  - garethadams 14y ago
    True, but encryption is merely a computationally unfeasible form of obfuscation
- TomGullen 14y ago
  I don't trust a site that stores my CC information in a cookie to always serve HTTPS pages. Also you didn't address the most important point, PCI compliance. The method Santander employs is unquestionably a bad way to do things.
  - snikch 14y ago
    If the cooke is set to secure it won't be sent in a non https request.
- 14y ago