Security Notice: Linode Manager Password Reset
blog.linode.com
blog.linode.com
At the time they did not give much information. They did not do a follow up. They did not discuss plans to prevent the same type of breach. I am not surprised that today, they got breached again! sigh
And again, they are making the same mistakes. They are not giving much information. They are not going to do a follow up. Etc.
That is, you use the expression 'they {linode} got breached', versus the more correct 'they {the customers} got breached'. How do you know that in both cases this was the case?
One could argue Linode was overzealous in resetting all passwords. Reasonable minds can differ.
If the compromise was due to a weak password that was brute forced, or obtained from the end user in some other way, then there is absolutely no need to reset every user's password.
The only time a 'reasonable mind' would think to reset everyone's password is if the attacker exploited some flaw in the underlying system, which could have given them access to arbitrary passwords.
Assuming the virtualization system is trustworthy (which it is), that's not a problem. Assuming it's not trustworthy, they shouldn't be running a virtual hosting company and letting random strangers sign up in the first place!
The xen security issue is another example of this kind of opaqueness.
Today, they are reseting the password of all customers, making it pretty certain this is another breach at the Linode level, not at the customer's level.
> "A server that I use for mail etc., deals with protecting its users from themselves by regularly attempting dictionary and bruteforce attacks upon its own password file. Any passwords that get broken get expired (forcing a change next login) and the user gets a (mostly polite) email explaining why their password was expired and how to avoid it happening again."
Thoughts?
[1] http://www.schneier.com/blog/archives/2012/04/password_secur...
You could check a lot (depending on language speed) of common passwords whenever a password is chosen, or during login, when you still have the password in cleartext. When it passes the checks, set a flag for that user so that the check doesn't have to be repeated.
If it takes to long to do during login, have a counter that keeps track of where in a list of passwords the checker is at, and do N more each login.
I don't think there's much need to check for common passwords at each login, provided that none of your users are allowed to use such passwords in the first place. You might get more security by banning IPs that try more than a few of those common passwords in a short time (it's a useful way to detect brute-force attempts), but in fact you should be banning any IP that generates more than a few failed logins in a short time.
[1] http://xato.net/passwords/more-top-worst-passwords/
Another measure I use on my webapps is calculating how many bits of entropy a password contains, and ban anything less than ~40 bits (the threshold depends on the target demographic). An 8-digit number has 10^8 = 26.5 bits of entropy. An 8-char lowercase string has 26^8 = 37.6 bits of entropy (unless it's a common word). A mixed-case 8-char string that also contains numbers has (26+26+10)^8 = 47.6 bits of entropy. This method has the advantage that I don't need to specify annoying rules like "one lowercase, one uppercase, one symbol, etc." Simpler passwords can be allowed if they are long enough, and complex passwords can be banned if they are too short.
"password1" is too easy to brute-force. "pAssword072" is not even in the top 10000, and therefore it is already stronger than at least 98.8% of passwords that are out there.
The idea is to allow weaker passwords for the sake of convenience, but compensate for their weakness by adding protections in other areas. For example, you might require users with weaker passwords to change their passwords more often, disable their accounts more aggressively when a brute-force attack is suspected, or use more rounds of bcrypt to encrypt their passwords. Some of these measures will be helpful even in the case of a database breach.
- 2-factor auth [1]
- X-Frame-Options [2]
- HSTS [2]
- Redirect from http to https prior to login. (if someone bookmarks the http url, for example, they can be mitm'd anytime they use that bookmark) [2]
These have been pointed out on the forums long ago (see cites) but have not been implemented.
If you visit http://manager.linode.com/session/index it'll happily let you log in via HTTP.
In the end they offered Bitcoinica one-year worth of services, which are basically nothing compared to the huge losses. I can expect 7 other customers to be treated similarly.
There were no details available at all. Not only they didn't follow up to the public, there's a shockingly lack of transparency to their affected customers as well.
I feel like this is probably more than just some dude's account.
I suspect that they aren't 100% sure, and that this is a precaution. I can live with it, but I hope that they keep their customers in the loop on things, where possible.
On the other hand, this type of action would give it away either way, so maybe even that excuse doesnt smell right.
EDIT: All is good with my account.
I wish my CC provider supported 'single use' or 'limit based' generated numbers. I think discover card does?
edit: something like this https://www.discover.com/credit-cards/member-benefits/securi... but for my card would be neat
On the other hand, I have a hard time using it for anything sensitive. Quotes like "We have implemented all appropriate measures to provide the maximum amount of protection to our customers." somehow don't reassure me.
Last I knew, they were running a seriously deprecated OS version for their hosts, and their configuration management systems left a lot to be desired in terms of security.
Perhaps more worrying is how opaque they are about everything. Nevermind the security issues, they won't even provide explanations for 'normal' service outages.
From what it seems, the only thing they take seriously is responding to incidents like these and letting customers know. If they were actually serious about security, these things wouldn't be happening. It was almost over a year ago since the last event.
http://status.linode.com/2012/03/manager-security-incident.h...
In other words, better safe than sorry.
If the compromise was due to a flaw in Linode's system (potentially exposing other accounts) then a global password reset makes sense.
Can you imagine if every service you used reset everyones passwords every time one of their users got brute forced? You'd do nothing but reset your passwords all day...