Security

Make login by passkeys possible for project dashboards. Current two-step authentication by SMS is not safe.

Hey guys. I am Yuriy. An engineer from FIDO Alliance. You probably heard about us. We are the organisation behind U2F protocol that Google reported killed employee phishing: https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing . Our organisation have developed secure, seamless, phishing proof, passwordless authentication standard called FIDO2. Or some people may call it WebAuthn. WebAuthn is the JS API part in the browsers of the FIDO2, and it is supported by Chrome, Edge and Firefox. I was happy customer of yours for many years and I felt like you guys so great and innovative, that adding FIDO2 support to your multifactor authentication instead of TOTP would be a great idea, since TOTP is succeptable to phishing. We have a tutorial https://slides.com/fidoalliance/jan-2018-fido-seminar-webauthn-tutorial I wrote blog posts on attestation and assertion verification: https://medium.com/@herrjemand/verifying-fido2-responses-4691288c8770 We have a stories a good deployment stories: https://engineering.linecorp.com/en/blog/fido-at-line/ And we have a helpful and friendly community that will be able to help you if you stuck *) Regards. Yuriy

Hello Support Team, I am writing to report a copyright infringement taking place on your network. An unauthorized private server is currently operating on IP address 165.232.122.114 for the game "Little Empire" (developed by Camel Games). This server interacts with modified/cracked APK clients to bypass official game authorization. Details of the Report: Game Title: Little Empire Rights Holder: Camel Games ( https://www.camelgames.com/game/LITTLEEMPIRE ) Target IP: 165.232.122.114 Infringing APK Link: https://www.mediafire.com/file/nvr2lxktsf2flmy/littleEmpire_1.27.8.apk/file I request that you review this server's activity and take the necessary action to address this violation of intellectual property rights. Thank you for your time and assistance.

I would like to be able to setup OIDC with Google. This enables us to enforce logging in with an Google account. It would also be very convenient if we have the option to choose between the functionality to automatically create accounts if they don't exist or to not create them. Currently Digital Ocean accounts are being created if they don't exist, whereafter these will be added to the team. This is not always convenient.

Currently, you can pull actions for a single individual via the API - but for folks that are using this in a team capacity that have multiple team members - this is not useful for monitoring. Any organization (not individual) using DO will have a need to monitor access/actions taken within the team. Under the team security history - there is a GraphQL area that has these logs (albeit - VERY space on the details) - but Support suggests these are not accessible via the API (which would be needed to send logs to a SIEM for monitoring). There needs to be an API that covers all audit events for the team instance, all actions, all products, and includes details on access (username, IP, user agent, action taken, date, product affected, time, etc.) at the very least - and this needs to be accessible via an API that can be queried by a Collector OR these events should be able to be sent outbound via webhook to a SIEM solution.

There are companies that outsource their development work and would like to give ACCESS TO SPECIFIC PROJECTS AND DROPLETS ONLY instead of all the projects and droplets. The custom roles allow you to restrict a reole but does not allow you to select the projects or resources so you cannot limit anyone's access to specific resources. It would be a great idea to be able to select specific projects and resources only

Any plans to offer a SecretsManager as a service?

I'd like to use GitHub Actions to deploy to my DO droplets without messing with SSH keys: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect Apparently AWS and GCP already support OIDC.

I think it is great that Digital Ocean rolled out it's beta testing to provide custom scopes for personal access tokens shown here: https://docs.digitalocean.com/reference/api/create-personal-access-token-with-custom-scopes/ However, I think it is missing one hugely beneficial feature that could dramatically increase security in the event of a compromised token. There should also be an option to allow tokens to only be used by authorized IP addresses and/or IP ranges. This way, attackers cannot use a compromised token to destroy resources regardless of customized granularity. It's a secondary protection layer to provide much stronger security. Default setting should of course be to allow all IP ranges, but if a token grantor wishes to have greater security, allow them the option to limit it only to authorized IP addresses (ie. the IPs of their droplets or other resources from where they anticipate making the API calls). The token-creator should be able to customize that IP list and/or IP range(s) accordingly.

Teams should be able to enable and disable per-user access for individual projects. This would be in line with best practices, following the principle of least privilege and maintaining a consistent level of separation between project staff.