OVH Security Incident

123 points by bjonathan 12 years ago | 54 comments

jacquesm 12 years ago |

OVH has come a long way. They used to be cheap and bad at service and totally incommunicado about any issues. Then a few years back something changed and they started to work on their image. Their still cheap, but their service is good and getting better and they seem to have nailed the communications angle. Good for them. Between OVH, Hetzner and Leaseweb the EU hosting space is doing fine.

adamseabrook 12 years ago | |

We tried a number of hosting companies before settling on OVH including the premium dedicated companies. They do have the occasional hiccup but overall we have been very impressed with the pricing and the support both reactive and proactive. The day we signed up for our 50th server we received a nice personal email from the head of their support in Montreal.

cmer 12 years ago | | |

We have over 25 machines with them. How do you cope with having to pay individually for every single machine, every single month? Their billing system is non-sense, unless I'm missing something?

Karunamon 12 years ago | |

I might add that OVH has a US arm as well - prices are competitive with Hetzner at least.

gtaylor 12 years ago | | |

I've been wanting to try them. Does this security breach have any implications for the US data center, or was this pretty localized to the European arm?

seivan 12 years ago | |

Wasn't there a recent thing with their CEO hating Github because of "Githubs agenda of poaching developers" or some shit like that?

johnchristopher 12 years ago | | |

Oh yeah: http://www.ovh.com/fr/a1136.interview-github-octave-klaba-ov...

Google translate: http://translate.google.com/translate?hl=fr&sl=fr&tl=en&u=ht...

temac 12 years ago | | |

Their CEO is not the brightest guy in the universe. This security notice is well written and signed by him... but obviously not written by him.

computer 12 years ago |

The level of transparency in this report is great. Especially compared to things like the Linode incidents.

p4bl0 12 years ago | |

OVH is always very good with transparency with its client. That's part of why I use them for my server, and my ADSL2+ (soon to be VDSL2) at home: when there is a problem, I know what it is and they report their progress solving it in live. Also their customer support is great and doesn't take you for a foul, if they feel you can take technical details, they will gave them to you and really discuss with you about the solution.

aroch 12 years ago | | |

Your interactions are pretty much opposite of mine. OVH is constantly doing stupid things to their network (like updating all their BGP reflectors at the same time last week and then falling out of BGP because of it). What they have in transparency and they lose in being a bunch of asshats to deal with. They've taken a week to replace a blown PSU (caused by their own inability to wire a rack); they've dumped my servers because their own internal billing checks weren't aligned with my actual billing details; ffs they essentially root all their servers with their default install image.

I won't even go into their blatant breaches of contract...They toss a ToS at you, but you can only read it when signed into your manager and you can only sign into your manager if you accept the ToS. They won't email you the new ToS either, you have to accept it without being able to read it.

Nikkau 12 years ago | |

Yeah, as great as Github... Oh wait!

peterkelly 12 years ago |

This is how you do a security incident disclosure.

I hope Apple is taking notes.

at-fates-hands 12 years ago | |

Are you referring to the recent disclosure, or just in general how they do it?

peterkelly 12 years ago | | |

I'm just referring to this specific post from OVH (who I hadn't heard of until today). In reading it, I get the impression that they've handled the situation extremely professionally, and are setting a great example.

mrb 12 years ago |

"The encryption password is "Salted" and based on SHA-512, to avoid brute-force attacks. It takes a lot of technical means to find the word password clearly"

"clearly?" OVH is wrong. Based on this information alone, it is not sufficient to say how costly it is to recover the password. SHA-512 needs to be iterated to make it costly to brute force.

For example, a raw SHA-512 hash, even salted, is not iterated and is easy to brute force. But multiple passes, as in crypt-SHA-512, are iterated and very costly to brute force.

huhtenberg 12 years ago | |

It's an ESL issue. He meant to say "in clear" as in "plaintext" rather than "clearly", clearly.

deweerdt 12 years ago | | |

