Technical Whitepaper

Owned by Anton Storozhuk
Last updated: Apr 21, 2023
9 min read

Summary of Key Principles

Vault Password Manager offers a secure password management solution for teams, businesses, and enterprises. Our system utilizes various security measures to increase productivity and reduce the chances of password-related breach.

  • We ensure secure and reliable access to your vault data through Atlassian's Jira platform. Our host-proof solution encrypts sensitive data locally on the end user's device and on Atlassian infrastructure. Admins have centralized control through a Jira admin dashboard that includes configurable security policies, provisioning, reporting, and more.

  • We follow industry-standard encryption best practices to protect sensitive data against brute-force and man-in-the-middle attacks. Our system is hosted on Atlassian's data centers, which comply with best practices for redundancy and stability.

  • We provide timely incident response and incentivize responsible disclosure through our Bug Bounty program. We also engage trusted third-party security firms for routine audits and annual testing of our service and infrastructure.

  • Vault Password Manager is backed by Alpha Serve, a leading software company. With our comprehensive security measures, your password management needs are in safe hands.

Introduction

Vault Password Manager provides effortless security solutions for enterprises, businesses, and teams in both office and home office settings. In our cloud-centric world, secure authentication and access are essential for protecting systems, data, and assets.

Our mission is to keep Jira customer information safe and provide a reliable service through password management. We achieve this by building security into the product's foundation and providing configurable security features to meet users' specific needs and follow best practices.

We continuously update our software and service with the latest technology to address emerging security threats. We work closely with the Vault Password Manager community and security researchers to strengthen our security model.

By implementing our solutions, businesses and consumers can strengthen their defense against attackers. At Alpha Serve, we take proactive measures to review security reports, address issues, and evaluate new technologies to improve our security model.

 

Logging in to the Vault Password Manager

The Application Password 

When a Jira user creates an account in the Vault Password Manager app, he generates an Application Password. This password is used to authenticate the user's access to the application account.

Once authenticated, the user can access and manage stored credentials and other items for various websites within the Vaults. The Vault serves as the space where users can add, view, and manage stored items. Access to the Vault is granted only after successfully entering the correct Application Password.

A Strong Application Password 

it is crucial for users to select a robust password for their application account to secure their vault. Although the industry-standard of a minimum of 8 characters is enforced when creating the Application Password, users should strive for a password that is lengthy, unique, and incorporates a variety of character types to ensure maximum security. A strong Application Password also makes a brute-force attack infeasible and ensures the encryption keys generated from the password are secure.

The Application Password must never be used for any other website or application, not even a variation of it, as it could put the user's application account at risk in the event of a breach on another website. It is also essential never to share the Application Password with anyone, including Alpha Serve or Atlassian employees. Users should treat any requests for the password as a threat and report them to the Jira Administrator.

Protecting the Application Password 

The encrypted Vault data in the Vault Password Manager is meaningless to anyone without the decryption key, which is created from a combination of Jira account username and Application Password. The Application Password is never sent to the Vault Password Manager application.

New Device Verification

Upon accessing the app from an unfamiliar or previously unused device, application mandates that users undergo a verification procedure to establish the device's trustworthiness. This authentication process necessitates the input of both the user's RECOVERY KEY and Application Password. Upon successful entry of the accurate RECOVERY KEY and Application Password, the new device is deemed trustworthy. Subsequent logins from the authenticated device will no longer require completion of the verification step.

Encryption

The encrypted Vault in the Vault Password Manager app is designed to prevent the ability to decrypt a Vault without a user’s Application Password.

Local-Only Encryption Model

Vault Password Manager utilizes a local-only encryption method, also referred to as "host-proof hosting." This security solution is crafted to ensure that only account owner can decrypt and access his data. This is known as "Local-Only Encryption," signifying that all sensitive vault information is encrypted and decrypted solely on the user's local device (e.g., Chrome, Firefox), rather than after syncing to Jira Forge servers.

Data is synced to Jira Forge to the secured storage only after it has been encrypted with the user's unique encryption key. Sensitive information is sent to Jira Forge as a base64 encoded block of encrypted data, ensuring it never interacts with Jira Forge in a manner visible to the Vault Password Manager application or Jira app Atlassian or Alpha Serve. Neither the Vault Password Manager application nor Alpha Serve has access to or stores the Application Password, which precludes Alpha Serve from decrypting a user's sensitive Vault data.

Consequently, Alpha Serve and its employees are unable to access the sensitive data stored in a user's Vault or remotely access a user's device. The data within the Vault is decrypted instantly on the user's device when needed, after the successful input of the Application Password, including during access to their account via the web vault and any mobile apps.

AES 256-bit Encryption

The application employs top-notch encryption and hashing algorithms to safeguard user information. Utilizing local-only encryption and locally-generated, one-way salted hashes, application users enjoy a perfect blend of comprehensive security, online accessibility, and cloud-based synchronization.

User data is encrypted using the reliable Advanced Encryption Standard (AES) algorithm in Cipher Block Chaining (CBC) mode, with a 256-bit key derived from each user's Application Password. The AES 256-bit algorithm is widely recognized as impervious to attacks and is employed by banks and the US military for securing Top Secret information. We maintain that the most effective defense is simply not possessing access to unencrypted sensitive vault data.

Key Derivation

Upon account creation, the user's device (client-side) hashes the Application Password, utilizing the User ID and Recovery Key as salt. The encryption key is generated using a default of 27,000 rounds of PBKDF2-SHA256, followed by an additional single round of hashing to create the Application Password authentication hash (or "login hash"). This hash is transmitted to the Vault Password Manager server for an authentication check during the user's login process. Employing a salt (a unique random string for each organization), an additional 27,000 rounds of PBKDF2 hashing and Scrypt, a top-tier hashing algorithm, are applied. When the user logs in, this value is compared to the authentication hash stored in our database. The Vault Password Manager saves this value your Jira Forge Storage to verify upon the user's subsequent login.

