
Rackspace: concerns from a former Slicehost customer - keenerd
http://kmkeen.com/rackspace/
======
jyap
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.

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

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

------
nodata
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?

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

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

------
geuis
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?

~~~
vegardx
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>

~~~
geuis
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?

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

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

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

