One-Time Share
Time-limited secure sharing of a record to anyone without having to create a Keeper account
Last updated
Time-limited secure sharing of a record to anyone without having to create a Keeper account
Last updated
Keeper "One-Time Share" provides time-limited secure sharing of a record to anyone without having to create a Keeper account. One-Time Share is the most secure way to send confidential information to an external person or contractor without exposing information over email, text message or messaging.
One-Time Shares are secure by design, utilizing Keeper's Zero-Knowledge encryption. The record data is decrypted locally on the recipient's device using 256-bit AES and all requests to the server are signed with elliptic-curve cryptography (ECDSA).
One-Time Share is only available on new record types. Legacy "General" records are not compatible. If you're not seeing the One-Time Share feature, change the record to a login type, or create a new record.
To create a One-Time Share, open a Keeper record and click on the Edit Icon > One-Time Share.
Select how long the share link should be valid. The record will expire at a time of your choosing, and it can only be viewed on one device. Even if you forget to un-share the record, it will expire and access will be revoked.
Share links will expire after the selected amount of time, if the link is never used. If the link is used and bound to a device, the record access will expire after the same amount of time.
You can either copy the Link only, the Invitation to share the record with another person, or simply scan the QR code.
When the recipient opens the link, the record will render in the device browser.
As an additional layer of security, One-Time Shares are device-locked which means that only the original recipient is able to access the data. If the link is later opened up by a third party, or your email account is compromised, the link cannot be accessed, except on the original device.
Share access credentials with a contractor
Share an encrypted file with a co-worker
Provide secure documentation or instructions
One-Time Share links can be sent to recipients through any trusted channel, such as:
Direct QR Code Scan
Airdrop
SMS
Enterprise messaging platforms
Any other out-of-band channel
The applications and uses for this are virtually endless. Any time you have a need to securely deliver data to a non-Keeper user, One-Time Shares are the perfect choice.
For existing Enterprise customers, One-Time Share is disabled on all default role policies.
To allow this feature on your existing default role policies, visit the Role > Enforcement Policies > Creating and Sharing.
For all new role policies created after the launch of the One-Time Share feature, it is enabled by default.
Create One-Time Share links programmatically using the Keeper Commander CLI tool. Relevant commands:
Commander offers additional controls such as fine-grained expiration times, additional output methods, and the ability to remove previously created One-Time Shares.
For more information see our Keeper Commander Documentation.
The encryption model implemented for one-time sharing uses the same technology as Keeper Secrets Manager, a zero-knowledge and zero-trust platform for protecting cloud infrastructure.
The security model and method of encryption is detailed below:
(1) In the vault, the sharer generates a one-time access token by clicking on "One-Time Share" in the record options screen. The 256-bit AES Record Key for the record being shared is encrypted with the one-time access token, and this encrypted value is stored in the Keeper Cloud.
(2) The sharer sends the One-Time Access Token to a recipient via a simple URL or QR code through their preferred channel. The URL portion that contains the access token is held within the "fragment identifier" section of the URL which is never sent over the network to Keeper's servers. Therefore, zero-knowledge is retained and Keeper has no ability to access or decrypt the information.
(3) The recipient opens the URL on their device browser, and a single-page Vault application is loaded on the device. The One-Time Access Token is handed off directly to the local vault application (not sent to the server).
(4) Upon loading the URL, the recipient's device generates a client-side public/private Elliptic Curve key pair, and the private key is stored locally on the Client Device in the browser's CryptoKey storage.
(5) Upon first use, the SDK library authenticates using the hash of the One Time Access Token and upon successful authentication, the server responds with the encrypted record ciphertext plus the Encrypted Record Key.
(6) The Client decrypts the Record Key with the One Time Access Token, and the record contents are decrypted using the Record Key. The Record Key is then stored locally on the client device in the browser's CryptoKey storage or other designated storage location.
(7) On the server, the encrypted record key for that given device is deleted so that the One Time Access Token cannot be used again. After that, the client's requests must be signed with the Client Private Key.
(8) Subsequent calls on the same device to the server are sent with an identifier which uniquely defines the device (hash of the one-time access token) and a request body that is signed with the Client Private Key. The server checks the ECDSA signature of the request for the given device identifier using the Client Public Key of the device. The Keeper Cloud processes the request for the record, and the server returns encrypted record ciphertext to the Client upon successful authentication.
(9) In addition to the record-level encryption, the Client Device creates a randomly generated AES-256 bit Transmission Key which is encrypted with the public key of the Keeper cloud API. The Client Device decrypts the response from the server with the Transmission Key and then decrypts the ciphertext response payload with the Record Key, which decrypts the contents of the record.
Additional details about Keeper's encryption model is documented here.
The use of One-Time Sharing can be restricted by the Keeper Administrator in the Roles section of the Keeper Admin Console.
