Naar de inhoud

Beveiliging

Beveiligingsarchitectuur en dreigingsmodel

Notenz gebruikt twee fundamenteel verschillende versleutelingsniveaus. Normale kluisitems worden aan de serverkant versleuteld, zodat we ze automatisch kunnen afleveren. De Verzegelde kluis en Gedeelde-sleutel items van Guardian worden volledig in uw browser versleuteld: wij hebben de sleutel nooit in handen. Deze pagina legt precies uit wat elk niveau doet, wat we wel en niet kunnen lezen, en waar de eerlijke grenzen liggen.

De korte versie, in gewone taal

  • 🔐 Uw notities worden versleuteld op het moment dat ze ons bereiken. We bewaren versleutelde gegevens, geen leesbare tekst. Onze medewerkers lezen die niet.
  • 🔑 Uw ontvangers kunnen die alleen lezen wanneer uw kluis wordt uitgevoerd. Niet eerder.
  • 🤔 Zou Notenz die technisch kunnen ontgrendelen? Voor de standaardkluis, ja: wij hebben de sleutel die nodig is om die automatisch af te leveren als u dat niet kunt. Lees waarom, en hoe de Verzegelde kluis anders is →
  • 🌐 Uw verbinding is altijd beveiligd. Net als bij internetbankieren staat het slotje in uw browser altijd aan.
  • 🪪 Uw wachtwoord wordt nooit als zodanig bewaard. We bewaren een eenrichtings wiskundige vingerafdruk ervan. Zelfs als onze database zou worden gestolen, blijft uw wachtwoord veilig.
  • 🚨 Een probleem gevonden? Mail [email protected] en dan lossen we het snel op.

Versleutelingsmodel met twee niveaus

Niveau 1: normale kluisitems

Alle Gratis-, Pro- en Guardian-items die geen Verzegelde kluis of Gedeelde-sleutel zijn. Dit dekt het merendeel van de kluisinhoud.

  • Tekstnotities: Fernet (AES-128-CBC + HMAC-SHA256), aan de serverkant
  • Bestanden: AES-256-GCM, streaming in stukken, aan de serverkant
  • Sleutel in handen van: Notenz (nodig voor automatische aflevering)
Notenz kan deze items technisch ontsleutelen. We hebben die mogelijkheid nodig om ze automatisch af te leveren wanneer u stopt met inchecken.

Niveau 2: zero-knowledge (alleen Guardian)

Verzegelde kluis (Privégeheimen) en Gedeelde-sleutel kluisitems. Volledig in uw browser versleuteld voordat ze worden geüpload.

  • Verzegelde kluis: PBKDF2-SHA256, 600.000 iteraties, AES-256-GCM
  • Gedeelde-sleutel / wachtzin per item: PBKDF2-SHA256, 100.000 iteraties, AES-256-GCM
  • Sleutel in handen van: Alleen u. Notenz bewaart uitsluitend versleutelde tekst.
Notenz kan deze items niet lezen. Zelfs een volledige inbraak op de server legt hun leesbare inhoud niet bloot. Nadeel: een vergeten sleutel betekent definitief verlies.

Wat Notenz wel en niet kan zien

Notenz kan lezen

  • Titels van items (onversleuteld bewaard om u te helpen ordenen)
  • Inhoud van normale kluisitems (sleutel aan de serverkant; nodig voor aflevering)
  • Normale kluisbestanden (ontsleuteld op het moment van aflevering)
  • Uw e-mailadres, check-inschema en lijst met ontvangers
  • Metagegevens: wanneer items zijn aangemaakt, geopend, afgeleverd

Notenz kan niet lezen

  • Geheimen in de Verzegelde kluis (sleutel aan de kant van de gebruiker, nooit verzonden)
  • Inhoud van Gedeelde-sleutel kluisitems (sleutel aan de kant van de gebruiker, nooit verzonden)
  • Inhoud die per item met een wachtzin is versleuteld (sleutel aan de kant van de gebruiker)
  • Uw accountwachtwoord (alleen bewaard als PBKDF2-SHA256-hash)
  • Tweefactorcodes (alleen bewaard als HMAC-SHA256-samenvatting)

Dreigingsmodel: waartegen we wel en niet beschermen

