Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security incident update

blog.linode.com

Post reply on HN
Print view View original

261–270 of 282 posts

Re: Security incident update

#261

Post by JshWright »

eridius wrote: post #254
JshWright wrote: post #139

Earlier quoted context omitted.

>That having been said, I think Linode just learnt a really unpleasant lesson and will become an even more secure provider for it. I believe that moving my sites away from them at this moment would be like selling stocks when they're about to go up. What concerns me is that the would have been perfectly happy to sweep most of this under the rug if Ryan hadn't forced their hand. The security lesson is one thing (hacks…

> What concerns me is that the would have been perfectly happy to sweep most of this under the rug if Ryan hadn't forced their hand. That's a rather cynical thing to say. There's no proof that without Ryan's chat log, Linode wouldn't have told us anything.

I'm a long time Linode customer. I love the service they provide. I hate their lack of transparency.

The 'proof' is that the announcement came in very short order after Ryan's comments, and in the past, Linode has _never_ made such announcements (despite serious security breaches)

Re: Security incident update

#262

Post by JshWright »

brandon272 wrote: post #211

Linode exceeds technically in providing reliable VPS instances. Unfortunately, that's overshadowed by their lax approach toward security and their inability to be transparent when problems come up. This is not the first incidence where their lack of transparency has come under fire. This latest update dances around the issue and doesn't go far enough to explain what happened, whether or not your data is at risk, and…

> Is "the private key was also compromised but we don't think they can guess it, so let's just move on" good enough?

You have to take that a step futher... "we don't _thing_ they can guess is, and we don't _think_ they were able to recover it from RAM"

Re: Security incident update

#263

Post by eridius »

thaumaturgy wrote: post #260
eridius wrote: post #255

Earlier quoted context omitted.

This seems likely. Once a month, run a script, type in the complex passphrase, and all the billing gets done at once.

I mentioned this elsethread, but I've had changes to my account get charged to my card immediately (within minutes), even in the middle of the night. Last example of this was January 2012, so they may've changed their billing practices since then.

I suppose they could also keep the decrypted key in memory using something like gpg-agent.

Re: Security incident update

#264

Post by justin66 »

bradleyland wrote: post #230
plusbryan wrote: post #208

Earlier quoted context omitted.

I'd recommend reporting your card likely stolen and getting a new number. The slight inconvenience is worth the peace of mind.

I recommend not bothering. Liability for fraudulent CC activity (in the US) is very low (max $500), and banks never enforce the liability for two reasons: 1) it's easier for them to chargeback the transaction to the vendor, thus they're not out of pocket, and 2) it causes customers to leave for a provider that doesn't hold them liable. How much of your time spent chasing down and changing a CC number is worth a maxim…

> maximal risk of $500

I'm pretty sure you're off by a factor of ten. If someone makes fraudulent charges with your credit card, your maximum liability is $50, and you'll only have to pay that if the charges occur after you've reported the card stolen. (There are different rules for debit cards, that doesn't apply here.)

Re: Security incident update

#265

Post by shadowmatter »

bvdbijl wrote: post #189
tbatterii wrote: post #132

Earlier quoted context omitted.

>Facebook and YouTube were both created later, and in PHP youtube was always done in python as far as I understand. http://www.youtube.com/watch?v=G-lGCC4KKok But yeah, back in 2002-3 coldfusion was an option.

Youtube pre-Google was PHP

Youtube pre-Google was still Python, from the way several Youtubers have told it to be. Maybe an initial prototype was PHP, but not what was running when it was purchased.

And trust me, there is no way Google ever would have said "rewrite it in Python." They would have said "rewrite it in Java," like every other frontend they run (Gmail, Calendar, Docs, etc).

Re: Security incident update

#266

Post by steveklabnik »

jmillikin wrote: post #251
steveklabnik wrote: post #246

Earlier quoted context omitted.

> communicating via a small and easily-auditable interface ... isn't that called 'a network'? This seems to contradict your earlier statement about 'machine B should be considered internet-facing.'

It's not a contradiction, because 1) the webserver would not have login credentials to the hardened machine and 2) the interface would be much smaller than "everything in SQL". A typical example of such an interface would expose about four operations: // Return true if the given user/password pair is valid. bool PasswordValid(string user, string password) // Return true if the password was changed successfully. bool…

That'd still be 'internet-facing' though, by your definition. Yes, it might require one more round of cracking (the simple interface), but the machines are still connected.

Re: Security incident update

#267

Post by corford »

lawnchair_larry wrote: post #213
gburt wrote: post #209

Earlier quoted context omitted.

It's a private key. You need the public key to encrypt, which is not password-encrypted. Although I still wonder about how they run recurring charges.

I understand this, and any system that needed this information would not work if it relied on a human to decrypt.

I think the most likely answer is pretty simple and non shocking: the key is loaded via an agent on boot (subject to the correct passphrase being entered) and stays resident in memory (either permanently or for x minutes/hours). Where's the problem?

Re: Security incident update

#268

Post by corford »

nenolod wrote: post #233
corford wrote: post #89

Earlier quoted context omitted.

This is what Caker (founder of Linode IIRC?) has to say about the strength of the passphrase: "our private key is stored only in encrypted format. The passphrase is not guessable, sufficiently long and complex, not based on dictionary words, and not stored anywhere but in our heads." [1] [1] http://blog.linode.com/2013/04/16/security-incident-update/c...

Except you know, system memory when the key material is unlocked... unless you really believe someone is sitting there typing in the passphrase for each non-batch CC transaction, because I do not.

What exactly do you propose as an alternative? At some point the card details need to be decrypted. Security always boils down to somewhere between total lock down and being able to actually get things done. The only semi reasonable alternative would be not to store any CC details and outsource that task to a payment processing company. It's not a great alternative though as you'd effectively be giving up the ability to swap payment processors (since they, not you, now have all your customers card details) for a potentially small and unproven bit of extra security.

Re: Security incident update

#269

Post by corford »

mike-cardwell wrote: post #187
darkarmani wrote: post #166

Earlier quoted context omitted.

> A single private key passphrase is all that stands between a bad guy and everyone's credit card information... Well I know I feel better... Where do you get that from? They encrypt all of the CC info using the public key. You need the private key AND the private key passphrase -- and one of them isn't stored on a computer.

The private key shouldn't be on any machine that it isn't used on. If we assume that the key is used on that machine, and is password protected, and is used automatically, then the unencrypted key, or its password, must exist in memory, if not on disk. Perhaps they log in when the machine boots and manually enter the password once, so it is cached and can be used for repeat decryption processes. If the key is in memo…

This isn't a problem unique to Linode though. The same risk is present for every system that needs a password/passphrase to decrypt. This is why effective security (not absolute - which is impossible for any system that has to connect with other systems) can only be achieved through a layered approach.

Linode layered pretty well: Hashed and salted passwords, isolated systems, encrypted CC database and passphrase protected decryption key with no written record of what that passphrase is. They didn't do a perfect job but then who does (or even can)?

Re: Security incident update

#270

Post by nenolod »

corford wrote: post #268
nenolod wrote: post #233

Earlier quoted context omitted.

Except you know, system memory when the key material is unlocked... unless you really believe someone is sitting there typing in the passphrase for each non-batch CC transaction, because I do not.

What exactly do you propose as an alternative? At some point the card details need to be decrypted. Security always boils down to somewhere between total lock down and being able to actually get things done. The only semi reasonable alternative would be not to store any CC details and outsource that task to a payment processing company. It's not a great alternative though as you'd effectively be giving up the ability…

Lets be honest here. How frequently do you think a company changes processors?
Post reply on HN