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

141–150 of 282 posts

Re: Security incident update

#141

Post by dchest »

Confusion wrote: post #87
dchest wrote: post #47

Earlier quoted context omitted.

Right, we don't know because they failed to disclose this.

Wouldn't you rather have them working on assessing, containing and repairing the damage rather than catering to the impatient internet crowd that is so used to immediate updates on everything that they can't fathom putting together a responsible, useful, correct response might actually take a while? Honestly, these people don't understand what it takes to run a company and handle such an incident. As far as i'm conce…

Quoting Linode:

"There were occurrences of Lish passwords in clear text in our database. We have corrected this issue and have invalidated all affected Lish passwords effective immediately."

Presumably, they know how many customers are affected, because they invalidated their passwords. They didn't tell us.

Re: Security incident update

#142

Post by mekoka »

JshWright wrote: post #139
mekoka wrote: post #85

The one thing that puzzles me above anything else about this whole thing is: "Linode uses ColdFusion". I mean, you have this Linux company that's pretty much an open source champion to us Linux guys and then... Adobe ColdFusion. Really? I know nothing about ColdFusion, don't get me wrong, I just find it an incredibly odd choice for a Linux company. That having been said, I think Linode just learnt a really unpleasant…

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

Don't assume that the most transparent company out there isn't choosy about what it's being transparent about. There are plenty of things we never know that don't hurt us. I choose not to concern myself with such things.

Re: Security incident update

#143

Post by pizzeys »

VLM wrote: post #128
threeseed wrote: post #116

Earlier quoted context omitted.

I am a former customer who was burned the last time they were hacked and were less than truthful. Now it has happened again and nothing has changed. Clearly non existent security audits (cleartext passwords ?) and still lots of unanswered questions. It should be crystal clear by now that Linode is fundamentally untrustworthy.

Typical hackernews binary thinking. Trust is a spectrum not a binary. I'd trust them more than the 16 yr old waitress at the local restaurant who is legally judgment proof and as a juvenile frankly has no punishment related reason not to rip me off. Every time I pay with a CC at a restaurant and don't get my number stolen it pretty much restores my faith in humanity. Or I'd trust them more than the seedy psuedo-organ…

> I'd trust them more than the 16 yr old waitress at the local restaurant who is legally judgment proof and as a juvenile frankly has no punishment related reason not to rip me off. Every time I pay with a CC at a restaurant and don't get my number stolen it pretty much restores my faith in humanity.

Know what we did in the UK to solve this problem? Identified it as a weakness and switched to a system that removes this weakness. Linode aren't too good at that bit.

Re: Security incident update

#144

Post by wuest »

arc_of_descent wrote: post #100
hellweaver666 wrote: post #98

Earlier quoted context omitted.

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…

> In the meantime, Perl works for us. It's not cool or sexy > but it gets the job done. What is not cool about Perl? You don't need to transition to a new framework outside of Perl. You can upgrade your backend by investing your time in rewriting the Perl code to newer standards.

> What is not cool about Perl?

Perl is my first interpreted language. It has a very special place in my heart, even if it was awkward at first to get used to it coming from a C background. Perl will always be a cool kid.

Re: Security incident update

#146

Post by rjbond3rd »

laumars wrote: post #119
arc_of_descent wrote: post #100

Earlier quoted context omitted.

> In the meantime, Perl works for us. It's not cool or sexy > but it gets the job done. What is not cool about Perl? You don't need to transition to a new framework outside of Perl. You can upgrade your backend by investing your time in rewriting the Perl code to newer standards.

It's hard to find good Perl developers and even harder to run multi-language libraries for the same online portal (ie same site, domain, database, hosting environment: hardware, OSs....and so on).

I disagree. First, it's hard to find good developers, period. S

econd, in general, good developers are hard to find by design (e.g., to avoid recruiters, but also because they are most tof the time already doing interesting work).