We beschermen tegen

  • ✓ Alleen diefstal van de database: alle inhoud is versleuteld in rust; gestolen databaseregels zijn zinloos zonder de hoofdsleutel
  • ✓ Inbraak op de server voor items van niveau 2: de versleutelde tekst van de Verzegelde kluis en Gedeelde-sleutel kan niet worden ontsleuteld, zelfs met volledige toegang tot de server, omdat de sleutel onze servers nooit bereikt
  • ✓ Onbedoelde toegang door medewerkers: er bestaat geen intern hulpmiddel om kluisinhoud te doorzoeken
  • ✓ Brute-force op accountwachtwoorden: PBKDF2-SHA256-stretching, inloggen met snelheidsbeperking
  • ✓ Raden van tokens: alle openbare links hebben een snelheidsbeperking en zijn cryptografisch willekeurig
  • ✓ Sessievastlegging en CSRF: CSRF-tokens op alle eindpunten die iets wijzigen, beveiligde HttpOnly-cookies

We beschermen NIET tegen (eerlijke beperkingen)

  • ✗ Volledige inbraak op een actieve server (niveau 1): een aanvaller met toegang tot zowel de database als de hoofdsleutel kan normale kluisitems ontsleutelen. We beperken dit met de mogelijkheid tot sleutelrotatie, maar het blijft een theoretisch risico.
  • ✗ Normale kluisitems zijn niet end-to-end versleuteld naar ontvangers: ze worden door onze server ontsleuteld en per e-mail verstuurd. TLS beschermt de e-mail tijdens het verzenden, maar wij zien de leesbare tekst op het moment van aflevering.
  • ✗ Inbraak op het apparaat: als uw apparaat is gecompromitteerd, kan een wachtzin van niveau 2 die u in uw browser invoert, worden onderschept voordat er wordt versleuteld. Geen enkele maatregel aan de serverkant kan dit voorkomen.
  • ✗ Vergeten wachtzin van niveau 2: items in de Verzegelde kluis en Gedeelde-sleutel items worden definitief onherstelbaar. Er is geen manier om ze aan de serverkant opnieuw in te stellen.
  • ✗ Metagegevens: zelfs voor items van niveau 2 bewaren we labels (titels), tijdstippen en afleveradressen. Niveau 2 verbergt de inhoud, niet het bestaan van een item.
  • ✗ Notenz is niet ISO 27001-gecertificeerd. We worden gehost op DigitalOcean, dat als aanbieder van cloudinfrastructuur wel ISO/IEC 27001:2013-certificering heeft.

Versleuteling in rust

Tekstnotities worden aan de serverkant versleuteld met Fernet (AES-128-CBC + HMAC-SHA256) voordat ze worden opgeslagen. Bestanden gebruiken streaming AES-256-GCM (stukken van 4 MB, een unieke nonce per stuk). De hoofdsleutel wordt apart van de inhoud bewaard; alleen een gestolen database levert enkel versleutelde tekst op.

  • ✓ Tekstnotities: Fernet (AES-128-CBC + HMAC-SHA256), sleutel aan de serverkant
  • ✓ Bestanden: AES-256-GCM streaming (unieke nonce van 12 bytes per stuk), sleutel aan de serverkant
  • ✓ Hoofdsleutel apart van de database bewaard; hulpmiddel voor sleutelrotatie beschikbaar
  • ✓ Leesbare tekst wordt nooit naar schijf of logbestanden geschreven

We lezen uw inhoud niet

Uw notities en bestanden worden versleuteld voordat ze worden opgeslagen. In de normale dagelijkse gang van zaken bekijkt, doorzoekt of leest niemand bij Notenz de leesbare tekst van wat u heeft geschreven, en is daar ook geen hulpmiddel voor. Titels worden onversleuteld bewaard (om u te helpen ordenen), maar de inhoud is altijd versleuteld. Automatische processen ontsleutelen de inhoud alleen om uw kluis af te leveren wanneer het tijd is: zie hieronder voor het volledige beeld.

  • ✓ Geen leesbare tekst in de logbestanden van de applicatie
  • ✓ Geen leesbare tekst in databaseback-ups
  • ✓ Geen hulpmiddel voor medewerkers om kluisinhoud te doorzoeken

Twee-persoons geheim (gesplitste aflevering)

Voor extra gevoelige items kunt u kiezen voor onze modus Twee-persoons geheim. Wanneer uw kluis wordt uitgevoerd, wordt het geheim wiskundig gesplitst in een apart deel voor elk van uw gekozen ontvangers (2 of meer), met een gevestigde techniek voor het delen van geheimen. Elke 2 van die delen volstaan om het originele bericht te reconstrueren, maar één enkel deel onthult er op zichzelf absoluut niets over.

  • ✓ Cryptografisch onmogelijk om met slechts één deel te lezen
  • ✓ Elke 2 van de N delen reconstrueren het geheim. Zelfs als u het contact met één vertrouwd contact verliest, kunnen elke 2 van de anderen het nog steeds ontgrendelen
  • ✓ Delen worden na het genereren nooit samen bewaard

