Security
Last updated on March 31th 2024.
At StickerDocs we take your data security seriously.
Open For Review
The StickerDocs app is built upon StickerDocs Core which is open source software. From the diagram below it should be clear that all data passes through StickerDocs Core. By opening up this key component anyone can review or enhance the security and privacy mechanisms.
We also contribute back to the open source community:
Encryption
StickerDocs uses end-to-end encryption (E2EE) meaning nobody at StickerDocs can decrypt your data stored within our systems. The only people that can decrypt your data are those that know your password, which is hopefully only yourself.
All files are encrypted on your device prior to transmission to a private AWS S3 bucket for storage.
Is It Quantum Resistant?
Not yet. We are aware NIST has recently published some Post-Quantum Encryption Standards, however we are waiting for greater standardisation, and ideally incorporation into libsodium. Please follow this discussion to learn more.
Authentication
Your password is never transmitted to StickerDocs. Your app derives a key from your password which we use to authenticate you when you log in. To the best of our knowledge this key cannot be used to determine your password.
App Security
The app is subjected to application security testing during development and at regular intervals. The app does not trust the data from the API and validates all input.
Sharing
When the recipient of a shared file downloads the file, that file is then re-encrypted for that user and uploaded to StickerDocs.
Trust Requests
The reason a secret is required to establish trust between two users is to prevent anyone at StickerDocs (or who has compromised StickerDocs) from intercepting that request and accepting it. If someone could do that they would be able to impersonate the person the sticker was intended to be shared with.
API Security
All user input is strictly validated by the API. All authenticated API requests are signed to reduce replay attacks. The API is subjected to application security testing during development and at regular intervals.
Cloud and Infrastructure Security
The API is hosted within AWS. All file data is encrypted before it reaches the cloud however we do have customer data stored within DynamoDB. This data consists of:
- Email addresses
- Names
Logging
We retain records of logins. These include IP addresses.
Staff Security
Access to the infrastructure is tightly controlled and actions are audited.
Threat Models
Endpoint (App) Compromise
If your device becomes compromised (hacked) there is very little that can be done. Whilst we expect modern devices to make use of full-disk encryption, if an attacker has access to your device then it’s pretty much game over.
We do not recommend jail-breaking as it weakens the security of the Operating System. The app has jailbreak detection to help our customers to make good decisions in that regard.
HTTPS Man In The Middle (MitM) / SSL Intercepting Proxies
All data to and from the API is via HTTPS. The authentication process makes use of additional cryptography such that an intercepting SSL proxy could not decrypt the login details from the user and the session data returned.
API / Infrastructure Compromise
The app has been built to not trust data from the StickerDocs API. All data from the API is validated and where appropriate, hashes and signatures are verified.
| Actor | Concern | Damage | Mitigation |
|---|---|---|---|
| Insider threat | A rogue file added to a user’s account | File is downloaded, possibly executed by the app, leading to Remote Code Execution (RCE) | All files uploaded by the user are signed. If the signature does not match th file is not processed. |
| Customer | Shares a malicious sticker with another customer | File is downloaded, possibly executed by the app, leading to Remote Code Execution (RCE) | SVG files are validated to contain SVG data. There are file size limits. |
App Store Compromise
Should an attacker steal our signing/account keys for the app stores they could impersonate us and attempt to push malware via app updates.
Our app source code is not public so that would also need to have been compromised if they intend on doing this covertly.
We know from first-hand experience that some of the app stores tend to be thorough in their review process and this will serve as an early warning of compromise also.
As users of the product ourselves we would know when a new version of the product has been published to the app store and if this was not an authorised action we will take steps to immediately notify the app stores.
Trade-offs
To balance security and performance the following trade-offs have been made:
- Local files are not encrypted. It is expected your devices will have at-rest/full-disk encryption enabled.
Vulnerability Disclosure Policy
We are a micro business, so we don’t have funds to pay bounties. We welcome responsible disclosures from security professionals and will acknowledge your efforts on this page. Thank you for helping us keep our customer’s data secure.
PGP Key
If you need to securely communicate with us our PGP key can be found here.
Bus-Factor
Relating to the security of our data there is the question of availability. As we are a small company to protect against any issues at our end, the app has an export feature which can be used to back up your data. We recommend you regularly back up your data. We have backups, but it’s on you to make your own backup.