Keystash Security

Last updated on 25 May 2022

How we keep your systems and data safe

We’re committed to guarding your important systems and data. Keystash has invested in best practices and security policies that are continually evaluated and updated and we have outlined a summary of the systems in place that keeps Keystash secure.

1. Database Security

  • Customer data is stored in a single database with data access control rules implemented to isolate data.
  • Database table data is encrypted at rest utilising AES encryption algorithm.
  • Sensitive data like tokens and keys are all encrypted at query time using AES encryption.
  • All data in transit to and from databases is encrypted via TLS v1.3 and connections are verified via X509 certificates.

2. Password Security

  • Customer passwords are protected with industry-standard Bcrypt encryption with multiple salt rounds.
  • Keystash staff do not have access to your password, and cannot retrieve it for you.
  • Login credentials are always transmitted securely over HTTPS.
  • Keystash implements Two Factor Authentication using TOTP and is suggested for all user accounts.
  • Keystash implements rate limiting and IP blocking to stop brute force account attacks.
  • Internal passwords used in the administration of Keystash are a minimum 14 characters long and always randomly generated with uppercase, lowercase, numbers and symbols.

3. Staff Access

  • Authorised Keystash helpdesk staff have the ability to administrate your account and the settings therein to provide support for any issues you may have. The helpdesk staff will use their own account details; however, they can assume the identity of the person requesting support and will do so only with the approval of the person requesting support. All actions and changes are reflected in the Audit logs. This access increases security as staff never need to request your password.
  • Your privacy is extremely important to us and we will only request or investigate data that is absolutely necessary to provide the required support.

4. System Security

  • All Keystash servers are running hardened Linux distributions with up-to-date security patches and configured to the recommended standards of the CIS Benchmarks for the Linux distribution being deployed.
  • Only a limited number of trusted and authorised Keystash engineers have clearance to remotely manage servers. Access is only possible using an encrypted SSH keypair of significant strength, with Two Factor Authentication, from a computer with full-disk encryption and fully up to date end point security enabled.
  • All Keystash servers run individual local firewalls in combination with external load balancers and firewall protection systems.

5. Physical Security

Keystash servers are hosted in trusted data centers in specific regions of the world and they must all exceed our physical security criterions:

  • Restricted perimeter, physically accessed by authorized data center employees only.
  • Physical access control with security badges or biometrical security.
  • Security cameras and security personnel monitoring the data center locations 24/7.
  • They must meet or exceed the internationally accepted security standard ISO27001 and PCI DSS.
  • We make use of Amazon AWS and Akamai Linode servers in London, Amsterdam and Frankfurt regions.

6. Credit Card Safety

  • We never store credit card information on our own systems.
  • Your credit card information is always transmitted securely directly between you and our PCI-Compliant payment acquirers (Stripe and Zoho). You may view more details on our Privacy Policy.

7. Communications

  • All data communications to client instances are protected with 256-bit TLS encryption (HTTPS).
  • All internal data communications between our servers are also protected with encryption TLS or SSH.
  • Our servers are kept under a strict security watch, and always patched against the latest TLS vulnerabilities. We ensure we maintain a Grade A SSL ratings at all times (as per Qualys SSL Labs analysis).
  • All our SSL certificates use robust 2048-bit modulus with full SHA-2 certificate chains.

8. Network defence

  • We make use of large data centre providers that have significant network capacities and Distributed Denial of Service (DDoS) protection.
  • Firewalls and intrusion prevention systems on Keystash servers help detect and block threats such as brute-force password attacks on key infrastructure.


Software Security

The Keystash R&D processes have code review steps that include security aspects, for new and contributed pieces of code. WE have automated code scanning processes to check code linting, code quality, detect common code vulnerabilities and to scan any new dependencies that have been approved.

1. Secure by design

Keystash is designed in a way that prevents introducing most common security vulnerabilities:

  • SQL injections are prevented by the use of a database abstraction APIs that does not require manual SQL queries.
  • XSS attacks are prevented by the use of a templating systems that automatically escape data.
  • The framework prevents RPC access to private methods, making it harder to introduce exploitable vulnerabilities.

