Password-Hardened Encryption

PureKit replaces password hashing in a way making it impossible to run offline and online attacks. You will not store user’s password hash in your database or any other. By interacting with PHE Service, a standalone cryptographic service in Virgil Cloud dedicated to implement PHE protocol, PureKit creates a unique user’s PHE record associated with user's password. It is important to note that a user password is never transmitted to the PHE service in any form.

Developers can store users' password records and encryption keys in their infrastructure or on the Virgil Cloud. Neither Virgil PHE Service nor Keys Storage know users' passwords or their hashes, and can't get access to any encryption key.

The Virgil PureKit makes implementing PHE’s advanced cryptography accessible to the average developer. Take a look at the Virgil Security's PHE Service Technical Paper for more information about the technical details.

How PHE works

Virgil’s offering consists of a cloud service (PHE Service) plus open source SDKs (PureKit) which together implement the PHE protocol.

The protocol consists of two phases:

  1. Enrollment (registration). During the enrollment phase, your application backend with installed PureKit interacts with Virgil PHE service to bind a user's password and random encryption key to it thereby creating a unique PHE record (password record) for a specific user of your database. Learn more about PHE records in PureKit whitepaper.

  2. Login (authentication). During the login phase, the client attempts to unbind the server's cryptographic information from the PHE record using the user's provided password, and if this process succeeds, only then the client is able to decode the encryption key used to protect the user's personal data.

To verify a user's password, the client communicates with the server and provides the same cryptographic data that was supplied during the enrollment phase. This makes it impossible to get to the user's passwords even if the database was compromised, which is an especially useful feature for SMBs who don’t have the resources to manage the fallout from a data breach.

Having a unique encryption key per user record makes it possible to decrypt personal data only if the user supplied the correct password.

This technology can be used within any database or login system that uses a password, so it’s accessible for SMBs of any industry or size. And the potential impact could eliminate password and database breaches completely, which is not an exaggeration.

Registration with PureKit

In PureKit registration is a process during which your application backend with installed PureKit interacts with Virgil PHE service in order to create a unique PHE record (password record) for a specific user of your database.

As a result, during the registration step, each user obtains:

  • personal unidentifiable profile at the PHE service;
  • unique password record, that needs to be stored in your database;
  • and a unique key pair that will be used on the next (encryption) step for data protection.

Note! User's key pair is associated with their password record.

To create a password record for a new or existing database, go through the following steps:

  1. Take a user's password (or its hash or whatever you use) and pass it through the registration function in the PureKit on your Server side.
  2. PureKit will send a request to the PHE service for registration.
  3. Then, PureKit will create a user's password record and defaultly saves it at Virgil Cloud. If you're using custom storage, save the password record in your database.

Create Pure Record

Authentication with PureKit

Authentication is a process during which the Virgil PHE service checks whether the user password was entered correctly. If user authentication is successful, the user is given access to their encryption keys in order to perform data decryption.

Approach advantages:

  • First, both the Service Provider and the PHE Service alone are unable to check whether a given password is correct. This means the best strategy for any attacker who has fully compromised the Service Provider is to launch online (instead of offline) attacks.
  • Second, the PHE Service can track the number of unsuccessful login attempts of each client, and rate-limit password validation requests (e.g. online attacks), on a per-user basis.
  • Third, the PHE Service has no information about user passwords.
  • Lastly, if the Service Provider or the PHE Service is compromised, or if the secret keys have been in use for quite some time, the Service Provider and PHE Service can jointly rotate the keys to refresh their secret keys. Furthermore, key-rotation is invisible to the end users. Specifically, the server can locally update end user records without interacting with the PHE Service or the end users.

PHE service doesn't know users' passwords or their hash, it is ONLY able to check if the password was entered correctly.