4 ms·

That doesn't make any sense. It's exactly like saying: "Oh sure, the credit card numbers were encrypted but if the encryption key is brute-forced then it's game

That doesn't make any sense. It's exactly like saying: "Oh sure, the credit card numbers were encrypted but if the encryption key is brute-forced then it's game over". The CC numbers were encrypted using a public key. The corresponding private key was itself encrypted using "[a] complex passphrase [that] is not stored electronically". They could be lying, but if they are not then this is perfectly valid security. Using this scheme, you can store new CC numbers any time you want using the public key. You'd have a regular billing cycle(say a month) with billings happening in a short time window(All my linode accounts get billed within minutes of each other so I think this is the case for linode). When you want to bill your customers you'd input the passphrase which wouldn't be stored anywhere, would be used to temporarily decrypt the CC numbers and bill everyone. Unless you are attacked in that window(or an attacker gains access before that window and can remain unnoticed until it happens, and even then they'd need root access to read the memory and not just access to the filesystem) then the CC numbers are pretty safe against any attack that leaks files/databases/etc...

thaumaturgy 13y ago
> When you want to bill your customers you'd input the passphrase which wouldn't be stored anywhere, would be used to temporarily decrypt the CC numbers and bill everyone. I've had account changes billed to my card within minutes, even (and especially) in the middle of the night (when I do most of that stuff). I'm having a little bit of trouble imagining that someone's sitting in front of a terminal and typing a passphrase into a prompt every three to five minutes, all day long.
- entropy_ 13y ago
  You make a good point
- corford 13y ago
  Interesting. Whenever I make changes that affect how much I'll be billed, the amounts get added or removed and take effect when the card next gets charged (which happens once a month). At least that's how I remember it... going to dig through some old statements now to verify this as its been a while since I last changed anything that would alter what they charge me.
  - thaumaturgy 13y ago
    I had to go back further than I thought to find an off-cycle charge, but I did find one from January 2012, for a plan upgrade, 10 minutes before midnight, for $6.77. It looks like that was the last plan modification I made. They may've changed their billing system in the last 12+ months.
    - corford 13y ago
      I haven't got online statements going back far enough to check right now (will have to do it with paper copies when I get home if I can be bothered). You're probably right though :) I guess they either keep the passphrase in memory (someone enters it once on boot) or another possibility is they have a couple of billing windows each day where they batch through whatever charges/refunds have accumulated since the last run. Feasible I guess with 2 or 3 specially cleared staff members on rotation.
- VLM 13y ago
  If I were designing the system given the constraints specified, it would look a lot more like sudo's timeout implementation, or one of the uncounted zillions of encrypted filesystem implementations over the years. An encoded filesystem doesn't mean the sysadmin types in the passphrase every time something hits an "open()" call, its (usually) just once at boot time. Or sudo can be configured so you get to authenticate every hour not every time you run a command. Also to be honest I've never had a problem with linode, combined with I've heard they've got pretty good support, so if there is a dude on duty at 3am he probably has nothing to do other than type in a password. So that would be an alternative, simple architecture. Now where it gets hard to justify is when there's enough traffic to pay a dude to sit there typing in the password all day, but they're apparently not that big. (edited to add I hope they didn't actually use encfs and/or sudo, I was using them as an example of a user interface not as the final answer for how it would be implemented.)
cheald 13y ago
My concern is that if the password was poorly chosen, the private key won't be very safe if they got the private keyfiles. That many credit card numbers is a huge target so it'd be worth an attacker expending some money on. If it's a strong, long non-dictionary passphrase, then I'm not nervous. But, we don't really have any idea if it is or not. The fact that their web interface boxes had the private key on them is a huge concern - you'd ideally run all billing stuff on a machine that is highly locked down, perhaps not even accessible outside of a very strict range of IP addresses. The practice of leaving the private keys hanging around on the same boxes that ran the website makes me awfully nervous about the other links in the chain.

thaumaturgy 13y ago

> When you want to bill your customers you'd input the passphrase which wouldn't be stored anywhere, would be used to temporarily decrypt the CC numbers and bill everyone. I've had account changes billed to my card within minutes, even (and especially) in the middle of the night (when I do most of that stuff). I'm having a little bit of trouble imagining that someone's sitting in front of a terminal and typing a passphrase into a prompt every three to five minutes, all day long.

entropy_ 13y ago
You make a good point
corford 13y ago
Interesting. Whenever I make changes that affect how much I'll be billed, the amounts get added or removed and take effect when the card next gets charged (which happens once a month). At least that's how I remember it... going to dig through some old statements now to verify this as its been a while since I last changed anything that would alter what they charge me.
- thaumaturgy 13y ago
  I had to go back further than I thought to find an off-cycle charge, but I did find one from January 2012, for a plan upgrade, 10 minutes before midnight, for $6.77. It looks like that was the last plan modification I made. They may've changed their billing system in the last 12+ months.
  - corford 13y ago
    I haven't got online statements going back far enough to check right now (will have to do it with paper copies when I get home if I can be bothered). You're probably right though :) I guess they either keep the passphrase in memory (someone enters it once on boot) or another possibility is they have a couple of billing windows each day where they batch through whatever charges/refunds have accumulated since the last run. Feasible I guess with 2 or 3 specially cleared staff members on rotation.
VLM 13y ago
If I were designing the system given the constraints specified, it would look a lot more like sudo's timeout implementation, or one of the uncounted zillions of encrypted filesystem implementations over the years. An encoded filesystem doesn't mean the sysadmin types in the passphrase every time something hits an "open()" call, its (usually) just once at boot time. Or sudo can be configured so you get to authenticate every hour not every time you run a command. Also to be honest I've never had a problem with linode, combined with I've heard they've got pretty good support, so if there is a dude on duty at 3am he probably has nothing to do other than type in a password. So that would be an alternative, simple architecture. Now where it gets hard to justify is when there's enough traffic to pay a dude to sit there typing in the password all day, but they're apparently not that big. (edited to add I hope they didn't actually use encfs and/or sudo, I was using them as an example of a user interface not as the final answer for how it would be implemented.)

cheald 13y ago

My concern is that if the password was poorly chosen, the private key won't be very safe if they got the private keyfiles. That many credit card numbers is a huge target so it'd be worth an attacker expending some money on. If it's a strong, long non-dictionary passphrase, then I'm not nervous. But, we don't really have any idea if it is or not. The fact that their web interface boxes had the private key on them is a huge concern - you'd ideally run all billing stuff on a machine that is highly locked down, perhaps not even accessible outside of a very strict range of IP addresses. The practice of leaving the private keys hanging around on the same boxes that ran the website makes me awfully nervous about the other links in the chain.