Hoe TOTP-geheimen werken (en waarom je ze niet moet delen)

Een TOTP-geheim is een willekeurige tekenreeks van 16 tot 32 base32-tekens, die de aanbieder één keer maakt en nooit wijzigt. Het wordt niet afgeleid uit je wachtwoord, het is aan geen toestel gebonden, en het heeft geen vervaldatum. Elke kopie maakt voor altijd geldige codes, en niets in het account kan je zeggen hoeveel kopieën er bestaan.

Dat is het hele dossier tegen het delen ervan. Elk van die stellingen verdient uitwerking, en daar komt bij wat je doet met een account waarvan het geheim al is rondgegaan, aangezien de vraag bijna altijd te laat komt.

Wat een geheim precies is

De werking die van een geheim zes cijfers maakt, staat in de volledige gids over TOTP in teams. Wat hier telt is wat het geheim als voorwerp is.

Het is symmetrisch. Beide kanten hebben dezelfde waarde. Er is geen publieke helft: er is dus niets dat je zonder risico kunt uitdelen.

Het heeft veel entropie en laat zich niet raden. 80 tot 160 bits willekeur. Geen enkele praktische aanval bestaat eruit het te berekenen, en precies daarom is elk echt incident een kopie.

Het heeft geen levenscyclus. Geen vervaldatum, geen versie, geen intrekkingslijst, geen rotatie. Het protocol heeft geen woordenschat voor „deze kopie is niet meer geldig”, alleen voor „dit geheim is niet meer op het account ingesteld”.

Het staat los van het wachtwoord. Het ene resetten doet niets met het andere. Teams wijzigen wachtwoorden na een vertrek en laten de tweede factor staan, wat de verkeerde helft is als het geheim heeft gereisd.

De plekken waar een kopie belandt

Deze lijst verdient het langzaam gelezen te worden. Het argument tegen delen is niet dat één kopie gevaarlijk is, maar dat de kopieën zich opstapelen waar niemand kijkt.

• De database van de aanbieder, op zijn plek.
• De authenticator-app van iedereen die de QR-code scande.
• De toestelback-up van elk van die telefoons, waar die ook leeft.
• De cloudsynchronisatie van de apps die haar aanbieden, dus de meeste vandaag.
• De schermafbeelding die tijdens de installatie is gemaakt, in een filmrol die zelf gesynchroniseerd wordt.
• Het chatbericht waarin het is gepost, plus de zoekindex en de bewaartermijn van dat platform.
• De gedeelde kluisvermelding, ooit geëxporteerd naar een bestand dat niemand heeft verwijderd.
• De omgevingsvariabele op een CI-runner of server, als een automaat inlogt.

Twee dingen gelden voor alle punten na het eerste. Geen enkele verschijnt ergens in de beveiligingsinstellingen van het account, en geen enkele wordt verwijderd door een handeling die je binnen het account kunt doen.

Waarom „we hebben het maar één keer gedeeld” nooit één keer is

Een eenmaal gedeeld geheim blijft niet op één plek, omdat de systemen waarin het belandt zijn ontworpen om dingen te kopiëren.

Een telefoon wordt geback-upt en daarna teruggezet op zijn vervanger. Een authenticator-app voegt bij een update cloudsynchronisatie toe, en het geheim staat nu in een account waaraan je niet had gedacht. Een kluis wordt vóór een migratie geëxporteerd. Een chatplatform bewaart de geschiedenis en maakt haar doorzoekbaar voor iedereen die later komt, ook voor wie op het moment van het bericht niet in het team zat. De laptop van een leverancier vertrekt met de leverancier.

Niets daarvan veronderstelt dat iemand zich misdraagt. Het is de gewone werking van consumentensoftware, en daarom groeit het aantal kopieën van een gedeeld geheim altijd alleen maar.

Wat het delen je kost

Telling. Je kunt niet weten hoeveel kopieën er bestaan.

Intrekking. Je kunt er geen terugnemen. Je kunt ze alleen allemaal ongeldig maken door het account opnieuw in te stellen.

Onafhankelijkheid. Een geheim dat naast het wachtwoord ligt maakt dat één inbreuk beide factoren oplevert, wat neerkomt op één factor met extra stappen.

