Keygen = Security

Security questionnaire

As a software licensing and distribution service, we recognize the importance of excellent security practices for such critical infrastructure. While we are a small team, we take security very seriously.

General security practices

• Access to servers, datastores, source code, and third-party tools are secured with strong non-SMS two-factor authentication when possible.

• We use strong, randomly-generated passwords that are never re-used.

• We have strong 2FA policies for all Keygen personnel:

  • All Keygen personnel are required to use non-SMS 2FA on all first- and third-party services when possible. When non-SMS 2FA is unavailable, we require use of SMS 2FA. We always require strong passwords, regardless of 2FA availablility. Our decision tree for 2FA options are HW key, TOTP, SMS, email.

  • We allow you to do the same by supporting TOTP 2FA for all Dashboard admin users, as well as offering 2FA for your product users (contact us at [email protected] to learn more).

• We have no employees (we're the founders 👋), and the contractors we hire are given the lowest level of access that allows them to get their work done.

• We provide cryptographic signatures of all API responses, and we provide the ability to sign and encrypt license keys, and we support nonces on certain requests, all to help combat common application licensing attack vectors such as man-in-the-middle, spoofing and replay attacks.

• We use automatic security vulnerability detection tools to alert us when our dependencies have known security issues, such as GitHub Advanced Security. We are aggressive about applying patches, keeping dependencies up-to-date, and deploying quickly. Infrastructure security is handled by Heroku.

• We regularly perform internal and external vulnerability scans and application penetration tests to monitor the status of our security efforts.

• We prefer third-party tools with strong privacy and security postures that align with our goals.

• We have strong rate-limiting measures in place to reduce API abuse. We've tried to design our rate limiting in a way that will not affect normal users of the service.

• We have near-100% integration test coverage on our API code base. Each time a bug or vulnerability is reported, we write a test (or ten) to ensure it never comes up again.

• We never copy production data to external devices (such as personal computers).

Infrastructure

• Our servers are hosted by Heroku. Heroku uses Amazon Web Services (AWS) for their infrastructure, meaning all of our servers and datastores are hosted on AWS infrastructure, managed by Heroku. Distribution artifacts are hosted by AWS S3. AWS is the largest and (in our opinion) most sophisticated hosting company in the world, and they have extensive physical and digital security in place. AWS regularly verifies their security through third-party auditors. For further information, see Heroku's security policy.

• Our main servers are in Virginia, USA at Amazon's US-East data center. We also keep encrypted backups of data in other locations within the USA in case anything happens to the Virginia data center. Our distribution service, AWS S3, replicates artifacts into an EU region for some customers.

• Our infrastructure provides DDoS mitigation techniques including TCP Syn cookies and connection rate limiting in addition to maintaining multiple backbone connections and scalable internal bandwidth capacity.

• Amazon continually manages risk and undergoes recurring assessments to ensure compliance with industry standards. Amazon's data center operations have been accredited under:

  • ISO 27001
  • SOC 1 and SOC 2/SSAE 16/ISAE 3402 (Previously SAS 70 Type II)
  • PCI Level 1
  • FISMA Moderate
  • Sarbanes-Oxley (SOX)

Authentication

• At sign-up, each admin sets up a new profile with their email and password. Passwords are securely hashed using industry-standard bcrypt, and all secrets are securely encrypted in-transit and at-rest. We never store passwords or secrets as plain text.

• API access tokens are securely hashed using a SHA-256 HMAC function, using a strong per-account secret key. We never store API access tokens as plain text.

Authorization

• We operate a multi-tenant application with row-level security. We have extensive unit tests and multiple failsafes at the database- and application-level concerning data isolation.

• We use standard RBAC for authorization. API access tokens are assigned a role, which gives them certain privileges and access permissions based on the resources they own and are associated to. Only administrative users can view and manage resources that do not belong to them.

Encryption

• All communication between the Keygen service, your software products, and our backend service is encrypted with TLS. We use Automated Certificate Management provided by Let’s Encrypt. User data is stored in Heroku PostgreSQL and details of their implementation can be found on the Security page at Heroku.

• We use 256-bit encryption at all levels of our systems. We enforce TLS (HTTPS) to protect sensitive data transmitted to and from applications i.e. data in-transit.

• All data is encrypted at-rest with industry-standard AES-256 block-level storage encryption. Keys are securely managed by Amazon EBS.

• Highly-sensitive data, such as private keys and secrets, is encrypted at-work using AES-256-GCM encryption.

Payments

• Credit card and bank information is encrypted, stored, and processed by Stripe with AES-256 encryption. Full details are available on Stripe's security page. Keygen stores a transient token provided by Stripe to reference a customer's credit card through the Stripe API. Credit cards are not stored on Keygen servers, nor do we have access to the card number or details. This information does not pass through Keygen servers. All communication with Stripe is handled over an encrypted TLS connection.

Crashes and other errors

• We are aggressive about monitoring for application errors and crashes, and resolving them as quickly as possible. We strive to provide 99.99% uptime, and do offer an SLA for enterprise customers.

FAQs

What user data do you collect?

We're not in the business of making money off of data. However, we do collect information about how who is interacting with the system so we can monitor and improve the product, and provide faster, more effective support when issues arise. These events include API requests, sign-ins, sign-outs, etc.

More information on the type of data we collect can be found in our privacy policy.

How long is data retained and can I have it removed?

Server and application logs are retained for a maximum of 30 days, after which they are permanently deleted. Retention of account analytics can span up to 90 days, but can be permanently deleted on request.

Do you have any vulnerability audit or penetration test reports that we can review?

Yes, our ImmuniWeb report from Q3 2021 is available here. ImmuniWeb is CREST accredited. If your company requires us to obtain a vulnerability assessment or pen test from different vendor, please email us and we can chat.

Will you fill out our security questionnaire?

Due to our small team size, we do not have the bandwidth to fill out security questionnaires for every customer. Please email us if you do not see one of your specific questions answered on this page and we can add it.

Do you maintain any security certifications such as SOC 2 or ISO 27001?

While we'd eventually love to achieve these certifications, we don't hold them at this time. Please email us if you'd like discuss working with us to get these certifications.

Is your system HA?

Yes, our infrastructure and datastores are highly available (HA). For infrastructure, we have auto scaling and health checks in place. For datastores, we have primary standbys in place with automatic failover. Standbys are always hosted in a different availability zone (AZ).

How do I report a potential vulnerability or security concern?

Please email us at [email protected], which will notify us very loudly, and we'll get back to you ASAP. Our PGP key is available here.

If you have a discovery, please discretely reach out to a member of the team via email for verification, vulnerability acceptance, and remediation timeline.

We believe in — and participate in — responsible disclosure. At this time we do not have a bug-bounty program in place, but would like one in the future.

Our public key fingerprint is E2A3 C809 9721 7FB6 A578 D08A E3C6 4A7B FE47 7AAA.

Any further questions?

Please email us and we'll happily update this doc.