Tekstnotities

De notitietekst zelf wordt over uw ontvangers verdeeld. Elke 2 van hen plakken hun delen in notenz.com/reconstruct/, en het originele bericht wordt volledig in hun browser opnieuw opgebouwd. Er wordt niets teruggestuurd naar Notenz.

  • ✓ De reconstructie gebeurt 100% aan de kant van de gebruiker, zonder tussenkomst van de server
  • ✓ Notenz heeft de gereconstrueerde leesbare tekst nooit in handen

Bestanden

Voor bestanden splitst Notenz de toegang tot het bestand, niet het bestand zelf. Een korte willekeurige toegangscode wordt met hetzelfde schema over uw ontvangers verdeeld. Wanneer elke 2 van hen hun delen op de reconstructiepagina samenvoegen, gebruikt de browser de samengestelde code om het bestand op te vragen. Notenz ontsleutelt het aan de serverkant en streamt het als een directe download. Geen enkel deel kan op zichzelf de code opleveren.

  • ✓ Alleen de toegangscode wordt gesplitst. Er wordt geen binair bestand per e-mail verstuurd
  • ✓ Bestand bewaard met AES-256-GCM versleuteling in rust; alleen ontsleuteld op het moment van downloaden
  • ✓ Downloadlink 90 dagen geldig; verloopt daarna automatisch

Eerlijke beperking, voor de transparantie

Anders dan bij Gedeelde-sleutel items, heeft Notenz de inhoud van uw Twee-persoons geheim wel in handen: we bewaren de gesplitste delen zelf totdat uw kluis wordt uitgevoerd, zodat we ze kunnen samenvoegen en afleveren. Dat betekent dat het niet zero-knowledge is, en dat een export van uw persoonsgegevens (Instellingen → Mijn gegevens exporteren) deze inhoud in leesbare vorm bevat. Heeft u een garantie nodig dat zelfs Notenz de inhoud niet kan lezen? Gebruik dan in plaats daarvan een Gedeelde-sleutel kluisitem.

Bescherming voor gedeelde links

Afleverlinks, links naar delen van gesplitste geheimen, bevestigingslinks van ontvangers en terughaallinks zijn allemaal beschermd tegen automatisch raden en misbruik. Als één link een ongebruikelijk hoog aantal aanvragen van dezelfde bron ontvangt, worden verdere aanvragen tijdelijk geblokkeerd en wordt de eigenaar van de kluis per e-mail op de hoogte gebracht, zodat ze het activiteitenoverzicht van hun account kunnen bekijken.

  • ✓ Snelheidsbeperking op alle openbare links op basis van tokens (aflever-, gesplitst-geheim-, bevestigings- en terughaalpagina's)
  • ✓ De eigenaar van de kluis krijgt een eenmalige e-mailmelding de eerste keer dat een aflever- of gesplitst-geheim-link wordt geopend
  • ✓ Verdachte activiteit wordt vastgelegd in het activiteitenoverzicht van uw account

Eerlijk antwoord: zou Notenz mijn kluis kunnen lezen?

Voor uw standaardkluis (Gratis-, Pro- en Guardian-items buiten de Verzegelde kluis): technisch gezien, ja. Dit is waarom, in gewone taal.

De hele taak van Notenz is om uw kluis automatisch af te leveren als u stopt met inchecken, zelfs als u zelf geen wachtwoord meer kunt typen. Om dat te laten werken, moet ons systeem uw kluis op eigen houtje kunnen ontgrendelen, zonder u. Daarom bewaren we een hoofdsleutel die dat kan.

That means: if someone broke into a stolen database backup alone, they'd find nothing but scrambled bytes: useless without the key. But if someone fully broke into our live servers (not just the database), they could, in theory, get the key too and unlock your vault. We guard hard against that (separate storage for the key, no staff access, encrypted backups, and we're rolling out key-rotation tooling so a leaked key can be replaced quickly), but it's an honest limit, not a guarantee of "nobody, ever, under any circumstances."

Wilt u een kluis die zelfs Notenz nooit kan openen, punt uit? Gebruik Verzegelde kluis (Guardian). Die wordt in uw browser versleuteld met uw wachtwoord. Wij hebben de sleutel nooit, punt uit. Het nadeel: die kan niet automatisch worden afgeleverd, en als u uw wachtwoord vergeet, is die voorgoed weg.

