OVH Security Incident (opens in new tab)

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?

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?

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

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.

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.

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.

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

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.

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!

Salted SHAx passwords are basically the entire reason GPU John The Ripper and oclHashcat exist, although SHA2-512 is significantly slower than SHA2-256, so if you're going to use a terrible SHA-based password hash, SHA2-512 is your best bet.

Yep, in the french version of the message they specify that it's salted.

http://travaux.ovh.net/?do=details&id=8998

Fair point Jess.