Twee-factor-authenticatie
Alles wat u heeft gelezen in heeft betrekking op identificatie op basis van wat de aanvrager weet. Hij weet zijn e-mailadres, weet hoe hij toegang kan krijgen (dat wil zeggen, hij weet zijn wachtwoord voor het e-mailadres) en weet de antwoorden op geheime vragen.
‘Kennis’ wordt beschouwd als een factor van authenticatie; de twee andere gangbare factoren zijn wat u heeft, zoals een fysiek apparaat, en wie u bent, zoals vingerafdrukken of het netvlies van het oog.
In de meeste gevallen is biologische identificatie moeilijk uitvoerbaar, vooral als we het hebben over de beveiliging van webapplicaties, daarom wordt bij twee-factor-authenticatie (two factor authentication, 2FA) meestal het tweede kenmerk gebruikt — ‘wat u heeft’. Een van de populaire opties voor deze tweede factor is een fysiek token, zoals :
Een fysiek token wordt vaak gebruikt voor authenticatie in bedrijfs-VPN's en financiële diensten. Voor authenticatie in de dienst moet zowel een wachtwoord als een code op het token (die vaak verandert) in combinatie met een PIN worden gebruikt. Theoretisch, voor identificatie moet de aanvaller het wachtwoord weten, het token bezitten en ook de PIN van het token kennen. In het geval van een wachtwoordreset is het wachtwoord duidelijk onbekend, maar het bezit van het token kan worden gebruikt om eigendom van het account te bevestigen. Uiteraard, net als bij elke implementatie van beveiliging, , maar verhoogt het zeker de instapdrempel.
Een van de belangrijkste problemen van deze aanpak is de kosten en de logistiek van de implementatie; we hebben het over het verstrekken van fysieke apparaten aan elke klant en het opleiden van hen in het nieuwe proces. Bovendien moeten gebruikers het apparaat bij zich hebben, wat in het geval van een fysiek token niet altijd mogelijk is. Een andere optie is om de tweede factor van authenticatie te implementeren via SMS, die in het geval van 2FA kan dienen als bevestiging dat de persoon die het resetproces uitvoert, de mobiele telefoon van de account eigenaar heeft. Zo doet Google dit:
Daarnaast moet ook , maar dit betekent dat bij de volgende wachtwoordreset uw mobiele telefoon een tweede authenticatiefactor kan worden. Laat me dit demonstreren met mijn iPhone om redenen die binnenkort duidelijk zullen worden:
Na identificatie van het e-mailadres van het Google-account, wordt vastgesteld dat 2FA is ingeschakeld en we kunnen het account resetten met een verificatie die via SMS naar de mobiele telefoon van de account eigenaar wordt verzonden:
Nu moeten we het begin van het resetproces selecteren:
Deze actie leidt tot het verzenden van een e-mail naar het geregistreerde adres:
Deze e-mail bevat een reset-URL:
Bij toegang tot de reset-URL wordt een SMS verzonden en vraagt de website deze in te voeren:
Dit is de SMS:
Na invoer in de browser keren we terug naar het klassieke wachtwoordresetgebied:
Het lijkt misschien een beetje langdradig, en dat is het ook, maar het formulier bevestigt dat de persoon die de reset uitvoert toegang heeft tot het e-mailadres en de mobiele telefoon van de account eigenaar. Maar dit kan negen keer veiliger zijn dan het resetten van een wachtwoord alleen via e-mail. Er zijn echter problemen...
Het probleem heeft te maken met smartphones. Het apparaat dat hieronder is weergegeven, kan slechts één authenticatiefactor verifiëren - het kan SMS ontvangen, maar geen e-mail:
Dit apparaat kan echter SMS ontvangen en e-mails over wachtwoordresets ontvangen:
Het probleem is dat we e-mail beschouwen als de eerste authenticatiefactor, en SMS (of zelfs een applicatie die tokens genereert) als de tweede, maar vandaag zijn ze samengevoegd in één apparaat. Dit betekent natuurlijk dat als iemand toegang krijgt tot uw smartphone, al dit gemak terugkomt naar één kanaal; die tweede factor ‘wat u heeft’ betekent dat u ook de eerste factor heeft. En dit alles is beveiligd met één pincode van vier cijfers... als de telefoon überhaupt een PIN-code heeft en deze was vergrendeld.
Ja, de door Google geïmplementeerde 2FA-functie biedt zeker extra bescherming, maar deze is niet ‘foolproof’ en hangt zeker niet af van twee volledig autonome kanalen.
Resetten op basis van gebruikersnaam versus resetten op basis van e-mailadres
Moet het resetten alleen via e-mail worden toegestaan? Of moet de gebruiker ook de mogelijkheid hebben om te resetten via de naam? Het probleem met het resetten via de gebruikersnaam is dat er geen manier is om de gebruiker te informeren over een onjuiste gebruikersnaam, zonder onthulling dat iemand anders een account met die naam kan hebben. In het vorige gedeelte zorgde het resetten via e-mail ervoor dat de legitieme eigenaar van dat e-mailadres altijd feedback ontving zonder openbaar te maken dat hij in het systeem bestaat. Dit is met alleen een gebruikersnaam niet mogelijk.
Daarom is het korte antwoord: alleen e-mail. Als je alleen met een gebruikersnaam probeert te resetten, zullen er gevallen zijn waarin de gebruiker zal twijfelen wat er aan de hand is, of je onthult het bestaan van accounts. Ja, het is maar een gebruikersnaam en geen e-mailadres, en ja, iedereen kan een (beschikbare) gebruikersnaam kiezen, maar toch is de kans groot dat je de eigenaren van accounts indirect onthult vanwege de neiging van gebruikers om hun naam meerdere keren te gebruiken.
Wat gebeurt er dan als iemand zijn gebruikersnaam vergeten is? Stel dat de gebruikersnaam niet meteen een e-mailadres is (wat vaak het geval is), dan lijkt het proces op het begin van het resetten van een wachtwoord — we voeren het e-mailadres in en sturen vervolgens een bericht naar dat adres, zonder het bestaan ervan te onthullen. Het enige verschil is dit keer dat het bericht alleen de gebruikersnaam bevat en geen URL voor het resetten van het wachtwoord. Of het staat in de e-mail dat er geen account is voor dit adres.
Identiteitsverificatie en nauwkeurigheid van e-mailadressen
Een sleutelaspect van wachtwoordresets, en zelfs waarschijnlijk, het belangrijkste aspect is de identificatie van de persoon die probeert te resetten. Is het werkelijk de legitieme eigenaar van het account, of probeert iemand het te hacken of de eigenaar te storen?
Het is duidelijk dat e-mail het meest handige en meest gebruikte kanaal is voor identificatie. Het is niet beschermd tegen onzorgvuldig gebruik ('door een domme'), en er zijn veel gevallen waarin de eenvoudige mogelijkheid om e-mails op het adres van de account eigenaar te ontvangen niet voldoende is als er een hoge mate van vertrouwen in de identificatie nodig is (daarom wordt 2FA gebruikt), maar het is bijna altijd het startpunt van het resetproces.
Als e-mail een rol speelt in het bieden van vertrouwen, dan moet eerst worden gegarandeerd dat het e-mailadres daadwerkelijk correct is. Als iemand een teken heeft vergist, zal de reset duidelijk niet beginnen. Het proces van e-mailverificatie bij registratie is een betrouwbare manier om de juistheid van het adres te controleren. We hebben dit allemaal in de praktijk gezien: je registreert je, er wordt een e-mail gestuurd met een unieke URL waarop je moet klikken, wat bevestigt dat jij inderdaad de eigenaar van dit e-mailadres bent. De onmogelijkheid om in te loggen totdat dit proces is voltooid, garandeert dat er motivatie is om het adres te bevestigen.
Zoals bij veel andere aspecten van veiligheid, vermindert dit model de bruikbaarheid in ruil voor een verhoogde mate van veiligheid wat betreft het vertrouwen in de identiteit van de gebruiker. Dit kan acceptabel zijn voor een site waar de gebruiker zich zeer gewaardeerd voelt en graag een extra stap aan het proces toevoegt (betaaldiensten, bankieren, enz.), maar dergelijke zaken kunnen de gebruiker afschrikken als hij het account als 'eenmalig' beschouwt en bijvoorbeeld gewoon gebruikt om een bericht te kommenteren.
Identificatie van wie het resetproces heeft geïnitieerd
Het is duidelijk dat er redenen zijn voor misbruik van de resetfunctie, en aanvallers kunnen deze op verschillende manieren gebruiken. Een eenvoudige truc die we kunnen gebruiken ter ondersteuning van de bevestiging van de bron van het verzoek (deze truc gewoonlijk werkt) — is het toevoegen van het IP-adres van de aanvrager in de e-mail met het verzoek om te resetten. Dit voorziet de ontvanger van enige informatie om de bron van het verzoek te identificeren.
Hier is een voorbeeld van de resetfunctie die ik momenteel integreer in ASafaWeb:
De link «find out more» («Meer informatie») leidt de gebruiker naar de website , dat informatie verstrekt zoals de locatie en organisatie van de aanvrager van de reset:
Natuurlijk zijn er veel manieren voor iedereen die zijn identiteit wil verbergen om zijn echte IP-adres te maskeren, maar dit is een handige manier om een gedeeltelijke identificatie van de aanvrager toe te voegen, en in de meeste de meeste gevallen geeft dit je voldoende inzicht in wie het verzoek om een wachtwoordreset indient.
E-mailmelding over wijzigingen
Deze post is doordrenkt met één thema — communicatie; informeer de eigenaar van het account zo goed mogelijk over wat er gebeurt in elke fase van het proces, zonder iets prijs te geven wat verkeerd gebruikt zou kunnen worden. Dit geldt ook voor de situatie waarin het wachtwoord daadwerkelijk is gewijzigd — vertel dit aan de eigenaar!
Er zijn twee redenen voor het wijzigen van het wachtwoord:
- Wachtwoordwijziging na inloggen, omdat de gebruiker een nieuw wachtwoord wil
- Wachtwoordreset zonder inloggen, omdat de gebruiker het is vergeten
Hoewel deze post voornamelijk gericht is op een reset, vermindert de melding in het eerste geval het risico dat iemand het wachtwoord wijzigt zonder medeweten van de rechtmatige eigenaar. Hoe kan dit gebeuren? Een veelvoorkomend scenario is het verkrijgen van het wachtwoord van de rechtmatige eigenaar (hergebruikt wachtwoord, gelekt uit een andere bron; wachtwoord verkregen via keylogging; gemakkelijk te raden wachtwoord, etc.), waarna de aanvaller besluit dit te wijzigen, waardoor de eigenaar wordt geblokkeerd. Zonder e-mailmelding zal de echte eigenaar niet weten dat het wachtwoord is gewijzigd.
Natuurlijk, in het geval van een wachtwoordreset zou de eigenaar het proces al zelf moeten hebben geïnitieerd (of de hierboven beschreven verificatiemiddelen hebben omzeild), zodat de wijziging hoort voor hem een verrassing is, maar de bevestiging per e-mail zou positieve feedback en een extra controle zijn. Bovendien zorgt dit voor consistentie met het bovenstaande scenario.
Oh, en voor het geval dat dit nog niet duidelijk is — stuur het nieuwe wachtwoord niet per e-mail! Sommigen zullen dit misschien grappig vinden, maar :
Logs, logs, logs en nog wat logs
De functie voor het resetten van wachtwoorden is aantrekkelijk voor kwaadwillenden: een aanvaller wil toegang krijgen tot de account van een ander persoon, of gewoon de eigenaar van het account/systeem ongemak bezorgen. Veel van de hierboven beschreven praktijken helpen de kans op misbruik te verkleinen, maar voorkomen het niet, en ze zullen zeker niet voorkomen dat mensen proberen de functie op ongepaste wijze te gebruiken.
Voor het herkennen van kwaadaardig gedrag is logging een absoluut onmisbare praktijk, en ik bedoel zeer gedetailleerde logging. Leg mislukte inlogpogingen, het resetten van wachtwoorden, wachtwoordwijzigingen (dus wanneer de gebruiker al ingelogd is) en vrijwel alles vast wat je kan helpen om te begrijpen wat er aan de hand is; dit zal in de toekomst zeer nuttig zijn. Leg zelfs afzonderlijke delen van het proces vast, bijvoorbeeld een goede resetfunctie moet inhouden dat resetten via de website wordt geïnitieerd (log de aanvraag en inlogpogingen voor het resetten met een verkeerd gebruikersnaam of e-mailadres), log het bezoek aan de reset-URL (inclusief de pogingen om een ongeldig token te gebruiken), en registreer vervolgens de succes of falen van het antwoord op de geheime vraag.
Wanneer ik het heb over logging, bedoel ik niet alleen het vastleggen van het feit dat een pagina is geladen, maar ook het verzamelen van zoveel mogelijk informatie, als deze niet vertrouwelijk is.Jongens, leg alsjeblieft geen wachtwoorden vast in de logs! In de logs moet de identiteit van de geauthenticeerde gebruiker worden geregistreerd (ze zijn geauthenticeerd als ze een bestaand wachtwoord wijzigen of proberen een ander wachtwoord te resetten na inloggen), alle geprobeerd gebruikersnamen of e-mailadressen plus alle reset tokens die ze proberen te gebruiken. Maar het is ook goed om loggegevens vast te leggen zoals IP-adressen en, indien mogelijk, zelfs de headers van verzoeken. Dit stelt je in staat om niet alleen te reconstrueren wat de we gaan laden, kunnen we vertellen hoe we dit gaan doen: gebruiker (of aanvaller) probeert te doen, maar ook wie wie hij is.
Verantwoordelijkheid delegeren aan andere uitvoerders.
Als je denkt dat dit een enorme hoeveelheid werk is, dan ben je niet alleen. In werkelijkheid is het opzetten van een betrouwbaar accountsysteem een uitdagende taak. Het is niet zo dat het technisch moeilijk is, maar er zijn veel specifieke aspecten aan verbonden. Het gaat niet alleen om het resetten van wachtwoorden; er is een heel proces van registratie, veilige opslag van wachtwoorden, verwerking van meerdere foutieve inlogpogingen, enzovoort. Hoewel , is er nog veel meer te doen.
Tegenwoordig zijn er veel externe leveranciers die met plezier al het werk op zich nemen en dit abstraheren naar een beheerde service. Onder deze services zijn OpenID, OAuth en zelfs Facebook. Sommige mensen (OpenID is inderdaad erg succesvol gebleken op Stack Overflow), maar anderen .
Zonder twijfel lost een service zoals OpenID veel problemen van ontwikkelaars op, maar het is ook onbetwistbaar dat het nieuwe problemen toevoegt. Hebben ze een rol? Ja, maar het is duidelijk dat er geen massaal gebruik is van de diensten van authenticatieproviders. Banken, luchtvaartmaatschappijen en zelfs winkels — allemaal implementeren ze hun eigen authenticatiemechanismen, en het is duidelijk dat daar zeer goede redenen voor zijn.
Kwaadwillige reset
Een belangrijk aspect van elk van de bovengenoemde voorbeelden is dat het oude wachtwoord pas als nutteloos wordt beschouwd na de verificatie van de identiteit van de accounteigenaar.Dit is belangrijk omdat als een account kon worden gereset tot zonder identificatiecontrole, dit een mogelijkheid zou bieden voor allerlei kwaadwillige acties.
Hier is een voorbeeld: iemand doet mee aan een veilingwebsite, en vlak voor het einde van het biedproces blokkeert hij concurrenten door het resetproces te starten, waardoor hij hen uit de veiling verwijdert. Het is duidelijk dat als een slecht ontworpen resetfunctie verkeerd kan worden aangevallen, dit kan leiden tot ernstige negatieve gevolgen. Het is vermeldenswaard dat het blokkeren van accounts door middel van foutieve inlogpogingen een vergelijkbare situatie is, maar dat is een onderwerp voor een andere post.
Zoals ik eerder zei, als we anonieme gebruikers de mogelijkheid geven om het wachtwoord van elk account te resetten gewoon door het e-mailadres te kennen, dan is dat een perfecte situatie voor een Denial of Service-aanval. Dit is misschien niet de DoS waar we vaak over praten, maar er is geen snellere manier om toegang tot een account te blokkeren dan met een slecht doordachte functie voor het resetten van wachtwoorden. , waar we normaal gesproken over spreken, maar er is geen snellere manier om toegang tot een account te blokkeren dan via een slecht doordachte wachtwoordresetfunctie.
De zwakste schakel
Vanuit het perspectief van de bescherming van een account is alles wat hierboven is geschreven geweldig, maar je moet altijd rekening houden met het ecosysteem rond het account dat je beschermt. Laat me een voorbeeld geven:
ASafaWeb wordt gehost op een geweldige service die wordt aangeboden door AppHarbor. Het proces voor het resetten van het hostingaccount verloopt als volgt:
Stap 1:
Stap 2:
Stap 3:
Stap 4:
Na het lezen van alle voorgaande informatie is het al gemakkelijk te begrijpen welke aspecten in een ideale wereld we iets anders zouden implementeren. Echter, hier wil ik zeggen dat als ik een site zoals ASafaWeb publiceer op de service van AppHarbor en vervolgens geweldige geheime vragen en antwoorden bedenk, een tweede authenticatiefactor toevoeg en alles verder volgens de regels doe, dat dat niet wegneemt dat de zwakste schakel in het gehele proces dit alles kan verbreken. Als iemand succesvol authenticatie uitvoert in AppHarbor met mijn informatie, kan hij het wachtwoord van elk ASafaWeb-account resetten naar wat hij maar wil!
Het punt is dat de veerkracht van de implementatie van bescherming holistisch moet worden bekeken: ik moet de dreigingen van elk toegangspunt in het systeem modelleren, zelfs als dit een oppervlakkig proces is, zoals inloggen op AppHarbor. Dit zou me een goed idee moeten geven van hoeveel moeite ik moet steken in het wachtwoorden resetten van ASafaWeb.
Alles samenvoegen
Deze post bevat een grote hoeveelheid informatie, dus ik wil het samenbrengen in een eenvoudige visuele weergave:
Vergeet niet dat je zo gedetailleerd mogelijk elk van deze punten moet loggen. Dat is alles, het is zo simpel!
Conclusies
Mijn post lijkt allesomvattend, maar er zijn talloze aanvullende materialen die ik zou kunnen in te opnemen, maar besloot dit voor de duidelijkheid te laten: de rol van het adres van een redmiddel email, een situatie waarin je de toegang tot de aan het account gekoppelde email verliest (bijvoorbeeld omdat je ontslagen bent) en dergelijke. Zoals ik eerder zei, is de resetfunctie niet zo ingewikkeld, maar er zijn veel verschillende meningen over.
Hoewel de reset niet zo moeilijk is, wordt deze vaak verkeerd uitgevoerd. Eerder zagen we een paar voorbeelden waar de implementatie kan problemen veroorzaakte, en er zijn veel meer gevallen waarin een onjuiste reset inderdaad problemen heeft veroorzaakt. Onlangs werd ontdekt dat Dit is een ernstige negatieve uitkomst!
Wees daarom voorzichtig met je resetfuncties, op verschillende punten, en draag je zwarte hoed niet af tijdens het ontwerpen van de functie, want de kans is groot dat iemand anders hem opzet!
Adverteervermelding
VDSina biedt goedkope met dagbetaling, elke server is verbonden met een internetverbinding van 500 megabit en gratis beschermd tegen DDoS-aanvallen!
Bron: habr.com