Lastly, yes, it's hard to find good Perl programmers to do boring work, under boring conditions, at a boring wage. But then that's true of all good developers. Try to find a Rails programmer to remediate crappy code (I've tried).

Re: Security incident update

#147

Post by laumars »

rjbond3rd wrote: post #146
laumars wrote: post #119

Earlier quoted context omitted.

It's hard to find good Perl developers and even harder to run multi-language libraries for the same online portal (ie same site, domain, database, hosting environment: hardware, OSs....and so on).

I disagree. First, it's hard to find good developers, period. S econd, in general, good developers are hard to find by design (e.g., to avoid recruiters, but also because they are most tof the time already doing interesting work). Lastly, yes, it's hard to find good Perl programmers to do boring work, under boring conditions, at a boring wage. But then that's true of all good developers. Try to find a Rails programme…

You're missing my point, PHP developers that know how to build websites are available ten to the dozen. But Perl most of the Perl developers we've tried to recruit over the last 18 months are either completely clueless at writing RESTful APIs or just terrible developers (sometimes even both).

We've had far more success at hiring good PHP developers and teaching them Perl then we have had at finding the Perl developers that can write web technologies.

But this might just be a facet of our location (a suburb that's more than an hour away from any city), so all the developers of "niche" languages (such as Perl has sadly become) tend to get drawn to the city and higher wages. Where as those who are still good developers but not as money driven tend to pick the more popular languages because they'll pick the work in the area they want to work. (that's probably an unfair generalization statement, but it's true for the local area where I live).

Re: Security incident update

#148

Post by purephase »

facorreia wrote: post #120
kijin wrote: post #114

Earlier quoted context omitted.

> why should a static document reader be able to run arbitrary code Because PDF was never meant to be a static format, and Adobe Reader was never meant to be a static document reader. However, since most PDFs are static anyway, I think it would be a very good idea for PDF reader softwares to treat every PDF as a static document by default, and only allow scripting after the user clicks Yes on a scary-looking warning.

Correct. I wasn't clear, so let me clarify: I regard every PDF I read as a static document. That's how I see them and that's how I read them, with readers that treat them as static. I have no use for a PDF document that wants to acts as software and I wouldn't use a bug-nest of a piece of software to run it.

You're not the target market for those types of PDF's then. In large corporate environments, PDF's are roughly the equivalent of small web-apps that handle a lot of the data entry and sharing across the organization.

I'm not a proponent of this approach, but it is what it is and it is the reason that Reader is such a bloated security-ridden nightmare.

Re: Security incident update

#149

Post by windexh8er »

wuest wrote: post #144
arc_of_descent wrote: post #100

Earlier quoted context omitted.

> In the meantime, Perl works for us. It's not cool or sexy > but it gets the job done. What is not cool about Perl? You don't need to transition to a new framework outside of Perl. You can upgrade your backend by investing your time in rewriting the Perl code to newer standards.

> What is not cool about Perl? Perl is my first interpreted language. It has a very special place in my heart, even if it was awkward at first to get used to it coming from a C background. Perl will always be a cool kid.

I think it's interesting when people tie sentiment to coding choices. As previously stated, I could never wrap my head around the horrid syntax and the feeling that if you didn't know it from the beginning it was going to be a long, hard trek in doing so.

As for 'cool' I'm not so sure. Perl will be a niche sandbox for quite a while, but most run-ins with Perl (as of late) have been trying to remove it for something else. I think choosing a more accepted language has legs for a variety of reasons including code portability and long-term maintainability, both stemming from the fact that if there's only one guy maintaining all of the Perl code then that's a very-bad-thing.

But, that's just me. To wax nostalgic on Perl and use that as a basis for use-case seems, at least somewhat, reckless.

Re: Security incident update

#150

Post by tlrobinson »

"Despite the uselessness of these hashes, as you know we expired Linode Manager passwords on Friday."

The uselessness of hashed passwords depends entirely on the hashing algorithm and the strength of the password.

Post reply on HN