Below is the PGP public key to contact firstname.lastname@example.org. You can use this key to encrypt and secure our messages. To start using it, you'll need to install an OpenPGP software on your computer. Below you'll find a list of possible solutions for your operating system:
macOS | Linux | Windows | iOS | Android
Please import the public key into your local OpenPGP Key-Manager. Updated on 10/3/22.
Click here to download PGP Public Key Block
Web Application Firewall
All Cobalt site traffic is proxied through CloudFlare. We leverage CloudFlare’s Web Application Firewall (WAF) to protect the site from:
- Distributed denial of service (DDoS) attacks
- Blocking of suspicious activity
- SQL injection, comment spam
- Possibility of quickly blocking IPs or entire countries
Encrypting Data in Transit
All HTTP-traffic to Cobalt runs over an SSL-encrypted connection and we only accept traffic on port 443. The status of our SSL configuration can be found here.
During a user agent’s (typically a web browser) first site visit, Cobalt sends a Strict Transport Security Header (HSTS) to the user agent that ensures that all future requests should be made via HTTPS even if a link to Cobalt is specified as HTTP. Additionally, we use HSTS preload, guaranteeing that requests are never – not even the very first – made over a non-encrypted connection. Cookies are also set with a secure flag.
Hosting and Database Storage
Cobalt is hosted via Google Cloud and managed within Google data centers that leverage secure Google Cloud Platform (GCP) technology.
Encrypting Data at Rest, Database
Cobalt’s backend is supported by a Postgres database to persist data. All data at rest and associated keys are encrypted using the industry-standard AES-256 algorithm. Only once an authorized user is granted access to their data will that subset of data be decrypted. For further details around the encryption at rest please see Encryption at Rest in Google Cloud Platform.
Encrypting Data at Rest, Files
Static files, such as images and other documents are persisted using AWS S3 storage. All static files are encrypted before they’re stored so while at rest they are encrypted.
GCP Security Practices
Cloud Platform and Google infrastructure is certified for a growing number of compliance standards and controls, and undergoes several independent third party audits to test for data safety, privacy, and security. Read more about the specific certifications on the GCP compliance page.
More information about GCP security can be found at Google Security Overview.
Password Policy and Storage
During an account creation and password update, Cobalt requires a strong password that has 8 characters or more, and contains numbers as well as lower- and uppercase letters. We do not store user passwords: we only store one-way password hashes using open source audited Bcrypt, including:
- Cost ratio 2^12 iterations - delaying brute-force attacks
- Per-user-random-salt - protect against rainbow table attacks and encrypted password matching
- Password concatenated with two individual app-tokens
If a user incorrectly enters an account password on multiple(10) attempts, the account will be temporarily locked to prevent brute-force attacks. To further protect account access, Two-factor authentication is available to all Cobalt users who use either Google Authenticator or Authy, and can be turned on via the user account security settings.
Following an email change, password change or similar sensitive user account changes occur, the user is always notified in order to quickly be able to respond, should an account attack be undergoing.
Request Throttling and Tracking
We employ Rack::Attack middleware for whitelisting, throttling, and tracking based on predefined security limits of the request.
XSS and CSRF Protection
To prevent Cross-Site Scripting attacks (XSS) all output is per default escaped in our Ruby on Rails framework before hitting the browser potentially causing XSS attacks. We avoid the use of the raw() method potentially causing unwanted data being sent to the browser.
In our Ruby on Rails framework protect_from_forgery is enabled and generates a random csrf_token to help prevent against Cross Site Request Forgery (CSRF) attacks.
Cobalt uses several services to automatically monitor uptime and site availability. Key employees receive automatic email and SMS notifications in the case of downtime or emergencies. Some of our preferred services for logging and 24h-notification-access are Data Dog HQ and Sentry.io.
We require all employees to use strong, unique passwords for Cobalt accounts, and to set up two-factor authentication with each device and service where available. All Cobalt employees are required to use recognized password managers like LastPass or 1Password to generate and store strong passwords, and are also required to encrypt local hard drives and enable screen locking for device security. All access to application admin functionalities is restricted to a subset of Cobalt staff and restricted by IP and other security measures.
Monitoring and Notifications
Cobalt uses several services to automatically monitor uptime and site availability. Key employees receive automatic email and SMS notifications in the case of downtime or emergencies. Some of our preferred services for logging and 24h-notification-access are SumoLogic and OpsGenie.
Code Review and Static Code Analysis
Cobalt institutes strict code reviews of changes to sensitive areas of our codebase. We also employ Snyk for static security code analysis to automatically detect potentially known vulnerabilities through static source code analysis.
Vulnerability Reporting(Bug Bounty)
Since launching Cobalt, we’ve invited anyone on the internet to notify us of issues they might find in our application to further strengthen and secure our platform. All vulnerability report submissions are read within hours of receipt, and we aim to respond to all submissions within 48 hours. Triage can take up to 72 hours for the team to review the issue and determine applicability. Completed resolution is between 24 hours and 60 days depending upon the severity and nature of the vulnerability.
In the event of a security breach, we have created procedures for resolute reactions, including turning off access to the web application, mass password reset and certificate rotations. If our platform is maliciously attacked, we will communicate this information to all of our users as quickly and openly as possible.