The Application Password and encryption key are never sent outside of your PC. Moreover, since hashing is a one-way algorithm, Vault Password Manager is unable to reverse the received authentication hash.

In conclusion, cracking our algorithms with a strong Application Password is virtually impossible, even for the most powerful computing systems.

Key Strengthening with PBKDF2

Vault Password Manager employs AES 256 in conjunction with thousands of rounds of PBKDF2 SHA-256, a password-enhancing algorithm, to generate a user's distinct encryption key. PBKDF2 is an adaptive one-way function that hashes a password multiple times using a selectable hashing algorithm determined by the service provider. This feature complicates the process for a computer to verify the accuracy of any single password during a brute-force attack.

Vault Password Manager has chosen to utilize SHA-256, a slower hashing algorithm offering increased protection against brute-force assaults. The system conducts x rounds of the function (27,000 by default) to produce the encryption key before executing an additional single round of PBKDF2 to create the user's login hash.

The entire procedure takes place client-side. The generated login hash is then shared with Vault Password Manager, which uses the hash to confirm that the user has entered the correct Application Password during the login process.

Vault Password Manager also performs 27,000 rounds of PBKDF2 server-side. This dual implementation of PBKDF2—both client-side and server-side—ensures comprehensive protection for the user's data, both the offline local portion and the online segment stored on Vault Password Manager servers.

 

PBKDF2 can be described as: 

Derived Key = PBKDF2(PRF, Password, Salt, Iterations, Key Length) 

Where: 

  • PRF is the hash function to be used. 

  • Password is the Application Password.  

  • Salt consists of bits of data unique to each account used to ensure the same Application Password does not produce the same derived key. 

  • Iterations is the desired number of iterations to run the PRF. 

  • Key Length is the desired length of the derived key. 

 

A RecoveryKeyHash is calculated with: 

PBKDF2(SHA-256, RecoveryKey, UserId+RecoveryKey, 27,000, 256) 

A Vault encryption key is calculated with: 

PBKDF2(SHA-256, Application Password, RecoveryKeyHash+accountId, 27,000, 256) 

To create a login hash, an extra level of PBKDF2-SHA256 is run on the user’s password using the user’s vault encryption key to create another 256-bit hash, thus increasing the number of iterations to 27,000.

Login hash = PBKDF2(SHA-256, Application Password, UserId+organizationKey, 27,000, 256) 

This hash value is sent to Vault Password Manager and used for account authentication. Additional measures are taken to protect this hash before it is stored by Vault Password Manager, as described in the Login Hash Storage section of this white paper. 

Due to the number of rounds used, users may notice slowness or problems connecting to Vault Password Manager when logging in via certain browsers, such as legacy versions of Internet Explorer.  

 

Shared Vaults

Public Key Cryptography

Vault Password Manager leverages RSA public key cryptography to enable users to share Vaults containing credentials with Jira users synchronized via Vault Password Manager application. Both admins and users can share vaults to provide suitable access to Jira organization users or groups without revealing the credentials themselves. Despite being shared through Vault Password Manager, the data remains undecipherable to the platform.

RSA employs asymmetric key algorithms, wherein the encryption key differs from the decryption key. Each user possesses a pair of cryptographic keys: one public and one private. The public key can be shared with anyone for data encryption purposes, while the private key, accessible solely to the user, decrypts data encrypted using their public key.

Upon sharing a vault, a 256-bit encryption key is generated to encrypt the data stored in the shared vault. This encryption key is then encrypted with the public key of each invited individual to the shared vaults and can only be decrypted using the invitee's corresponding private key. The private key is safeguarded by a master key hash with salt (user ID and Recovery Key). Each user device maintains its own distinct private and public keys.

 

Account Recovery

Since the application does not save the user’s Application Password, it cannot provide conventional password reset options typically available on other web services.

If a user forgets their Application Password, Alpha Serve is unable to retrieve or reset it. However, users have two options:

  1. Self Recovery allows users to create a new Application Password and RECOVERY KEY if they possess an old RECOVERY KEY.

  2. Admin Account Recovery is a process that users can initiate, and any Jira Admins (Admin Group) can complete.

 

Recovery Key

On desktop browsers, a random Recovery Key is generated on the user's device during account setup. This key encrypts the Vault encryption key (re-generated at login) using AES-128 in CBC mode. The encrypted Vault key is then transmitted to Jira Forge servers, while the Recovery Key is stored locally on the device.

The encrypted Vault key cannot be retrieved from Vault Password Manager until the user initiates account recovery. The encrypted vault key on the Vault Password Manager servers remains secure, as the recovery key is never shared with VAULT.

When Account Recovery is requested and approved by a Jira admin, the encrypted Vault key is downloaded and decrypted locally on the user's computer using the Recovery Key. The user sets a new Application Password, generates a new Vault encryption key and a new login hash, and encrypts his Vault data with the new key. The previous encrypted files are removed from Vault Password Manager servers, rendering the old keys obsolete.

Admins with the system role ADMINISTER and SYSTEM_ADMIN may initiate the process of account recovery which will allow to change the Application Password for employee account.

 

Safeguarding the Client

The Vault Passwords Manager client operates as a Jira/browser app compatible with all major browsers on Windows, Mac, and Linux platforms. Communication between the client and Jira Forge (VAULT) servers utilizes TLS connections.

Browser-based connections receive additional protection through browser security measures. HTTP Strict Transport Security (HSTS) mandates all connections to use TLS, reducing the risks associated with downgrade attacks and misconfiguration. Content Security Policy headers offer extra defense against injection attacks, including cross-site scripting.