TL;DR
Worklist maakt gebruik van ChaCha20-Poly1305-versleuteling met zero-knowledge-architectuur. Uw gegevens worden op uw apparaat versleuteld voordat ze onze servers bereiken met behulp van gedocumenteerde cryptografische primitieven. We kunnen uw taken fysiek niet lezen, zelfs niet met volledige toegang tot de database. Een door u bewaarde reservesleutel kan de toegang eenmalig herstellen als u uw wachtwoord kwijtraakt, zonder Worklist een ontsleutelingssleutel te geven. Het ondersteunt AVG-dataminimalisatie en kan helpen met HIPAA/SOC 2 technische beveiligingen in combinatie met vereiste overeenkomsten en operationele controles.
Ons kernprincipe.
Uw gegevens worden op uw apparaat versleuteld voordat deze onze servers bereiken. We hebben Worklist zo ontworpen dat wij – het bedrijf – uw werklijsten, taken of opmerkingen niet kunnen ontsleutelen, lezen of openen. Dit wordt genoemd zero-knowledge architectuur.
Wat maakt Worklist anders.
Traditionele taakmanagers.
Wat concurrenten doen
- • Slaan uw gegevens in leesbare tekst op hun servers op
- • Kan elke taak, opmerking en bestand lezen dat u maakt
- • Kan uw inhoud scannen op advertenties, AI-training of ‘functies’
- • Kwetsbaar voor datalekken waardoor alles bloot komt te liggen
Worklist (zero-knowledge).
Wat wij doen
- • Versleutelt op uw apparaat voordat het naar onze servers wordt verzonden
- • We kunnen uw taken niet ontsleutelen, zelfs als we dat zouden willen
- • Geen scannen, geen AI-training op uw privéwerk
- • Datalekken onthullen niets betekenisvols: alleen versleutelde blobs
Hoe zero-knowledge-versleuteling werkt.
U maakt uw account aan.
Wanneer u zich registreert, verlaat uw wachtwoord uw browser nooit in platte tekst. In plaats daarvan:
- Wij gebruiken het OPAQUE PAKE-protocol zodat onze servers uw wachtwoord in platte tekst nooit zien
- Na succesvolle registratie of aanmelding geeft OPAQUE uw browser een geheime exportkey die wij nooit ontvangen
- Er wordt een willekeurige ‘datasleutel’ van 32 bytes op uw apparaat gegenereerd
- Deze gegevenssleutel wordt lokaal versleuteld met een verpakkingssleutel die van die OPAQUE-exportkey is afgeleid
- De versleutelde gegevenssleutel wordt opgeslagen op onze servers, maar we kunnen hem niet ontsleutelen zonder het client-side ontgrendelingsmateriaal
- U kunt een eenmalige reservesleutel downloaden. Die verpakt dezelfde gegevenssleutel in uw browser; wij bewaren alleen een versleutelde herstelverpakking
Belangrijk punt: de ontgrendelingssleutel en gegevenssleutel worden in uw browser verwerkt. Wij bewaren alleen versleutelde verpakkingen, nooit platte wachtwoorden of workspace-sleutels.
Waarom de versleutelde gegevenssleutel opslaan?
Zo kunt u vanaf elk apparaat inloggen. Wanneer u van computer wisselt of uw telefoon gebruikt, sturen we de versleutelde blob, uw browser ontgrendelt die lokaal na veilige aanmelding en u bent weer binnen. Zonder dit op te slaan zou u handmatig een sleutel van 32 bytes tussen apparaten moeten kopiëren - een slechte gebruikerservaring voor dezelfde beveiliging.
U maakt een werklijst of taak.
Elk stukje gevoelige gegevens wordt versleuteld op uw apparaat:
- Titels, beschrijvingen en instellingen van werklijsten
- Taaktitels, hoofdteksten, checklists en opmerkingen
- Herhalende taaksjablonen en schema's
- Alles is versleuteld met behulp van ChaCha20-Poly1305 AEAD (een modern, gecontroleerd cijfer)
- Elke werklijst heeft zijn eigen unieke versleutelingssleutel, afgeleid van uw gegevenssleutel
Onze servers slaan alleen de versleutelde cijfertekst — ze kunnen de leesbare tekst niet lezen.
U nodigt teamleden uit.
Bij het delen van werklijsten met teamgenoten:
- Elk lid krijgt zijn eigen versleutelde kopie van de werklijstsleutel
- Sleutels worden uitgewisseld via HPKE (Hybride openbare sleutelversleuteling)
- Publieke sleutels worden gepubliceerd naar een transparantielogboek (Merkle-boom) om man-in-the-middle-aanvallen te voorkomen
- Als u een lid verwijdert, wordt de werklijstsleutel gerouleerd en krijgen alle overige leden nieuwe versleutelde kopieën
Onze servers verifiëren zonder te ontsleutelen.
U vraagt zich misschien af: “Als de server niet kan ontsleutelen, hoe kan hij dan de rechten afdwingen?”
We gebruiken HMAC-bewijzen: cryptografische handtekeningen die bewijzen dat u recht heeft op toegang tot gegevens zonder de platte tekst te onthullen.
- Uw browser berekent een HMAC (keyed hash) van de versleutelde gegevens met behulp van een lidmaatschapsspecifieke sleutel
- De server valideert de HMAC om te bevestigen dat u een actief lid bent
- Het knoeien of afspelen van de gegevens van iemand anders mislukt de HMAC-controle
- We ontsleutelen de payload nooit; we verifiëren alleen de integriteit en autorisatie
Wat onze servers wel en niet kunnen zien.
Wij KUNNEN NIET zien
- × Titels of beschrijvingen van werklijsten
- × Taaktitels, hoofdteksten of checklists
- × Opmerkingen of discussies
- × Sjablonen voor herhalende taken
- × Alle inhoud binnen versleutelde payloads
- × Uw wachtwoord (zelfs gehasht)
Wij KUNNEN zien
- ✓ E-mailadres van gebruikersaccount (voor inloggen)
- ✓ Lidmaatschapsrelaties (wie staat in welke werklijst)
- ✓ Taakstatus (open/gesloten) en prioriteit
- ✓ Vervaldata en tijdstempels
- ✓ Delegatietoewijzingen (alleen gebruikers-ID's)
- ✓ Metagegevens die nodig zijn voor zoekopdrachten (ID's, aanmaakdatums)
Waarom sommige metadata zichtbaar zijn: Bepaalde velden (zoals taakstatus en vervaldatums) moeten in leesbare tekst worden opgeslagen, zodat onze servers zoekopdrachten efficiënt kunnen filteren, herinneringen aan vervaldatums kunnen afdwingen en database-indexen kunnen onderhouden. Deze velden bevatten geen gevoelige inhoud, maar alleen operationele metagegevens waarmee de app kan functioneren.
Beveiliging garanties.
Met wachtwoord geverifieerde ontgrendeling (alleen client-side).
Uw wachtwoord verlaat uw apparaat nooit in leesbare tekst. Succesvolle OPAQUE-verificatie geeft uw browser een exportkey die uw gegevenssleutel lokaal uitpakt. Die gegevenssleutel wordt vervolgens uitgebreid met behulp van HKDF om voor elke werklijst afzonderlijke sleutels af te leiden.
De server kan de payloads niet ontsleutelen.
Onze backend-code roept nooit ontsleutelingsbewerkingen op gebruikersgegevens op. Het valideert alleen HMAC-bewijzen om de autorisatie te bevestigen.
Sleutelroulatie bij ledenwijzigingen.
Wanneer een lid wordt verwijderd of vertrekt, wordt de werklijstsleutel gerouleerd. Alle overige leden ontvangen nieuwe versleutelde kopieën, zodat het vertrekkende lid toekomstige inhoud niet kan ontsleutelen.
Transparantie van uitnodigingssleutels.
Openbare sleutels voor uitnodigingen worden vastgelegd in een Merkle-boom die alleen kan worden toegevoegd. Clients verifiëren insluitings- en consistentiebewijzen, waardoor wordt voorkomen dat de server stilletjes sleutels vervangt om werklijstgegevens te onderscheppen.
Reservesleutels blijven zero-knowledge.
Een reservesleutel wordt in uw browser gegenereerd en moet door u worden bewaard. Hij maakt een aparte versleutelde verpakking voor dezelfde gegevenssleutel; wij bewaren alleen het herstelcredentialbestand en de versleutelde verpakking, zodat we zonder die bewaarde sleutel uw wachtwoord niet kunnen resetten en uw gegevens niet kunnen lezen.
Open source-cryptografie.
We gebruiken beproefde bibliotheken: strong-box (ChaCha20-Poly1305), OPAQUE (wachtwoordauthenticatie), HKDF (sleutelafleiding), Argon2id (OPAQUE-wachtwoordverharding en legacy-migratie) en HPKE (sleuteluitwisseling). Al onze cryptocode is open source en controleerbaar.
Hoe we verifiëren onze veiligheid.
Onze beveiligingsclaims zijn verifieerbaar, niet alleen marketing. Zo zorgen we ervoor dat onze zero-knowledge-architectuur werkt zoals beloofd:
- Open-source cryptografische code beschikbaar op GitHub voor openbare audits door beveiligingsonderzoekers
- In de praktijk geteste bibliotheken, waaronder ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9497) en HPKE
- Cryptografische bewijzen (HMAC) die ontsleuteling op de server wiskundig voorkomen
- Transparantielogboeken (Merkle-bomen) om sleutelvervangingsaanvallen te detecteren
- Client-side ontgrendeling vanuit OPAQUE-exportkeys zorgt ervoor dat we uw wachtwoord of versleutelingssleutels nooit zien
- Eenmalige reservesleutels worden door de gebruiker gegenereerd en bewaard, nooit door Worklist
Afwegingen van zero-knowledge.
Een reservesleutel kan toegang herstellen als u uw wachtwoord kwijtraakt.
Bewaar een reservesleutel eenmaal en houd hem privé. Als u uw wachtwoord kwijtraakt, kunt u met die sleutel het wachtwoord opnieuw instellen en toegang houden tot versleutelde gegevens. Omdat Worklist geen kopie bewaart, blijven accounts zonder bewaarde reservesleutel onherstelbaar.
Geen zoekopdracht op de server.
Omdat uw taakinhoud versleuteld is, kunnen we niet voor al uw taken op de server full-text zoeken. Zoeken gebeurt in uw browser na ontsleuteling.
Beperking: we optimaliseren zoeken aan de clientzijde met geïndexeerde zoekopdrachten en snelle ontsleuteling om de prestaties te behouden.
Technisch specificaties.
| Symmetrische versleuteling | ChaCha20-Poly1305 AEAD (via de strong-box-bibliotheek) |
| Gegevenssleutel ontgrendelen | OPAQUE-exportkey + HKDF-SHA256 — leidt lokale verpakkingssleutels af voor de versleutelde gegevenssleutel |
| Sleutelhiërarchie | HKDF-SHA256 — leidt werklijst- en lidmaatschapssleutels af van de gegevenssleutel |
| Wachtwoordverificatie | OPAQUE PAKE (Ristretto255 curve) |
| Reservesleutels | Een actieve eenmalige reservesleutel per gebruiker; client-side gegenereerd en door de gebruiker bewaard |
| Sleuteluitwisseling (uitnodigingen) | HPKE (Hybrid Public Key Encryption) met X25519 |
| Integriteitsbewijzen | HMAC-SHA256 |
| Serialisatie | CBOR (Concise Binary Object Representation) |
| Sleutelgrootte | 256-bit (32 bytes) voor alle symmetrische sleutels |
Alle cryptografische bewerkingen gebeuren in uw browser met behulp van WebCrypto API's en gecontroleerde WASM-modules samengesteld uit Rust.
Audits & transparantie.
Open source crypto-stack.
Onze gehele cryptografische implementatie is open source en beschikbaar op GitHub. We verwelkomen beveiligingsonderzoekers om onze code te controleren.
Bekijk op GitHubNaleving.
Onze zero-knowledge-architectuur ondersteunt AVG-dataminimalisatie en kan helpen met HIPAA- of SOC 2-technische beveiligingen. Voor gereguleerde PHI is nog steeds een schriftelijke overeenkomst of BAA vereist, plus de operationele controles en leveranciersbevestiging die uw nalevingsprogramma vereist.
Algemeen vragen.
Wat gebeurt er als u wordt gehackt?
Als een aanvaller toegang krijgt tot onze database, ziet hij alleen versleutelde blobs, in wezen willekeurige bytes. Zonder de ontgrendeling die met uw wachtwoord is geverifieerd of een bewaarde reservesleutel zijn de gegevens wiskundig gezien onmogelijk te ontsleutelen met de huidige technologie.
Kunnen overheidsinstanties u dwingen mijn gegevens te ontsleutelen?
Nee, want dat kunnen we echt niet. We hebben de sleutels niet. Zelfs met een bevelschrift of gerechtelijk bevel kunnen we alleen de versleutelde cijferteksten verstrekken, die zonder de ontgrendeling die met uw wachtwoord is geverifieerd of een door u bewaarde reservesleutel nutteloos zijn.
Wat als ik mijn wachtwoord vergeet?
Als u een reservesleutel hebt bewaard, kunt u die eenmaal gebruiken om uw wachtwoord opnieuw in te stellen en toegang tot uw versleutelde gegevens te behouden. Zonder bewaarde reservesleutel kan Worklist de gegevens niet voor u herstellen.
Hoe verschilt dit van “versleuteling voor opgeslagen gegevens”?
‘Versleuteld voor opgeslagen gegevens’ betekent dat gegevens op de harde schijven van de server worden versleuteld, maar dat de server nog steeds over sleutels kan beschikken om ze te ontsleutelen. End-to-end-versleuteling betekent dat alleen u (de eindpunten) de sleutels heeft; de server heeft nooit toegang tot platte tekst.
Kunnen medewerkers van Worklist mijn gegevens inzien?
Nee. Onze backend-code is ontworpen om nooit de payloads van gebruikers te ontsleutelen. Zelfs databasebeheerders met volledige toegang tot onze servers kunnen uw werklijsten of taken niet lezen.
Wat moet ik doen als ik mijn gegevens wil exporteren?
U kunt uw ontsleutelde gegevens op elk gewenst moment vanuit de app exporteren. Omdat de ontsleuteling in uw browser plaatsvindt, krijgt u leesbare JSON/CSV-bestanden en geen versleutelde blobs.
Referenties & normen.
Onze cryptografische keuzes volgen industriestandaarden en peer-reviewed specificaties.
- 01 RFC 8439: ChaCha20 en Poly1305 voor IETF-protocollen — Onze symmetrische encryptiestandaard
- 02 RFC 9497: OPAQUE Asymmetrisch PAKE-protocol — Zero-knowledge-wachtwoordverificatie
- 03 RFC 9180: Hybride publieke sleutelversleuteling (HPKE) — Sleuteluitwisseling voor teamuitnodigingen
- 04 RFC 9106: Argon2 Memory-Hard-functie — Op wachtwoord gebaseerde sleutelafleiding
- 05 NIST SP 800-175B: Richtlijn voor het gebruik van cryptografische standaarden — Federale cryptografische begeleiding
- 06 AVG Artikel 32: Beveiliging van de verwerking — EU-vereisten voor gegevensbescherming
Klaar voor echte privacy?
Sluit u aan bij teams die erop vertrouwen dat Worklist hun werk echt privé houdt. Start uw gratis proefperiode – geen creditcard vereist.
Gratis proefperiode startenHeeft u beveiligingsvragen? E-mail ons op security@worklist.app