Definitely: the french for plaintext would be "en clair"

lmkg 12 years ago | |

I think you may be reacting to a mis-parse. The sentence is awkwardly phrased either way, but "clearly" could mean "it is clear that it takes a lot of technical means," or it could mean "to find a clear version (i.e. plaintext) of the password."

jlgaddis 12 years ago | |

If one's password is "password", the choice of hash algorithms and salts is irrelevant anyway.

yeukhon 12 years ago | | |

Yes and no. If you salted a plaintext using any hash algorithm, the biggest advantage is on the population, not an individual password; so yes, it is irrelevant for any single password. If you have comprised a database, and you are interested in a single user, then you can easily recompute months. But if you are interested in compromising a large user population, because you want to find the weakest (like find all the users using 'password' or '123456'), then you have a hard time because with salt you cannot find occurrence. People think salt saves everything, that is not true. It only adds hardness to secure a population, not an individual password (because the salt is appended and stored!). Now when it comes to iteration, sure, adaptive hashes like bcrypt or scrypt can make computation longer. That's all. Using sha512 is still wrong: it's a hash designed for fast hashing, not for securing password. bcrypt is slowly broken. Slowly because workfactor is exponential.

ihsw 12 years ago |

Hacked again?

https://bitcointalk.org/index.php?topic=186902.msg1936161#ms...

tallanvor 12 years ago | |

Quite a different incident, I think.

Robin_Message 12 years ago |

If I was a customers, I'd be asking if "based on SHA-512" means some kind of iterated algorithm, or if have they lost my password?

eli 12 years ago | |

It doesn't matter; you should assume your password is lost.

Follow their advice: "we advise you to change the password for your user name."

Robin_Message 12 years ago | | |

It matters a great deal (well, not to me, I don't use the service). Password reuse is common, and the way to fix that is good quality password hashing. If I used OVH, I'd need to change my password everywhere now.

If I used someone competent (i.e. they still have bugs but they use bcrypt), they'd have lost: $2a$10$NkYCXBjWeVP0rJUlfl0VL.d66EvJjbVUA/YEsmBSyTZOnbY0/anxa which is a bcrypt hash of my most secure password.

I'm happy to publish that. The salted SHA-512? Not so much!

w0rd-driven 12 years ago | |

"based on" could literally mean "some shit our lead developer cooked up that's like SHA but not really."

I would hope "based on" doesn't mean that but why use the phrasing at all? Either it's SHA-512 or it isn't and if it isn't, confidence is definitely not instilled.

tommis 12 years ago | |

Not everyone is native english speaker. He means the password is salted and SHA-512 hashed...

mikeash 12 years ago | |

That jumped out at me as well. People need to understand that even cryptographic hashes cannot be considered irreversible for short inputs, and that you need to use something specifically designed as a password hash to do it properly.

thirsteh 12 years ago | | |

http://throwingfire.com/storing-passwords-securely/#notpassw...

http://codahale.com/how-to-safely-store-a-password/

hbbio 12 years ago | |

Maybe SHA-512, salted?

nnwa 12 years ago |

"After internal investigations, it appeared that a hacker was able to obtain access to an email account of one of our system administrators."

That translates to password reuse, or an insecure password.

jessaustin 12 years ago | |

...or a client attack, or XSS, or poorly secured tokens, or whatever. If we always blame the user first, we're bound to miss something. Even if the fault were an insecure password, the admin site would still be to blame for not throttling and locking down the account in response to repeated attack.

nnwa 12 years ago | | |

Fair point Jess.

donohoe 12 years ago |

  An email will be sent today with the new password

Password in plain-text? I understand the convenience factor but doesn't sound very secure...

mike-cardwell 12 years ago | |

If someone can read your email, they don't need your password. They can just initiate a password reset.

  https://www.ovh.co.uk/cgi-bin/nic/nicPassword.cgi

But yes, in general, email isn't a very secure method of sending passwords.