Live data from Hacker News

Security incident update

blog.linode.com

101–110 of 282 posts

Re: Security incident update

#101
post #59
post #35

Earlier quoted context omitted.

"There were occurrences of Lish passwords in clear text in our database."

I believe the correct approach for us is to assume all Lish password where in clear text until a good explanation is given. It's not usual to store some password in clear text and encrypt the others, right?

Could be that the passwords were hashed, but something logged a password, or there was leakage somewhere during the login process.

All it takes is one debug log statement to leak through from development and you can be logging plain-text passwords on every login.

Re: Security incident update

#102
post #76

Earlier quoted context omitted.

Well, the official statement re: the passphrase is: > @Eivind – 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.

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

You can't assume this. It could be ridiculously strong, and, with a lot of use, has become remembered.

Re: Security incident update

#103
post #95

Earlier quoted context omitted.

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

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.

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.

Re: Security incident update

#104
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…

This should be the top comment and the reason why companies should disclose this information on time and more often. Just like you would block your card if you get robbed, you should block your card if someone steals your cc data.

Re: Security incident update

#105
I don't know why so many guys here who obviously are not customers of linode care about this case so much, I've been a user of linode for 5 years, it's a company that you know you can trust, that's simply what I can tell from my experience.

Re: Security incident update

#106
As a computer user, I'm thoroughly tired of Adobe's products constant stream of security vulnerabilities. Flash, Adobe Reader, ColdFusion. I avoid their products mostly for this reason. Flash, which I can't avoid completely, I have set up to only run when I say so, which I only do for a couple websites I trust. And why should a static document reader be able to run arbitrary code completely eludes me.

Many companies should learn the lesson from Microsoft's huge shift years ago when they implemented the Trustworthy Computing Initiative. They have much larger targets (an operating system, a hypervisor, a database server, a full office suite, etc.) compared to a browser plugin or a document reader, and in my experience they're doing a far better job at keeping security at an acceptable level.

Comparing IIS+ASP.NET security versus some frameworks such as Rails (another huge source of vulnerable web applications) is also enlightening.

Re: Security incident update

#107
post #95

Earlier quoted context omitted.

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.

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.

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.

Re: Security incident update

#108

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…

Also, if it works for them, it may not be financially viable to rewrite all of their code. For example, I work for a large company that uses Perl for all the backend stuff on our website. If we were to change to a more "modern" stack, we would have to stop and focus on that for a period of time instead of pushing the company forward and improving the customer experience etc. In the meantime, Perl works for us. It's n…

I think most of the time it's never got anything to do with financial considerations, it's more just does anyone feel strongly enough about it to rewrite it in a fit of pique/on the sly/in a slow month and then on top of that have the power/influence/charm to push it through. No manager will ever say 'this non-essential system needs re-writing in a modern way'.

Rewrites where you're already intimate with the code base don't take that long for non-core stuff. I assume it's the web interface that's written in CF (which you can see from viewing the source in their signup and login pages). I guess you could argue it's core to their conversion process, but I mean their core skills are servers and their maintenance rather than web development so they probably actually haven't spent that many man hours on it.

Re: Security incident update

#109

Earlier quoted context omitted.

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

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

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

Post reply on HN