Bij 2FA worden gebruikers na het inloggen met een wachtwoord geprompt om een tweede sleutel in te voeren. Voor dat proces wordt vaak het gestandaardiseerde algoritme Time-Based One-Time Password (TOTP) gebruikt. Google biedt een open dienst op basis van TOTP waarbij deze codes worden aangemaakt in de vorm van Google Authenticator. Hoe werkt dat precies?
Sleutel voor de app
Als je Google Authenticator configureert, wordt er allereerst een sleutel aangemaakt door de servers, in ons voorbeeld die van Google zelf. Dezelfde sleutel gaat Google Authenticator gebruiken in het TOTP-proces om codes mee aan te maken. Aan de serverkant wordt hetzelfde TOTP-proces gebruikt en de codes van de client worden op het eind van de rit vergeleken met die op de server.
Maar eerst even terug naar de configuratie. De gedeelde sleutel is een string van 32 tekens. Deze wordt verwerkt in een QR-code om het bevestigingsproces wat te vereenvoudigen voor gebruikers. Als alternatief kunnen ze op een link klikken om de sleutel te bevestigen voor de app. De vanaf dat moment gedeelde sleutel op de server wordt dan tevens opgeslagen in de applicatie, zodat deze daarmee codes kan aanmaken.
Codes maken
De codes die je steeds in de app ziet, zijn zes- tot achtcijferige hashes die zijn aangemaakt op basis van de met de server gedeelde geheime sleutel. Een tweede element om die code aan te maken is de ingestelde tijd van je toestel: de applicatie gebruikt die als input om de hash te genereren. Elke dertig seconden zie je een nieuwe code, die dus is gemaakt op basis van jouw sleutel en de timestamp die je toestel aanlevert.
Google zelf legde 2FA vijf jaar geleden uit bij de introductie van deze feature voor Google-diensten.
Hierna: Het verificatieproces en de zwakke plek van 2FA.
Om de 2FA-verificatie uit te voeren, bekijkt de server de code die je toestel heeft gepresenteerd. De server aan de andere kant voert dezelfde hashmethode uit. Die procedure pakt dus de gedeelde geheime sleutel, gebruikt de tijd als inputvariabele en maakt van de string die daaruit komt een zescijferige code op dezelfde manier als de app dat doet. Die twee codes moeten overeenkomen.
Tijd is een factor
Je toestel voert dit proces op zichzelf uit en heeft geen input nodig van de servers van Google om de 2FA-code aan te maken. Daarom werkt Authenticator ook offline. Voorwaarde is wel dat de input overeenkomt aan beide kanten en de tijd dus gesynchroniseerd moet zijn. Met andere woorden, de tijd moet kloppen op het toestel. Als codes opeens niet werken, adviseert Google dan ook om 'Tijdcorrectie voor codes' te gebruiken in de instellingen van de app.
De tweede code biedt op deze manier een extra beveiligingslaag bovenop de gebruikelijke combinatie van inlognaam en wachtwoord. Perfect is het niet - laat die droom van perfecte beveiliging ook maar gerust varen - maar het is wel een forse drempel voor aanvallers die met alleen je inlogcredentials niets meer aan kunnen vangen, tenzij ze je codes hebben. Ze hebben niets aan codes die inmiddels zijn vervallen.
Vervallen codes
Uit een hash kan namelijk, als die tenminste goed is geïmplementeerd, de oorspronkelijke gedeelde sleutel niet worden herleid om geldige nieuwe codes aan te maken. Een aanvaller kan daarom niets beginnen als hij of zij een code bemachtigt - tenzij die code wordt gebruikt in de korte tijd dat de server deze accepteert als geldige 2FA-sleutel.
En uiteraard is het zo dat als aanvallers de gedeelde sleutel achterhalen (bijvoorbeeld als ze een server bemachtigen), ze zelf codes kunnen aanmaken. Verder kan een snoodaard die je toestel heeft uiteraard ook inloggen, dus het is zaak om na verlies van je telefoon zo snel mogelijk diens toegang in te trekken. Maar goed, als een aanvaller fysieke toegang heeft, is het in de meeste gevallen sowieso rien ne va plus wat security betreft.
Een veelgebruikte optie in Google is om bepaalde hardware automatisch te vertrouwen en geen 2FA-code te vragen, bijvoorbeeld bij een laptop die mee gaat op reis.
Geweldige oplossing. Zou eigenlijk iedereen moeten gebruiken, indien men externe toegang wilt toestaan.
Google = Amerikaans bedrijf.
Deze methode is dus kapot vanaf de grond af aan. De NSA moet namelijk ook kunnen inloggen....
Hoedje op?
Het uitbesteden van je authenticatie doe je alleen aan een partij die je betrouwbaar acht. Ook het gebruik van een generiek apparaat als een mobiele telefoon is wat dubieus. Aan ieder zijn eigen afwegingen in dit opzicht. Maar wat is er fundamenteel kapot aan de methode zelf?
Correct, maar hoever wil je gaan. Uit eindelijk loopt bijna alles via een Amerikaans bedrijf. Maar als de NSA je echt onder de loep wilt nemen, dan heb je toch echt wel grotere problemen. Welke authenticatie je dan ook gebruikt maakt niet meer uit. Ze komen dan toch wel binnen.
Je moet zover gaan als je zelf nodig acht. Ik heb daar alleen in specifieke gevallen een mening over. Het lijkt mij echter zeker wel mogelijk om partijen als de NSA buiten te houden. Triviaal zal het niet zijn, maar zeker ook niet onmogelijk.
Heb je hier ook enige bron voor dan de NSA dit ook misbruikt? Of is dit jouw fingerspitzengefühl? Of misschien gewoon iets te veel aluminium hoedjes opgehad?
Maar al zou het wel zo zijn...... Dan is het nog altijd 10 keer beter dan alleen een UserID en Password authenticatie. Ofwel voor 99,9999999% van de gebruikers is dit een perfecte oplossing.
Reageer
Preview