Bekijk accountlogin, toestemming voor gegevenstoegang en herstel van chatsleutels afzonderlijk; één inlogknop beantwoordt niet alle drie de vragen.
‘Inloggen met Google’ betekent niet automatisch dat Google toegang krijgt tot de tekst van chats, maar is ook geen keuze zonder vertrouwensafweging. Deze methode betrekt een identiteitsaanbieder bij het inlogproces; de overgedragen informatie en de afhankelijkheid van het account moeten worden beoordeeld aan de hand van de rechten en de daadwerkelijke opzet van de dienst.
Maak voor je beslissing onderscheid tussen accountlogin, toestemming voor toegang tot Google-gegevens en de versleutelingssleutels van gesprekken. Eén inlogknop beantwoordt niet alle drie de vragen.
Wat is het verschil tussen OAuth en OpenID Connect?
OAuth is een raamwerk om toegang tot bronnen te verlenen. OpenID Connect voegt daar een authenticatielaag aan toe. Googles inlogdocumentatie beschrijft de op OpenID Connect gebaseerde procedure om gebruikers te identificeren.
De uitspraak ‘OAuth geeft je Google-wachtwoord aan de berichtenapp’ is dus onjuist. De dienst moet het betreffende token correct valideren en zijn eigen sessie beveiligen. Toestemming voor Gmail, Drive of andere gegevens staat eveneens los van alleen inloggen. Uitleg over rechten en scopes.
Welke informatie kan worden uitgewisseld?
De inlogprocedure verstrekt doorgaans een identificatiecode aan de dienst en, afhankelijk van de rechten, informatie zoals een e-mailadres of profielgegevens. De identiteitsaanbieder is ook betrokken bij authenticatieverzoeken. Uit de naam van de inlogmethode kan echter niet worden afgeleid dat iedere keer dat de app opent, elk bericht of de volledige gebruiksgeschiedenis aan die aanbieder wordt doorgegeven.
| Vraag | Wat je moet controleren |
|---|---|
| Welke accountgegevens ontvangt de berichtenapp? | Het toestemmingsscherm, de scopes en het privacybeleid |
| Wordt toegang tot extra gegevens gevraagd? | Het onderscheid tussen inloggen en toegang tot e-mail, bestanden of contacten |
| Wanneer wordt de identiteitsaanbieder opnieuw betrokken? | Het sessie- en tokenvernieuwingsbeleid van de implementatie |
| Zijn de chatsleutels afhankelijk van deze login? | Documentatie over sleutelopslag en -herstel, niet alleen de inlogknop |
Verleen geen toestemming die niet kan worden verklaard vanuit jouw behoefte. Vat tegelijk een specifieke toestemmingsvraag niet zonder onderzoek op als ‘alle berichten lezen’.
Wat is het risico van afhankelijkheid van een centraal account?
Als je enige manier om op een berichtenapp in te loggen een account is waartoe je de toegang verliest, kan een nieuwe login worden verhinderd. Het effect op bestaande sessies, lokale gegevens en herstel hangt af van de opzet van de dienst. ‘Een geblokkeerd Google-account vernietigt gegarandeerd alle chats’ is daarom geen juiste conclusie.
Controleer voordat er een noodsituatie ontstaat of de dienst een alternatieve inlogmethode of herstelprocedure biedt en hoe het toevoegen daarvan de accountbeveiliging beïnvloedt. Een alternatief mag geen gemakkelijkere route voor een aanvaller worden. Wijzig of verwijder ook geen accountkoppeling zonder zeker te weten hoe je daarna kunt inloggen.
Neemt rechtstreeks inloggen met SRP al deze risico’s weg?
Rechtstreeks inloggen kan de afhankelijkheid van een externe identiteitsaanbieder verminderen. Bij correcte uitvoering bewijst SRP ook kennis van het wachtwoord zonder het zelf in protocolberichten te versturen. De berichtenapp verwerkt echter nog steeds de accountnaam, inloggebeurtenissen en bijbehorende operationele informatie; ‘zonder digitale voetafdruk’ is geen juiste omschrijving.
Ook de opgeslagen SRP-verifier moet worden beschermd. RFC 5054 beschrijft het risico op wachtwoordgissingen nadat de verifier is gelekt. Beveiliging van de inlogpagina, sessie, herstel en het apparaat blijft essentieel.
Geen technisch principe stelt dat SRP de enige privacyvriendelijke inlogmethode is of dat elke federatieve login inherent onveilig is. De kwaliteit van de uitvoering en het dreigingsmodel moeten doorslaggevend zijn.
De grenzen van Livara’s claims
Livara’s beveiligingspagina beschrijft SRP voor authenticatie en vermeldt ook expliciet dat bepaalde operationele gegevens worden bewaard. Dat betekent niet dat de accountidentiteit voor de dienst zelf verborgen blijft. Dezelfde pagina maakt onderscheid tussen herstel van de cryptografische identiteit en de chatgeschiedenis.
Vraag voor een praktische vergelijking aan iedere dienst dezelfde antwoorden: welke gegevens ontvangt die, welke derde partij is betrokken, hoe beëindigt die een sessie en hoe worden chatsleutels hersteld? Een gedocumenteerd antwoord is nuttiger dan de slogan ‘zero knowledge’.
Voordat je een inlogmethode kiest
Beveilig je hoofdaccount en herstelmethoden, lees de gevraagde rechten, bekijk gekoppelde apparaten en weet wat je plan is bij verlies van het account. Kies daarna de inlogmethode die past bij jouw behoeften en wat je kunt beheren; gemak en onafhankelijkheid zijn beide waardevol, maar geen van beide garandeert op zichzelf veiligheid.
