This is the official update from ovh: http://forum.ovh.co.uk/showthread.php?t=6592
If you still have 7 characters of entropy, that's 60^7 combinations. If the attacker hacked the account in one hour (as they claim), how did the attacker sent 777600000 requests per second for one hour without them noticing? One billion requests per second, that's not something you usually handle. Nor your servers, you would crash anytime.
Something is missing from this story, or i'm blinded and i'm missing something myself.
Quote
On April 26th, we detected an internal problem with the generation of the 21 characters. 2 out of the 3 random functions that we use in the code were not generating an authentic random sequence. It was possible to request a password change for a customer ID,
and then find the "unique" URL emailed to the customer by brute force. The problem was found by an internal developer on April 26th at 11:03:14 and it was fixed at 12:54:13. The cause of the problem was linked to the rand function used in this part of the code. It was not patched to the same extent as the rest of the code at the time of activating the script execution cache. We have replaced the old function of 3 sequences to generate 21 characters with 2 authentic random functions to generate 64 characters.
We then ran searches on our databases to verify whether the loophole had been exploited and if so, when. We tracked the log of password changes for your IDs for the last 3 years. We actually have authorisation from the CNIL (the French data protection authority) to archive and exploit all our back office logs for the last 10 years, precisely for this type of situation.
We detected three password changes carried out by brute force on 3 customers IDs with active services. These 3 cases involved an attack aimed at the "bitcoin" community that uses OVH services. The hacker seems to have found the loophole on April 23rd at
22:00 and ran a significant number of tests to develop their tactics over a period of 1 hour. At 23:00 it had been perfected and the 1st ID was hacked, followed by the other 2 the next day (all from the "bitcoin community"). We have been in contact with these customers but the quality of the exchanges prevented us from obtaining sufficient information to identify this loophole. Thanks to our internal developers, we have fixed the problem in a totally independent manner. Only then did we begin to make the connection between the loophole that we had just fixed annd these 3 customers. We have certainly learnt a lesson on how to communicate with clients in this type of situation.
and then find the "unique" URL emailed to the customer by brute force. The problem was found by an internal developer on April 26th at 11:03:14 and it was fixed at 12:54:13. The cause of the problem was linked to the rand function used in this part of the code. It was not patched to the same extent as the rest of the code at the time of activating the script execution cache. We have replaced the old function of 3 sequences to generate 21 characters with 2 authentic random functions to generate 64 characters.
We then ran searches on our databases to verify whether the loophole had been exploited and if so, when. We tracked the log of password changes for your IDs for the last 3 years. We actually have authorisation from the CNIL (the French data protection authority) to archive and exploit all our back office logs for the last 10 years, precisely for this type of situation.
We detected three password changes carried out by brute force on 3 customers IDs with active services. These 3 cases involved an attack aimed at the "bitcoin" community that uses OVH services. The hacker seems to have found the loophole on April 23rd at
22:00 and ran a significant number of tests to develop their tactics over a period of 1 hour. At 23:00 it had been perfected and the 1st ID was hacked, followed by the other 2 the next day (all from the "bitcoin community"). We have been in contact with these customers but the quality of the exchanges prevented us from obtaining sufficient information to identify this loophole. Thanks to our internal developers, we have fixed the problem in a totally independent manner. Only then did we begin to make the connection between the loophole that we had just fixed annd these 3 customers. We have certainly learnt a lesson on how to communicate with clients in this type of situation.
If you still have 7 characters of entropy, that's 60^7 combinations. If the attacker hacked the account in one hour (as they claim), how did the attacker sent 777600000 requests per second for one hour without them noticing? One billion requests per second, that's not something you usually handle. Nor your servers, you would crash anytime.
Something is missing from this story, or i'm blinded and i'm missing something myself.
Nobody from OVH contacted me with any official statement, they even cannot blame for "not giving them enough information". Actually I called them many times and provided them many useful information for "debugging" the issue. So far the official statement from OVH is "not our problems, secure your email better". However, I'll call them tomorrow (again).
More discussion:
https://news.ycombinator.com/item?id=5624728
https://news.ycombinator.com/item?id=5632479