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

201–210 of 282 posts

Re: Security incident update

#201

Post by sparkinson »

singlow wrote: post #177
sparkinson wrote: post #99

Earlier quoted context omitted.

> in our heads So it's short enough to remember and likely has some sort of pattern. There's a limit to what a person can remember, lower if there are several people that have to remember it.

It is not very difficult to memorize random strings of arbitrary characters. I use a password manager to manage most of my accounts, but the important ones, like banks and email, I keep in my head. I use my password manager to generate a 15 character string of alpha+numeric+symbols. The symbols would kind of make it hard, except that in my head they are just upper-case numbers, mostly (shift-7, not ampersand). And in…

The thing is for your personal bank account a 15 character password is acceptable.

But for x many customer credit card details you're really looking for a much longer password that that. I'm talking 64 characters or more of pure random data.

You shouldn't be compromising for the convenience of being able to remember a password when it secures such critical data in my opinion.

Edit: I do agree though that your method is a very good way of remembering password.

Re: Security incident update

#202

Post by kaiserama »

ig1 wrote: post #93

I've canceled the card I used with Linode, the hacker may or may not have got access to the card number, but given the level of uncertainty I'd just rather cancel my card and get a new one reissued. I imagine my bank feels the same way. Remember that depending on where you're based / your agreement with your bank that you might lose any standard "protection" for any fraudulent transactions that occur after you learn…

I did the same thing. I had to read HN to even have a clue about this as their email correspondence/site gave no indication that this was even a possibility.

I would assume a large majority of their clients don't read HN and would have no line of sight to do the same.

It's unfortunate that this happened, but I'll be looking for another host in the near future.

Re: Security incident update

#203

Post by ig1 »

ryan-c wrote: post #197
corford wrote: post #183

Earlier quoted context omitted.

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 b…

Cracking even a 1024 bit RSA key would cost at least millions of dollars. Credit card numbers are not worth that much.

Tens of thousands of credit and debit cards, many of which are likely to be corporate cards with extremely high spending limits ?

Re: Security incident update

#204

Post by lawnchair_larry »

corford wrote: post #89
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…

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

Doesn't make sense. Who here thinks they typed that in manually for every single CC they got? They didn't, encryption/decryption was automated, meaning anyone could have done it if they had access to the process that normally does.

Also, the post says salted sha256 passwords are useless. Evidently, they do not have a clue how to safely store passwords, because that is not useless at all.

Finally, it's an outright lie that systems were not accessible, because we already know that they hacked seclists.org/nmap. Even their previous post acknowledged this.

Re: Security incident update

#205

Post by seany »

jpallen wrote: post #5

I know Linode has been getting hammered for not being trustable or that they don't respond well when contacted, but in my experience they have been extremely responsive to any issues I have raised. I don't just mean technical issues either, we had what looked like a security breach on our account and it kicked of a small frenzy in their support staff and supervisory team to track down the problem. They figured out wh…

This seems to happen when they think it isn't their fault. As soon as it's something that could reflect negatively on them they put out the smallest most vague amounts of information possible. That happened with the xen security issue, and with the previous hack.

Re: Security incident update

#206

Post by zimpenfish »

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.

An option much like washing your feet in boiling sulphuric acid is a way of getting sand out from between your toes.

When something makes PHP look like a bastion of sanity and competence, you really should run a million miles in the other direction.

Re: Security incident update

#207

Post by sparkinson »

bjterry wrote: post #161
sparkinson wrote: post #99

Earlier quoted context omitted.

> in our heads So it's short enough to remember and likely has some sort of pattern. There's a limit to what a person can remember, lower if there are several people that have to remember it.

It's trivial to memorize an entire sonnet. Actors and actresses memorize many times that amount. It's also trivial to write a sonnet. How many bits of entropy do you think a sonnet has?

Are you saying that you are happy to type in an entire sonnet when prompted for a password?

Being realistic, to expect someone to type in such a long password regardless of if they can remember it or not is clearly unreasonable.

Re: Security incident update

#208

Post by plusbryan »

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…

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

Re: Security incident update

#209

Post by gburt »

lawnchair_larry wrote: post #204
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...

Doesn't make sense. Who here thinks they typed that in manually for every single CC they got? They didn't, encryption/decryption was automated, meaning anyone could have done it if they had access to the process that normally does. Also, the post says salted sha256 passwords are useless. Evidently, they do not have a clue how to safely store passwords, because that is not useless at all. Finally, it's an outright lie…

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.

Re: Security incident update

#210

Post by teach »

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…

> "It's probably safe to assume that 'there were occurrances of Lish passwords in clear text...' is a euphemism for "we stored all Lish passwords in cleartext."

This borders on libelous, in my opinion. If all Lish passwords had been stored in the clear, I think they would have said that. They've been pretty specific in the rest of the update.

They say they have "invalidated all affected Lish passwords effective immediately". I just logged in to Lish via SSH using the new password I had set on Friday, so I guess mine at least wasn't one of the "occurrences"....

Lish passwords in the clear might have been in support tickets stored in the same database, or chat logs.

Also: "It's very likely that people reused their root login passwords as their Lish passwords..."

Really? I guess it's never a good idea to doubt people's capacity for stupidity, but this seems very obviously a bad idea. Hopefully this isn't so common as to be "very likely".

Post reply on HN