Security incident update • Hacker News Board

Re: Security incident update

#181

Post by hemancuso » Tue, Apr 16, 2013, 2:50 PM UTC

I wish PCI compliance required companies that take credit card info for any sort of recurring billing declare if they store your credit card information or if it is stored for them by their gateway/merchant account provider.

There are a thousands of very small SAAS services out there that bill monthly which I assume would take advantage of gateway stored credit card info, then you find out that a comparatively larger more trustworthy player like Linode doesn't.

Similarly it would be nice to also have them declare if they use something like Braintree's transparent redirect such that they never even see the card numbers.

Re: Security incident update

#182

Post by singlow » Tue, Apr 16, 2013, 2:50 PM UTC

gr3yh47 wrote: post #129

How can it be a 0-day vulnerability if it was addressed in a patch that came out more than a day ago? I understand patch cycles and I'm not hating on them for not having the latest update when it's been less than a week but still...

It is a 0-day because the vulnerability was disclosed publicly before the patch was made available.

Re: Security incident update

#183

Post by corford » Tue, Apr 16, 2013, 2:51 PM UTC

darkarmani wrote: post #166

UnoriginalGuy wrote: post #118

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... But jokes aside, there is a huge gap between the strongest and weakest algorithms used to passphrase protect a private key. I wish they gave us more information about the certificates. Including: is it ONE private certificate for everyone? Or one per client/customer? How was the…

> 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.

I'm pretty sure UnoriginalGuy understands that. What he says is correct, the attackers now have the private key file so all that prevents them from decrypting the CC data is the passphrase. They don't know what this is but they can try and brute force it which is why it's relevant to wonder what cipher the key uses, how many bits and how long, random and complicated the passphrase text is.

Hopefully, they used 4096 bits and a random >20 char string as the passphrase. That combined with a standard cipher algorithm (DSA, RSA) should be enough to keep us safe.

Re: Security incident update

#184

Post by darkarmani » Tue, Apr 16, 2013, 2:52 PM UTC

I'm assuming they mean these hashes are useless for the attacker, not for Linode users?

"Linode Manager user passwords are not stored in our database, but their salted and cryptographically hashed representations are. Despite the uselessness of these hashes, as you know we expired Linode Manager passwords on Friday."

Re: Security incident update

#185

Post by heyitsnick » Tue, Apr 16, 2013, 2:59 PM UTC

merlincorey wrote: post #111

webmonkeyuk wrote: post #97

Earlier quoted context omitted.

At least if someone tries cracking the passwords they won't have to bother with a dictionary based attack or short strings ;)

Unless of course it's a double-bluff.

Digression: That would be a single bluff.

Bluff: Saying one thing, doing the opposite ("our passwords are really long" (actually, they are short).

Double bluff: Saying one thing, and actually doing it, as everyone will assume we are bluffing. "Our passwords are really long, honestlyl! (and they actually are, but bad guys will assume we are bluffing and using a short password).

Re: Security incident update

#186

Post by threeseed » Tue, Apr 16, 2013, 3:01 PM UTC

andyhmltn wrote: post #158

ciaron wrote: post #60

Earlier quoted context omitted.

I can second this - Linode has always responded quickly and effectively in my experience.

I third this. I've never had a problem. Most of my tickets have a response within 10 minutes and they always seem to have been open when anything has gone wrong on their end. Is anyone not thinking that the reason they didn't come out in public talking about this until now is because law enforcement was involved? Notifying the public could ruin the investigation.

No. Because Linode has been hacked before and exactly the same situation is playing out. Major compromise and selective release of information.

I really do wonder at what point people are going to realise that they aren't dealing with a company who cares about their interests.

Re: Security incident update

#187

Post by mike-cardwell » Tue, Apr 16, 2013, 3:02 PM UTC

darkarmani wrote: post #166

UnoriginalGuy wrote: post #118

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... But jokes aside, there is a huge gap between the strongest and weakest algorithms used to passphrase protect a private key. I wish they gave us more information about the certificates. Including: is it ONE private certificate for everyone? Or one per client/customer? How was the…

> 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 memory, then a blackhat who knows what he's doing can get access to it.

Re: Security incident update

#188

Post by blantonl » Tue, Apr 16, 2013, 3:04 PM UTC

thaumaturgy wrote: post #77

They reset the passwords on Friday. Even assuming that they've been working for the last four days on discovering the extent of the intrusion, there's a pretty big gap between Friday's announcement: "This activity appears to have been a coordinated attempt to access the account of one of our customers. This customer is aware of this activity and we have determined its extent and impact. We have found no evidence that…

Honestly, the gap can probably be attributed to them not knowing what exactly happened. Figuring out that you were compromised by a zero day vulnerability isn't an easy process to work through.

Re: Security incident update

#189

Post by bvdbijl » Tue, Apr 16, 2013, 3:09 PM UTC

tbatterii wrote: post #132

rjknight wrote: post #90

Earlier quoted context omitted.

Linode is a Linux company, but it's also a company founded in 2002-3. Back then, there weren't many great options for web programming and ColdFusion would have made a degree of sense (PHP 4.0 was released in 2000, and Ruby on Rails 1.0 didn't appear until 2004; Django was released in 2005). A modern, reasonably-secure web stack in those days really did mean "PHP with register_globals=Off". (Facebook and YouTube were…

>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

Re: Security incident update

#190

Post by rellik » Tue, Apr 16, 2013, 3:09 PM UTC

powertower wrote: post #178

moxie wrote: post #162

"There were occurrences of Lish passwords in clear text in our database." I think that this is what's most criminal about the whole event. It's probably safe to assume that "there were occurances of Lish passwords in clear text..." is a euphemism for "we stored all Lish passwords in cleartext." Simply invalidating these is probably not enough. It's very likely that people reused their root login passwords as their Li…

I've been a Linode customer since the start of 2007 and my biggest worry right now is this... > Credit card numbers in our database are stored in encrypted format, using public and private key encryption. The private key is itself encrypted with passphrase encryption and the complex passphrase is not stored electronically. By not providing further clarification that the private key was stored outside that compromised…

Why won't they just tell us the private key's passphrase, so we can judge for ourselves how secure it is?