Kunnen meerdere mensen dezelfde TOTP gebruiken?

Ja. TOTP heeft geen enkel begrip van hoeveel mensen een geheim bewaren, en om het even hoeveel toestellen met hetzelfde geheim tonen op hetzelfde moment dezelfde zes cijfers. Wat misgaat is niet de rekenkunde. Het zijn de twee aanmeldingen die in dezelfde dertig seconden botsen, de klok die op een telefoon wegloopt, en het feit dat achteraf niets kan zeggen wie er inlogde.

In die vraag zitten twee verschillende vragen

„Kunnen meerdere mensen dezelfde TOTP gebruiken” betekent bijna altijd een van twee dingen, en die hebben tegengestelde antwoorden.

Meerdere mensen die hetzelfde geheim bewaren. Het geheim is de blijvende sleutel: hij verloopt niet, hij is aan geen toestel gebonden, en er is geen registratie om ongedaan te maken. Elke extra houder is een niet te tellen en niet in te trekken kopie van de tweede factor van het account.

Meerdere mensen die dezelfde code lezen. De code is zes cijfers die zo’n dertig seconden gelden, goed voor één inlogpoging. Er een aan een collega doorgeven geeft niets prijs dat het gesprek overleeft.

Beide lijken op „de 2FA delen”, en daarom doen teams uiteindelijk het blijvende terwijl ze alleen het tijdelijke nodig hadden. Die afweging, en de uitwegen eruit, zijn het onderwerp van hoe je 2FA-codes veilig met je team deelt. Dit artikel blijft bij de smalle vraag: wat je echt zult zien wanneer meer dan één persoon vanuit dezelfde TOTP werkt.

Wat er werkelijk gebeurt met twee toestellen

De codes komen overeen, zolang de klokken overeenkomen

Twee toestellen met hetzelfde geheim zijn op geen enkele manier met elkaar gesynchroniseerd. Dat hoeft ook niet: de code wordt afgeleid uit het geheim en de huidige tijd, en verder gaat er niets in. Identieke invoer, identieke uitvoer. De werking staat in de volledige gids over TOTP in teams; het praktische punt is dat een tweede inschrijving voor iedereen onzichtbaar is, jou inbegrepen.

Twee aanmeldingen in hetzelfde venster: de tweede kan geweigerd worden

Dit is het symptoom dat mensen op zoek stuurt naar een kapotte configuratie. Twee mensen loggen in binnen dezelfde stap van dertig seconden, allebei met de juiste code, en de tweede poging wordt afgewezen.

RFC 6238 vraagt verificatiediensten om een gegeven code maar één keer per tijdstap te accepteren, en de meeste implementaties houden zich daaraan door de laatst gebruikte stap voor een account te bewaren. Vanuit het account gezien is er maar één gebruiker: de tweede aanmelding lijkt dus op het hergebruik van een al besteedde code.

Het middel is op de volgende code wachten. Dat is het waard vooraf te weten, want de natuurlijke reactie, aannemen dat je je vertikt hebt en de code opnieuw typen, verergert het volgende probleem.

Nieuwe pogingen tellen op tegen de limiet van de aanbieder

Zes cijfers zijn een miljoen mogelijkheden: aanbieders beperken daarom de pogingen. Die limiet telt per account, niet per persoon.

Drie mensen die elk twee keer proberen hebben zes mislukkingen op één account geproduceerd, wat kan volstaan voor een tijdelijke blokkade, een extra controle of een beveiligingsmail naar wie het geregistreerde adres beheert. Elk afzonderlijk gedrag is redelijk; het totaal lijkt op een aanval.

Eén klok loopt weg en maar één persoon merkt het

Klokafwijking wordt meestal beschreven als een storing die het hele account raakt, maar met meerdere toestellen ziet ze er anders uit: de codes werken voor iedereen behalve voor één persoon, systematisch, en alleen vanaf haar toestel.

De telefoon van die persoon berekent codes voor een tijdstap die de server al voorbij is of nog niet bereikt heeft. Er is niets mis met het geheim, en het opnieuw invoeren helpt niets. Wat je moet nakijken is de automatische tijdinstelling, op het toestel dat faalt.

Gelijktijdige aanmeldingen vanaf meerdere plekken lijken op een inbraak