Toewijzing. Elk van de kopieën kan de code hebben gemaakt die om 03.12 uur is gebruikt. Geen enkel logboek, nergens, zal zeggen welke.

Alles wat een team van 2FA op een gedeeld account verwacht, van beschikbaarheid zonder flessenhals tot een vertrek dat werkt en een antwoord op „wie logde er in”, volgt uit het niet uitdelen van het geheim. De werking om daar te komen staat in TOTP-codes delen zonder het geheim te delen.

Als het al gedeeld is

De meeste teams die dit lezen hebben al ergens een geheim gedeeld. De nuttige vraag is niet of dat een fout was, maar welke accounts het werk van een reset verdienen.

1. Beslis wat je reset

Reset de accounts waar een voormalige houder van het geheim echte schade zou kunnen aanrichten: alles wat geld, domeinen, klantgegevens, publicatierechten of cloudinfrastructuur raakt. Voor een account zonder belang waarvan je het wachtwoord kunt wijzigen en waarvan de toegangslijst kort is, kan het wachtwoord wijzigen en het delen aanhalen proportioneel zijn. Wat telt is bewust beslissen; uit traagheid beslissen is wat een betaalaccount twee jaar blootgesteld laat.

2. Reset in deze volgorde

De volgorde telt, want twee van deze stappen kunnen je buitensluiten als je ze eerst doet.

1. Zorg dat je actuele herstelcodes hebt, of ze kunt krijgen, voor je iets aanraakt.
2. Schakel de 2FA op het account uit. Alle bestaande kopieën van het geheim sterven hier.
3. Zet hem weer aan, en zet het nieuwe geheim op precies één plek.
4. Verleen toegang aan de mensen die de codes nodig hebben, zonder het nieuwe geheim uit te delen.
5. Genereer en berg de herstelcodes opnieuw op, buiten het account dat ze herstellen.

3. Ruim daarna op wat de reset niet heeft geraakt

Dit is de stap die wordt overgeslagen. De tweede factor resetten beëindigt doorgaans niets van wat al loopt:

• Log alle toestellen en alle sessies uit. Een aanvaller met een levende sessie heeft geen codes nodig.
• Wijzig het wachtwoord, want de twee sleutels hebben meestal samen gereisd.
• Loop de API-sleutels, de tokens en de verbonden apps na. Ze authenticeren zich per ontwerp zonder de tweede factor, en ze overleven de reset ervan.
• Bekijk de toegangs- en aanmeldgeschiedenis van het account, op zoek naar wat uit een tijd of plaats komt die niet zou mogen bestaan.

4. Noteer waar het nieuwe geheim woont

Eén regel per account: waar het geheim is, wie het beheert, waar de herstelcodes zijn. Het ontbreken van die notitie maakt teams huiverig om ook maar iets te resetten, omdat niemand zeker weet wat er kapotgaat.

Waar een geheim zou moeten wonen

Op één plek, bereikbaar door minstens twee beheerders, gescheiden van de herstelcodes, en gescheiden van het account dat het beschermt. Of dat een beperkte vermelding in je wachtwoordmanager is of een tool die daarvoor gemaakt is, telt minder dan het deel „één”.

Share Auth is één antwoord: het geheim wordt één keer ingevoerd, versleuteld opgeslagen, en nooit meer getoond. Leden zien codes en aftellingen, de toegang wordt per persoon en per account verleend, en elke raadpleging wordt gelogd. Wat het wegneemt is de reden waarom teams om te beginnen geheimen uitdelen, namelijk dat de persoon met de telefoon niet altijd beschikbaar is.

Kort samengevat

• Een TOTP-geheim is blijvend, symmetrisch en op zichzelf niet in te trekken.
• Het delen kost je de telling, de intrekking, de onafhankelijkheid van de factoren en de toewijzing.
• De kopieën vermenigvuldigen zich via back-ups, synchronisatie, exports en chatgeschiedenissen, zonder dat iemand iets fout doet.
• Is het gedeeld, beslis dan per account, reset in volgorde, en ruim de sessies en tokens op die de reset achterlaat.
• Houd daarna precies één kopie, en geef mensen liever toegang tot de codes.