Rackspace: concerns from a former Slicehost customer | Hacker News Reader

Rackspace: concerns from a former Slicehost customer

kmkeen.com

22 pointskeenerd16 comments

A lot of places just have legacy code and policies. You have no evidence of your claim that they store passwords in clear text.

Their restrictions may in fact have cut down on widespread security outbreaks from users who use the same password across multiple web sites. This means that Rackspace has also enforced a unique password from their other passwords via their enforced scheme.

That's not quite the claim he made though. His claim is that the only reason to have those policies is to mitigate SQL injection and because you're storing cleartext passwords.

If you're storing password hashes, you don't care about the charset used for the password, and the only limitation on password length would be sane bandwidth concerns - who really cares if I send you 2 or 3Kb of password if your hash algorthm is going to store that in the same sized database column as "password123"?

Either they have those policies for a reason - they've got bad password storage practices, or they have them for no good reason - which is a very good excuse to ask "WTF?"

And do you _really_ think this might have "cut down on widespread security outbreaks"? That's a pretty lame justification in my opinion - it's like claiming I'd be "improving my users security" by disallowing vowels in passwords, to minimise the risk that they re-use existing passwords. There is no way to "enforce a unique password" without keeping too much knowledge of users passwords.

I think the OP's stated "concerns" are very valid, and I agree with him that Rackspace's policies and answers fall a long way short of providing the reassurance that they're storing critical security credentials in a safe fashion.

Be careful with that. BCrypt for example silently truncates long passwords (>72 chars).

Wow a whole blog post on the presumption that not allowing some special characters means they are vulnerable to an sql injection attack.

How about.. testing that theory?

Who cares if they're not actually vulnerable? It's 2012. These password restrictions are arbitrary and anachronistic.

They are also the kind of policies that will make enterprisey minds feel safe and secure. Not worth reading too much into them.

I've been a loyal Slicehost customer since 2009. I was previously a Rackspace customer too. There were a lot of reasons I jumped to SH when I had a chance. I'm seriously considering moving over to Linode soon. I desire the most control over my servers, and the combination of that and the low cost of SH is hard to find elsewhere. I think Linode will be a good alternate. Do any others have experience with Linode that can comment?

I've been running a few Linodes for the past year with absolutely no complaints. A year isn't a huge sample period, but I am very happy with my experience so far. I can't compare to Slicehost or Rackspace, but compared to my previous VPS at Media Temple (grrr...) Linode is paradise.

I had 8 instances with Linode and quickly moved after their disgraceful behaviour during their Bitcoin security incident. In which customers were only told days after it was reported across the internet and to this day nobody knows exactly what happened, what was done to fix it or whether it will happen again.

As a PaaS/IaaS provide you NEVER, EVER hide things from your customers. Especially with security. And you combine this with their very average uptime and I would never recommend Linode to anybody.

You are much better off having a look around:

http://webhostingtalk.com

I've had my Linode account for 3 years this month, with server instances from all of their U.S. datacenters. Before I sing their praises, I have to describe how hard it is for me to be a fan of just about anything. I'm a pretty grumpy dude and I think everything's crap.

But not Linode. They are really, really great.

1. Great support. I'm an experienced sysadmin but I still occasionally run in to things that make me scratch my head. When I do, Linode support is the last place I turn to, but when I do turn to them, they respond within a few minutes and almost always with the right answer. They should be held up as a model of perfect customer service right alongside Zappos and Amazon and Nordstrom.

2. No I/O issues so far, for me. One of the concerns of a VPS is that you can get strange issues caused by other VPS instances running on the same hardware where everything will be sluggish but iostat and its brethren will you tell you everything's fine. I haven't seen this on any of my Linodes so far.

3. No other performance issues so far. Similar to above; the only time my instance feels icky is when I've crapped on it somehow. Near as I can tell, nobody else is using the same hardware I am.

4. Pretty good uptime. Unfortunately, not perfect -- if you insist on 100% uptime, you'll have to get clever with redundancies between datacenters -- but it's been pretty good overall. They're pretty open about problems as they happen, check http://status.linode.com. There were repeat problems with their Fremont datacenter about a year ago, so I moved everything out of it, but it's probably OK now.

5. A pretty nice management interface. I did like their previous version a little better, but the current one is OK. You can still do pretty much anything you need to do from it.

6. No stupid password requirements. My main Linode password is a string of line noise. It works. 'Nuff said. (Also: you can make their interface block logins from IPs you haven't logged in from before; attempted login attempts from unknown IPs will result in an email to you with a link to allow that IP.)

7. They like to give their customers gifts. Really, about twice a year they'll say, "thanks for being our customer!" by handing out free memory upgrades or other awesomeness. How cool is that?

Some criticisms:

1. Disk space seems pretty expensive right now. That might be a lingering side-effect of the mass destruction of HD manufacturers early this year. I'm not yet feeling like the disk space is completely inadequate, but it is more of a problem than RAM (for me).

2. Security. They had two incidents in the last year, IIRC; one caused by an ex-employee who compromised a bunch of Linodes running Bitcoin-related stuff, and one caused by a Xen vulnerability. Linode was pretty tight-lipped about both of those, and I don't like that.

Hope this helps.

We host a couple of external DNS-servers on Linode for redundancy, and I just looked at our smokeping reports, and everything looks pretty nice. We wouldn't notice downtime on a single machine other than some noise in nagios, but as far as I can remember, they have been stable all year.

I've added some reports from smokeping and munin. Please note that these are DNS-servers, so basically the only thing that generates IO is logging and updates. Your milage may vary.

Linode London DC: https://dl.dropbox.com/u/24775/linode_london_v4.png https://dl.dropbox.com/u/24775/linode_london_v6.png https://dl.dropbox.com/u/24775/linode_london_io.png

Linode Newark DC: https://dl.dropbox.com/u/24775/linode_newark_v4.png https://dl.dropbox.com/u/24775/linode_newark_v6.png https://dl.dropbox.com/u/24775/linode_newark_io.png

Thanks alot for the graphs. That's awesome data to have on hand. Very reassuring. Could you say roughly how many servers you guys run?

No problemo! Roughly around 30 servers, give or take.

Thanks for all the comments. I definitely think I'll be going with Linode, but remain aware of security issues. One thing I'm really looking forward to is the IPV6 support, which Slicehost hasn't ever quite worked out to my satisfaction. It'll mean IPV6 support for jsonip.com relatively soon, I hope.

I call Hanlon's Razor (on part of this anyway). I suspect it's far more likely that it was a (stupid) business decisions on the password length/characters to reduce the number of times people would forget their paswords and initiate a password reset. I have tragically come across this many times (and more than once in the UK retail banking sector)

I'm less inclined to give them the benefit of the doubt.

Limited password lengths (shorter than possible DOS attacks attempting to upload megabytes into the password field) mean that either a) you're storing cleartext passwords, or b) your tech people are storing hashed passwords and somebody who doesn't understand web security is in a position of enough control to subvert the decisions of the tech people who _do_ understand how to do things.

Either their password storage is insecure, or their marketing/support/management is reducing security by imposing arbitrarily policies on passwords - arbitrarily policies which just happen to look exactly like they're mitigating SQLi and storing passwords as cleartext.

Reply on news.ycombinator.com