5 ms·

And DO consistently ignores requests to add this. It prevents me from seriously using Spaces and I think many others, too.

sneak 3y ago
DO has had a terrible attitude to security for as long as they've been around. I reported a major data leak vulnerability to them and they told me it was operating as intended, so I published it, and then they accused me of irresponsible disclosure, while simultaneously claiming that there was no security issue. This was a dozen years ago and the founders were involved in the response. They are at the top of the list of companies with which I will never do business.
- mdekkers 3y ago
  Could you provide more details?
  - sneak 3y ago
    On delete of VMs, the next user to be allocated disk would be able to read your data. There was a "scrub" feature that would bill you longer/extra to zeroize your data and not give it to the next customer. Apparently they hadn't heard of TRIM or thin provisioning. https://github.com/fog/fog/issues/2525 https://github.com/fog/fog/issues/2525 https://news.ycombinator.com/item?id=6983097 https://news.ycombinator.com/item?id=6983097 https://news.ycombinator.com/item?id=6983520 https://news.ycombinator.com/item?id=6983520
    - belter 3y ago
      Some of the comments by DO on that GitHub thread, are really surprising, and disappointing to say the least...
      - neom 3y ago
        I wrote those comments, fog wasn't using the API as he would have liked, and then this guy starts a bunch of trouble on HN stating that there was a vun on DigitalOcean, and conflated someone using the API incorrectly with us having a security vun. Two things I was trying to (admittedly not very well) say was: if DO did have a security issue, posting it on HN ("DigitalOcean leaks customer data between VMs" huh?) instead of emailing us about it isn't a very responsible way to disclose it and, there isn't actually a security issue, the fog app wasn't passing the scrub flag. In retrospect, I should have been less of a jerk, but I still think sneak was acting in bad faith in how he went about the whole thing. 10 years later and I still remember how pissed off I was that day, hah.
        richbell 3y ago
        I do find the claim that "there's nothing irresponsible about full immediate disclosure" to be interesting. https://github.com/fog/fog/issues/2525#issuecomment-31336855 https://github.com/fog/fog/issues/2525#issuecomment-31336855
        deleted 3y ago
        [deleted]
        ratg13 3y ago
        The fact that you think it should be the customers’ responsibility to make sure that DO doesn’t accidentally give your private data away to unknown third parties is an absolutely minblowing take on this matter. I’ve been a DO customer for the better part of a decade, but there is no way that I can continue to be a customer with a company that has such a blasé stance toward security and protecting customer data. If anyone can suggest any alternatives that are not Hetzner, I would be interested.
        neom 3y ago
        Well first, I've not worked for DigitalOcean in a long time, I left in 2015. I don't really wanna re-hash something from 2013, but again: when you deleted a VM you could click the scrub button or pass the scrub flag in the API when you issued a delete call. It was very well documented and the scrub button wasn't hidden anywhere in the interface. The fog platform wasn't using the scrub flag in their app for whatever reason. As I recall, we did change it to scrub by default shortly after. From what I remember, the reason it wasn't originally default was the zero'ing process tried up a lot of resource on the box and it was hard on the drives and we were very much in startup mode at that time with limited capacity, so it was better to only zero if the customer requests it.
    - 15155 3y ago
      I actually came here to add this very issue and then noticed this comment. This issue is the reason why I will never use DO or recommend it to a customer.
    - fullspectrumdev 3y ago
      Holy shit that’s bad. I wonder how one could test for that “automatically” on other providers.
- k8sToGo 3y ago
  Reminds me of a hosting company in my country. When you use their spaces thing, they generate a password for you (not being able to set your own is already a red flag for me, but ok). It was "hidden" in the UI to look secure. However, the password itself was passed as an argument that was part of the URL. So everyone who logs access urls could see the password. I reported it, they fixed it quickly, but never acknowledged that it was a "security" issue.
- Operyl 3y ago
  Don’t forget the time they issued the same sshd keys to every instance because they didn’t scrub them from the images.
- scrumlord 3y ago
  [dead]
giancarlostoro 3y ago
Yeah I was unaware of this, and will no longer consider DO for anything beyond basic VPS hosting, if even that.
MaxBarraclough 3y ago
See also this old comment on security issues with their managed Kubernetes offering. https://news.ycombinator.com/item?id=22490390 https://news.ycombinator.com/item?id=22490390

