All secrets are end-to-end encrypted, which means the plaintext values never leave your device. We do not log, track, share, or store the master passphrase that protects your account master keys.
A key derivation function is used to ensure the password used to encrypt the master account private key is always of constant length, is salted, and would be difficult to break computationally, although there is currently no validation on the strength of the master password chosen (except that the length must be at least 12 characters). This is something we are working to improve.
The computed password can optionally be stored in an OS keychain service such as macOS Keychain. We use Keytar to faciliate the integration with native OS keychains.
The password salt is currently stored in the ledger on our server, but we are looking at ways to improve the entire security model of generating and storing the account master key(s).
Lastly, our client code is fully open source. You can see exactly what it does and you can also see how the binaries get built and distributed.
We store the account email, account name, account and vault public keys and encrypted private keys. We store the private keys encrypted as PGP messages to allow for secure sharing. In theory, the mechanics of vaults and sharing secrets within vaults mimics how a Signal group chat works - allowing multiple members of a group to read end-to-end encrypted messages.
All secrets are stored encrypted as PGP messages.
You can take a look at the source code to see for yourself which details are being sent to our backend service.
A secret must belong to a vault. Each vault has its own keypair, where the private key is encrypted with the public keys of the members of the vault. The roles of the members (Read, Admin, Owner) are stored in the ledger and are used to control access to both the vault and the secrets within it.
For example, a Read role can only view secrets in a vault, an Admin role can add secrets to a vault, and an Owner role can additionally manage members of a vault.
One-time secrets can be created using the
snip share command and then shared by sending the generated URL to the recipient.
The secret value is encrypted using a private key which itself is then encrypted using a strong password generated by the CLI. This password can then be used to decrypt the encrypted private key and subsequently decrypt the secret on the receiving end - in this case in the browser. While we do not log, track, share, or store this password, it is embedded in the generated URL and so you should take extra care when sharing this URL with the recipient.
Once viewed, the secret will be deleted from the server along with the public key and encrypted private key used to protect it. The "get" and "delete" executions happen in a single transaction.
IMPORTANT: Make sure to note down your master passphrase and store it somewhere secure.
To register a new device, run
snip configure with your existing account email. Upon confirming your master passphrase you will be able to access your content again.
This is one of the reasons we chose a rather simple approach (PGP, encrypted keys, etc.) at first as we wanted to make sure the barrier to entry is as low as possible before we move onto a more advanced solution.
Sniptt is free for personal use with the following limits:
- Up to 100 secrets per month
- Up to 100 URL shares per month
- 1 additional vault (up to 3 members)
To increase limits and access more features, please email us at firstname.lastname@example.org.
Yes, we are actively working on providing a self-hosted option with licensing.
Our platform is built on AWS, using 100% serverless architecture. We rely heavily on Lambda, so you may occasionally experience what's called a "cold start". Another reason your requests might be taking slightly longer is if you're not in Europe. We're currently only deployed in eu-west-1 (Ireland), however we plan to deploy in 2 additional regions soon.