One-Time Share
Time-limited secure sharing of a record to anyone without having to create a Keeper account
One-Time Share
One-Time Share is live on all platforms.
Note: Admins must activate this feature from the Admin Console role policy
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, try creating a new record. Vault version 16.8 contains a feature to convert General to new record types.
Keeper One-Time Share
To create a One-Time Share, open a Keeper record and click on Options > One-Time Share.
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 used on one device. Even if you forget to un-share the record, it will expire and access will be revoked.
Set Record Access Expiration
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 copy the Link or the Invitation to share the record with another person. Or simply scroll down and scan the QR code.
Copy Link or Invitation
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.
One-Time Share Recipient
- 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
- Email
- 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 > Sharing & Uploading.
For all new role policies created after the launch of the One-Time Share feature, it is enabled by default.
One-Time Share Role Policy
Create One-Time Share links programmatically using the Keeper Commander CLI tool. To create a One-Time Share use the
one-time-share create command.
Creating a One-Time Share with Keeper Commander
Commander offers additional controls such as fine-grained expiration times, additional output methods, and the ability to remove previously created One-Time Shares.
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.
Last modified 1mo ago