PassHub Security Explained

Technical white paper

PassHub is a highly available web-based password manager, targeted at sharing credentials, notes and files between users in ad-hoc groups.

Dealing with sensitive data, PassHub relies on

  • Strong user authentication
  • Client-side encryption
  • End-to-end encryption for shared data

WWPass Service

To achieve its exceptional features, PassHub employs WWPass service to authenticate users and to provide personal encryption keys. Users get their own “authenticator” in the form of hardware token or smartphone app – PassKey. In fact, the PassKey is more than just authenticator – it is also used for local cryptographic operations, crucial for client-side encryption. You can read more on the WWPass technology on WWPass site.

Strong User Authentication

Unlike many other solutions for user data encryption, PassHub does not use usernames and passwords to allows users to access their Passhub accounts.

A traditional approach is to attach a user account to e.g. e-mail address (usually known to the outside world) and then to use a password to not only authenticate the user but to also derive a user encryption key. It is a well-known fact that passwords are often reused in many accounts (one of the weakest sides of login/password technology), thus making it possible to guess user credentials.

In PassHub, the PassKey app authenticator uses the so-called “trusted device” model, making additional factor – PIN (“something you know”) – optional. The same device is used to handle user encryption keys, but this time the encryption keys are totally separated from authentication parameters of the PassKey.

The PassKey is essentially a one-to-many authenticator. The same PassKey may be used to authenticate the user on many sites. Unlike e.g. OAuth protocol, WWPass fully isolates user data of different Service Providers - a feature known as “directed identity”.

Client-Side Encryption

PassHub implements client-side encryption architecture: user data such as credentials, files, notes, are encrypted in the browser on the user laptop, desktop, or mobile device. The encrypted data is sent to the PassHub server. Here is an example of a record stored in PassHub database:

	"_id" : ObjectId("5a9a1b20dab32d06ec49081c"),
	"SafeID" : "5a9a1b20dab32d06ec490816",
	"iv" : "XAaS59w8IgbsZOvXK+Vk8Q==",
	"data" : "0nfky8UsDOsa4w==",
	"tag" : "SFvqeiWESWrjmT2LErFi/Q==",
	"folder" : "5a9a1b20dab32d06ec490818",
	"lastModified" : "2018-03-03T03:48:48+00:00",
	"version" : 3

When a user opens the PassHub page, the data is decrypted in the browser and then presented directly to the user. The Passhub server never sees this data in a decrypted form.

Client-side encryption implies the existence of a cryptographic key in a user device (in a browser or an application). This cryptographic key is constructed by PassKey and delivered to the browser. Since a PassKey is a one-to-many authenticator (the same PassKey may be used on different websites and services, with full isolation between them) the client-side encryption key is unique for every User - Service Provider pair and is not known to WWPass itself.

More on client encryption key, Kc

This client-side encryption feature leverages a unique WWPass service. During personalization, each PassKey generates and stores a secret symmetric key, which never leaves the PassKey itself. WWPass authentication scenario may include “client-side key” request. When a PassKey authenticates to WWPass network, the latter sends a unique service provider ID (SPID) to the PassKey. With its internal secret key, the PassKey generates a specific “client-side” encryption key using the SPID as a key material. This way every User - Service Provider pair gets its independent encryption key Kc on the client side. Another challenge is to send the key to the browser (the QR code is a “one-way” transport). To send the encryption key in the opposite direction, we use a two-hop channel between a PassKey and WWPass and then, from WWPass to the browser via web socket. The “client-side encryption key” is ciphered, so WWPass does not get it in clear text.

End-to-End Encryption for Data Sharing

For data sharing, Passhub uses multi-tier cryptographic key architecture.

User asymmetric key pair { Kpub, Kpr }

When a user account is created in Pashub, an asymmetric RSA key pair is generated in the user browser and is sent to the server, with its private key encrypted with the client-side symmetric key: { Kpub, Enc(Kc, Kpr)) } Thus, the user private key is not known to the server

Encryption Key of a Safe, Ks

User data is stored in groups called “safes”. Each safe may contain credential records, notes, and files, possibly placed in folders. Safes define sharing granularity: you can only share the whole safe, not a folder or individual record.

Each safe has its own symmetric encryption key. Every record in a safe is ciphered with the encryption key of the safe. File encryption includes another level of indirection: they are encrypted with individual keys, which, in turn, are encrypted with the key of the safe. This scheme allows to move files from one safe to another without re-encrypting the file body. The encryption key of the safe is generated in a user browser when the user creates a new safe. The key is encrypted with the user public key before sending it to the server: Enc(Kpub ,Ks). Thus, the encryption key of the safe Ks is not known to the PassHub server.

When a user reads the content of a safe, all items of the safe are downloaded to the browser in encrypted form. Along with this data, the browser also gets an encrypted key of the safe Enc(Kpub, Ks) and encrypted user private key Enc(Kc, Kpr). Now, the browser first decrypts user private key with client-side key Dec(Kc, Enc(Kc, Kpr)) and the safe key: Dec(Kpr, Enc(Kpub, Ks)).

Sharing Access to a Safe

When an owner of a safe provides access to this safe to another user (recipient), the owner's browser downloads the owner’s encrypted private key, the key of the safe and the recipient’s public key. After decrypting the key of the safe, this key is re-encrypted with the recipient’s public key and sent to the PassHub server. The latter creates a new access record binding the safe ID, the recipient's ID, and the key of the safe, encrypted with recipient public key. Now, the recipient is able to decrypt all records and files of the safe.

High Service Availability

For a password manager as a public service, 24x7 availability is crucial. is deployed on 3 geographically separated Linux servers. Two of them are identical and run Nginx HTTP servers, a PHP 7+ engine and MongoDB database in replica configuration. The third server has no public access and serves as a MongoDB arbiter, required by replica architecture.

Apart from its own availability, the PassHub relies on the availability of WWPass service. The WWPass network was specifically designed to be highly redundant and available. Since it is distributed over the globe with Reed-Solomon redundancy six-out-of-twelve data nodes, the WWPass network is a unique service with all components deployed in multiple instances thus providing no single point of failure.

For a dedicated corporate on-premises implementation, the most basic PassHub configuration requires a single Ubuntu server with Nginx HTTP server, PHP 7+, and MongoDB database.

Summary is a highly available password manager web service with fine-controlled sharing capabilities. Client-side encryption, based on WWPass service and hardware devices or smartphone apps, provides higher security than that based on user login/password pairs. Encryption keys are bound to cryptographic user authenticators (hardware or software) and hence do not depend on a particular browser on a particular device. PassHub can be accessed on any device, laptop, desktop, or mobile. Sensitive user data are encrypted directly in user devices and are not known to server.