Wilt u diezelfde garantie dat "Notenz die nooit kan openen", maar moet het item toch bij een ontvanger worden afgeleverd? Gebruik een Gedeelde-sleutel kluisitem (Guardian). U genereert uw eigen sleutel in uw browser, Notenz ziet die nooit, en het item wordt nog steeds gewoon bij uw ontvanger afgeleverd, maar alleen u kunt hun de sleutel geven om het te openen.

Verzegelde kluis: zero-knowledge versleuteling

Guardian

Items in de Verzegelde kluis worden volledig in uw browser versleuteld voordat ze worden geüpload. De servers van Notenz bewaren alleen versleutelde tekst: nooit uw leesbare geheimen, nooit uw versleutelingssleutel. Zelfs een volledige inbraak op de database van Notenz legt niets leesbaars bloot.

Technische specificatie

  • ✓ Sleutelafleiding: PBKDF2-SHA256, 600.000 iteraties
  • ✓ Versleuteling: AES-GCM 256-bits
  • ✓ IV: Willekeurige 12 bytes per geheim, nooit hergebruikt
  • ✓ Auth-tag: De AES-GCM-authenticatietag detecteert manipulatie en verkeerde wachtwoorden
  • ✓ Uitvoering: Alle cryptografie draait in uw browser via de Web Crypto API, zodat sleutels uw apparaat nooit verlaten

Belangrijke beperking

De Verzegelde kluis heeft uw Notenz-wachtwoord nodig om te ontsleutelen. Als u uw Notenz-wachtwoord vergeet, kunnen de geheimen in uw kluis niet worden hersteld. Dat is met opzet zo: er is geen achterdeur aan de serverkant.

Wilt u dat de Verzegelde kluis een reset van het accountwachtwoord overleeft?

By default, Sealed Vault uses your normal Notenz login password. If you ever reset that password (e.g. via "forgot password"), your existing Sealed Vault secrets become unreadable, because they were encrypted with the old password.

Om dit te voorkomen, kunt u een apart wachtwoord voor de Verzegelde kluis inschakelen op de pagina van de Verzegelde kluis: een tweede wachtwoord dat alleen wordt gebruikt om uw meest gevoelige geheimen te ontgrendelen, volledig los van uw accountlogin. Het opnieuw instellen van uw accountwachtwoord heeft er dan geen invloed meer op.

Dezelfde regel geldt, alleen nog sterker: als u dit aparte wachtwoord vergeet, kan Notenz de geheimen in uw Verzegelde kluis niet herstellen, punt uit. Er is geen link om opnieuw in te stellen, geen omzeiling door support, en geen enkele manier waarop wij kunnen helpen. Schrijf het ergens veilig op voordat u dit inschakelt.

Iemand anders er later toegang toe geven

De Verzegelde kluis wordt bij uitvoering van de kluis nooit automatisch afgeleverd. Om een vertrouwd persoon er uiteindelijk in te laten, geeft u ze zelf twee aparte dingen, buiten Notenz om: toegang tot uw Notenz-accountlogin, en uw wachtwoord voor de Verzegelde kluis.

Houd deze twee gescheiden (bijvoorbeeld de accountgegevens bij een executeur, het wachtwoord van de Verzegelde kluis in een verzegelde brief of bij een advocaat): wie beide heeft, kan het ontgrendelen; wie er maar één heeft, kan dat niet.

Gedeelde-sleutel kluisitem: end-to-end versleuteling die toch wordt afgeleverd

Guardian

De Verzegelde kluis geeft u de garantie dat "Notenz dit nooit kan lezen", maar die kan aan niemand worden afgeleverd. Die is alleen voor u. Een Gedeelde-sleutel kluisitem geeft u diezelfde garantie voor een item dat u wel wilt laten afleveren bij een ontvanger.

Wanneer u dit soort item toevoegt, genereert uw browser een willekeurige geheime sleutel en gebruikt die om uw notitie of bestand te versleutelen voordat het ooit naar Notenz wordt gestuurd. Wij bewaren alleen de versleutelde versie. Wij zien, bewaren of hebben op geen enkele manier toegang tot uw sleutel om die te reconstrueren. Wanneer uw kluis wordt uitgevoerd, ontvangt uw ontvanger dit item net als elk ander, plus een eenvoudige ontgrendelpagina die in de afleverlink is ingebouwd. Om het te openen, plakken ze de sleutel.

  • ✓ In uw browser versleuteld voordat het ooit Notenz bereikt: wij bewaren alleen de afgesloten versie
  • ✓ Toch automatisch bij uw ontvanger afgeleverd wanneer uw kluis wordt uitgevoerd, net als andere items
  • ✓ Ontvanger krijgt een ingebouwde ontgrendelpagina op de afleverlink waar ze de sleutel invoeren om het te lezen of te downloaden