De misbruikdetectie aan de kant van de aanbieder reageert op patronen, en een account dat zich binnen enkele minuten vanuit twee steden authenticeert is precies het patroon waarvoor ze gebouwd is. Afhankelijk van de dienst levert dat een extra controlestap op, een mail over een nieuw apparaat, een gedwongen wachtwoordreset, of een sessie die midden in een taak eindigt.

Niets daarvan is een TOTP-probleem, en niets ervan los je op met een instelling aan jouw kant. Zo ziet een gedeelde inlog er van buitenaf gewoon uit, en het wordt frequenter naarmate het aantal gebruikers groeit.

Niets legt vast welk toestel de aanvaarde code maakte

De verificatiedienst vergelijkt zes cijfers. Hij leert niet waar ze vandaan komen, omdat er in de code niets te leren valt, en omdat een toestel inschrijven van meet af aan nergens iets heeft verstuurd.

Dus wanneer het logboek van het account een aanmelding om 14.12 uur toont, houdt het spoor daar op. Kunnen vier mensen codes maken, dan kunnen vier mensen ingelogd hebben, en het account kan niet verder inperken. Dat is het deel dat na een incident telt, en de reden waarom medewerkers toegang tot 2FA geven zonder hun het geheim te geven toewijzing als een eis behandelt en niet als een prettige extra.

Dus „ja, technisch”, tegen welke prijs

Alles hierboven is wrijving: vervelend, te diagnosticeren, te overwinnen. De prijs van meerdere mensen die het geheim bewaren hoort in een andere categorie, en levert geen enkel symptoom op.

Je kunt de kopieën niet tellen. Niets in de beveiligingsinstellingen van het account zal ooit zeggen hoeveel toestellen zijn ingeschreven: het getal is zo veel waard als je herinnering aan eerdere inschrijvingen.

Je kunt er geen intrekken. Het protocol voorziet geen rotatie en geen registratie per toestel, wat betekent dat de enige beschikbare intrekking bestaat uit de 2FA op het account uitschakelen en opnieuw instellen, voor iedereen tegelijk.

En de tweede factor houdt op onafhankelijk te zijn overal waar het geheim naast het wachtwoord belandt: een gedeelde notitie, een kluisvermelding, een document. Eén plek bereikt, en beide factoren zijn weg. Hoe TOTP-geheimen werken (en waarom je ze niet moet delen) loopt de plekken langs waar de kopieën zich opstapelen. Kort gezegd: ze stapelen zich stilletjes op, en ze blijven.

Wat de vraag echt vraagt

Wat mensen willen door haar te stellen, is dat meerdere collega’s op hetzelfde account kunnen inloggen. Dat vraagt niet dat meerdere mensen het geheim bewaren. Het vraagt drie dingen.

Eén enkele houder van het geheim. Eén keer ingevoerd, door wie het account beheert, bewaard op één bekende plek die minstens twee beheerders kunnen bereiken. Alle andere betrokkenen verbruiken codes in plaats van iets op te slaan.

Codes die per persoon worden uitgedeeld. Elke geautoriseerde persoon krijgt de actuele code en het aftellen wanneer ze die nodig heeft, per account toegekend, en met één handeling in te trekken. Op niemands toestel staat iets dat haar toegang overleeft.

Een spoor van de raadplegingen. Omdat het logboek van de aanbieder nooit meer kan tonen dan het gedeelde account, is het register van wie een code opvroeg het enige dat een naam naast een tijdstempel zet.

Kan het betrokken platform elke collega een eigen inlog geven, doe dat dan; het is beter dan wat dan ook delen, en de 2FA van een gedeeld account: hoe pakt een team dat aan? zet uiteen welke accounts echt geen optie per persoon hebben. De drie eisen hierboven gelden voor de accounts die werkelijk maar één inlog hebben.

Waar Share Auth staat

Share Auth is voor dit geval gemaakt. Het geheim wordt één keer ingevoerd en versleuteld opgeslagen; uitgenodigde leden zien de code en het aftellen, nooit het geheim erachter. Rechten worden per lid en per account ingesteld, elke raadpleging van een code wordt in een toegangslogboek geschreven, en een lid verwijderen trekt zijn toegang overal in één handeling in. Scripts die moeten inloggen kunnen de codes via de API opvragen in plaats van een persoon te betrekken.

Het gratis pakket dekt drie geheimen en drie leden, zonder bankkaart, wat genoeg is om te zien of de hierboven beschreven vorm past bij hoe je team echt werkt.