2. Security Audits

Keystash regularly run internal audits and automated infrastructure and configuration scans looking for vulnerabilities and security concerns.

Keystash is also regularly audited by independent companies that are hired by our customers and prospects to perform audits and penetration tests. The Keystash Security Team receives the results and takes appropriate corrective measures whenever it is necessary.

We can't however disclose any of those results, because they are confidential and belong to the commissioners.

Keystash has a community of independent security researchers, who continuously monitor the source code and work with us to improve and harden the security of Keystash. Our Security Program is described in our Responsible Disclosure section below.

3. OWASP Top Vulnerabilities

Keystash actively monitors and aligns with the OWASP security recommendations, as listed by the Open Web Application Security Project (OWASP):

  • Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Keystash relies on an object-relational-mapping (ORM) framework that abstracts query building and prevents SQL injections by default. Developers do not normally craft SQL queries manually, they are generated by the ORM, and parameters are always properly escaped.
  • Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. The Keystash framework escapes all expressions rendered into views and pages by default, preventing XSS. Developers have to specially mark expressions as "safe" for raw inclusion into rendered pages.
  • Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. The Keystash backend engine includes built-in CSRF protection mechanisms. In addition, the required CSRF headers are automatically applied to all rendered pages and assets.
  • Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Keystash does not expose functions to perform remote file inclusion.
  • Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. The Keystash access control is not implemented at the user interface level, so there is no risk in exposing references to internal objects in URLs. Attackers cannot circumvent the access control layer by manipulating those references, because every request still has to go through the data access validation layer.
  • Insecure Cryptographic Storage: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud. Keystash uses industry-standard secure hashing for user passwords (Salted Bcrypt) to protect stored passwords.
  • Insecure Communications: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. Keystash runs on HTTPS by default and all HTTP connections are automatically redirected to HTTPS.
  • Failure to Restrict URL Access: Frequently an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. The Keystash access control is not implemented at the user interface level, and the security does not rely on hiding special URLs. Attackers cannot circumvent the access control layer by reusing or manipulating any URL, because every request still has to go through the data access validation layer. In rare cases where a URL provides unauthenticated access to sensitive data, such as special URLs customers use to confirm a signup, these URLs are digitally signed with unique tokens and only sent via email to the intended recipient.

4. Reporting Security Vulnerabilities

If you need to report a security vulnerability, please email security@keystash.io. These reports are treated with high priority, the problem is immediately assessed and solved by the Keystash security team, in collaboration with the reporter, and then disclosed in a responsible manner to Keystash customers and users.



Data Backups and Disaster Recovery

Keystash has implemented a number of steps and policies to ensure the integrity of your data and the availability of the service.

1. Data Backups

  • We keep 30 full backups of the Keystash database, one each day. The database backups are individually signed and encrypted.
  • Backups are replicated in at least 2 different data centers in either AWS or Akamia Linode in the Frankfurt region.
  • We run automated data backup restore tests every 24 hours to check the integrity of the data within the backups.

2. Disaster Recovery

  • All key server infrastructure is deployed in an n + 1 configuration. Should a single server loss occur then the additional server capacity will continue to provide service. Keystash will replace the lost server resources within 60 minutes if the loss incurs any impact in service delivery. If there is no impact to service delivery then the resources will be replaced within 12 hours.
  • In the event of a complete disaster, where an entire data centre is not responsive for more than 8 hours, we have the following objectives:
    • RPO (Recovery Point Objective) = 24 hours. This means you can lose a maximum of 24h of work if the data cannot be recovered and we need to restore your latest daily backup.
    • RTO (Recovery Time Objective) = 20 hours. This is the time to restore the service in a different data center. This would be made up of 8 hours + 12 hours to restore services.
    • The entire Keystash infrastructure would be moved to a completely different data center region at either AWS or Akamia Linode within the European Union (EU). The impact is that all IP addresses for Keystash infrastructure would change.
    • Note that customers would still be able to access their servers via SSH during the disaster as Keystash is designed in such a way that our infrastructure is not required for you to access your servers via SSH.