U moet de sleutel zelf overhandigen: lees dit alstublieft zorgvuldig

Notenz heeft deze sleutel nooit. Dat is precies de bedoeling, maar het betekent ook dat het bij uw ontvanger krijgen van de sleutel volledig uw taak is, niet die van ons. Stuur die naar ze op de manier waarop u iets gevoeligs zou delen: persoonlijk, via een telefoongesprek, via een end-to-end versleutelde chatapp zoals Signal, overal behalve door die naast het item zelf te laten liggen.

Als u de sleutel verliest, of er nooit aan toekomt om die te delen, ontvangt uw ontvanger het item nog steeds wanneer uw kluis wordt uitgevoerd, maar kunnen ze het nooit openen. De gegevens erin zitten voorgoed op slot. Notenz kan die niet herstellen, opnieuw instellen of een vervangende sleutel genereren. Er is geen supportproces dat dit kan oplossen.

Gebruik dit voor het handjevol dingen die zowel maximale geheimhouding als aflevering nodig hebben. Voor al het andere is de standaardkluis (die we automatisch kunnen afleveren, zelfs als u de toegang tot alles verliest) de veiligere keuze voor dagelijks gebruik.

Versleuteling per item met een wachtzin

Guardian

Guardian-gebruikers kunnen elk kluisitem beschermen met een gemakkelijk te onthouden wachtzin van 4 woorden die in de browser wordt gegenereerd (technisch gezien: Web Crypto PBKDF2, 100.000 iteraties, SHA-256, AES-256-GCM). De zin wordt nooit naar de servers van Notenz verzonden. Ontvangers voeren die in op de afleverlink om de inhoud aan de kant van de gebruiker te ontsleutelen. Dit werkt los van of in combinatie met het Twee-persoons geheim (Shamir-verdeling: splitst de sleutel zodat 2 vertrouwde mensen het samen moeten ontgrendelen).

Als Notenz ooit verdwijnt

Zero-knowledge versleuteling betekent dat Notenz uw sleutels nooit in handen heeft, wat ook betekent dat Notenz niet nodig is om uw inhoud te ontsleutelen: alleen de wachtzin en de standaardcryptografie zijn dat. We publiceren een losstaande offline ontsleutelingstool die volledig draait in een opgeslagen browserpagina, zonder server, zonder inloggen en zonder externe aanvragen. Sla nu een kopie op: die blijft met uw wachtzin werken, zelfs als de servers van Notenz onbereikbaar zijn.

Transport en infrastructuur

Al het verkeer tussen uw browser en onze servers wordt tijdens het verzenden versleuteld met TLS (HTTPS). We gebruiken CSRF-bescherming op alle eindpunten die iets wijzigen. Sessiecookies zijn gemarkeerd als HttpOnly en Secure.

  • ✓ Alleen TLS/HTTPS; HTTP wordt omgeleid naar HTTPS
  • ✓ CSRF-tokens op alle POST/DELETE-eindpunten
  • ✓ HttpOnly + Secure sessiecookies
  • ✓ Gehost op DigitalOcean, een aanbieder van cloudinfrastructuur met ISO/IEC 27001:2013-certificering. Notenz zelf is niet ISO 27001-gecertificeerd.
  • ✓ Datacentrum in de EU-regio

Inloggen en authenticatie

Wachtwoorden worden gehasht met PBKDF2-SHA256 (standaard van Django). Tweefactorauthenticatie (2FA) via een eenmalige code per e-mail staat standaard aan voor alle accounts. Guardian-accounts kunnen die niet uitschakelen.

  • ✓ PBKDF2-SHA256 wachtwoordhashing (standaard van Django, industriestandaard)
  • ✓ E-mail-2FA staat standaard aan voor alle abonnementsniveaus
  • ✓ Guardian-abonnement: 2FA is verplicht en kan niet worden uitgeschakeld
  • ✓ 2FA-codes bewaard als HMAC-SHA256-samenvatting, niet de ruwe code
  • ✓ OTP-codes verlopen na 5 minuten
  • ✓ 2FA-verificatie vereist (in de huidige sessie) voordat 2FA kan worden uitgeschakeld
  • ✓ Snelheidsbeperking: maximaal 5 verificatiepogingen per 10 minuten

Een beveiligingsprobleem gevonden?

We nemen beveiligingsmeldingen serieus. Heeft u een kwetsbaarheid gevonden? Mail ons dan op [email protected]. We reageren binnen 48 uur en werken met u samen om het probleem op te lossen. We hebben nog geen formeel bug-bountyprogramma, maar we waarderen verantwoorde openbaarmaking enorm.