sneak 3y ago

DO has had a terrible attitude to security for as long as they've been around. I reported a major data leak vulnerability to them and they told me it was operating as intended, so I published it, and then they accused me of irresponsible disclosure, while simultaneously claiming that there was no security issue. This was a dozen years ago and the founders were involved in the response. They are at the top of the list of companies with which I will never do business.

mdekkers 3y ago
Could you provide more details?
- sneak 3y ago
  On delete of VMs, the next user to be allocated disk would be able to read your data. There was a "scrub" feature that would bill you longer/extra to zeroize your data and not give it to the next customer. Apparently they hadn't heard of TRIM or thin provisioning. https://github.com/fog/fog/issues/2525 https://github.com/fog/fog/issues/2525 https://news.ycombinator.com/item?id=6983097 https://news.ycombinator.com/item?id=6983097 https://news.ycombinator.com/item?id=6983520 https://news.ycombinator.com/item?id=6983520
  - belter 3y ago
    Some of the comments by DO on that GitHub thread, are really surprising, and disappointing to say the least...
    - neom 3y ago
      I wrote those comments, fog wasn't using the API as he would have liked, and then this guy starts a bunch of trouble on HN stating that there was a vun on DigitalOcean, and conflated someone using the API incorrectly with us having a security vun. Two things I was trying to (admittedly not very well) say was: if DO did have a security issue, posting it on HN ("DigitalOcean leaks customer data between VMs" huh?) instead of emailing us about it isn't a very responsible way to disclose it and, there isn't actually a security issue, the fog app wasn't passing the scrub flag. In retrospect, I should have been less of a jerk, but I still think sneak was acting in bad faith in how he went about the whole thing. 10 years later and I still remember how pissed off I was that day, hah.
      - richbell 3y ago
        I do find the claim that "there's nothing irresponsible about full immediate disclosure" to be interesting. https://github.com/fog/fog/issues/2525#issuecomment-31336855 https://github.com/fog/fog/issues/2525#issuecomment-31336855
        deleted 3y ago
        [deleted]
      - ratg13 3y ago
        The fact that you think it should be the customers’ responsibility to make sure that DO doesn’t accidentally give your private data away to unknown third parties is an absolutely minblowing take on this matter. I’ve been a DO customer for the better part of a decade, but there is no way that I can continue to be a customer with a company that has such a blasé stance toward security and protecting customer data. If anyone can suggest any alternatives that are not Hetzner, I would be interested.
        neom 3y ago
        Well first, I've not worked for DigitalOcean in a long time, I left in 2015. I don't really wanna re-hash something from 2013, but again: when you deleted a VM you could click the scrub button or pass the scrub flag in the API when you issued a delete call. It was very well documented and the scrub button wasn't hidden anywhere in the interface. The fog platform wasn't using the scrub flag in their app for whatever reason. As I recall, we did change it to scrub by default shortly after. From what I remember, the reason it wasn't originally default was the zero'ing process tried up a lot of resource on the box and it was hard on the drives and we were very much in startup mode at that time with limited capacity, so it was better to only zero if the customer requests it.
  - 15155 3y ago
    I actually came here to add this very issue and then noticed this comment. This issue is the reason why I will never use DO or recommend it to a customer.
  - fullspectrumdev 3y ago
    Holy shit that’s bad. I wonder how one could test for that “automatically” on other providers.
k8sToGo 3y ago
Reminds me of a hosting company in my country. When you use their spaces thing, they generate a password for you (not being able to set your own is already a red flag for me, but ok). It was "hidden" in the UI to look secure. However, the password itself was passed as an argument that was part of the URL. So everyone who logs access urls could see the password. I reported it, they fixed it quickly, but never acknowledged that it was a "security" issue.
Operyl 3y ago
Don’t forget the time they issued the same sshd keys to every instance because they didn’t scrub them from the images.
scrumlord 3y ago
[dead]

giancarlostoro 3y ago

Yeah I was unaware of this, and will no longer consider DO for anything beyond basic VPS hosting, if even that.

MaxBarraclough 3y ago

See also this old comment on security issues with their managed Kubernetes offering. https://news.ycombinator.com/item?id=22490390 https://news.ycombinator.com/item?id=22490390