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 pure-record that is associated with the user password. It is important to note that a user password is never transmitted to the PHE service in any form.
Developers can store users' Pure 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:
- 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 Pure Record for a specific user of your database.
Pure-Record - a unique data that is associated with a specific user’s password (1 password = 1 record). Each Pure-Record contains a user's Pure-Record version, your application & PHE service random salts, two values obtained during the execution of the PHE protocol and user's PHE encryption key.
- Login (authentication). During the login phase, the client attempts to unbind the server's cryptographic information from the Pure Record using the user provided password and if this process succeeds, only then is the client 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.
Pure Record enrollment
In PureKit enrollment is a process during which your application backend with installed PureKit interacts with Virgil PHE service in order to create a unique Pure 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 Pure 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 Pure Record.
To create a Pure Record for a new or existing database, go through the following steps:
- Take a user's password (or its hash or whatever you use) and pass it through the
EnrollAccountfunction in the PureKit on your Server side.
- PureKit will send a request to the PHE service for registration.
- Then, PureKit will create a user's Pure Record. You need to store this unique user's Pure Record in your database in the associated column.
- (optional) Encrypt your user password hashes with the recovery key generated in Generate a recovery keypair step and save them to your database.
Authentication with Pure Record
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.
- 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.