To-faktor autentificering
Alt, hvad du har læst i handler om identifikation baseret på, hvad anmoderen kender. Han kender sin e-mailadresse, ved, hvordan man får adgang til den (dvs. kender sin e-mail-adgangskode) og ved svarene på de hemmelige spørgsmål.
«Viden» betragtes som en autentificeringsfaktor; to andre almindelige faktorer er hvad du har, såsom en fysisk enhed, og hvem du er, såsom fingeraftryk eller iris-scanning.
I de fleste tilfælde er biologisk identifikation svært at implementere, især når vi taler om sikkerheden ved webapplikationer, så ved to-faktor autentificering (two factor authentication, 2FA) anvendes normalt den anden attribut — «hvad du har». En populær mulighed for denne anden faktor er et fysisk token, for eksempel, :
Et fysisk token bruges ofte til autentificering i virksomhedernes VPN og finansielle tjenester. For at autentificere dig i tjenesten skal du anvende både adgangskoden og koden på tokenet (som ofte ændres) i kombination med en PIN. Teoretisk set, for at identificere en angriber, skal de kende adgangskoden, have tokenet og også kende tokenets PIN. I scenariet for nulstilling af adgangskoden er selve adgangskoden åbenlyst ukendt, men besiddelse af tokenet kan bruges til at bekræfte ejerskabet af kontoen. Naturligvis, som med enhver implementering af sikkerhed, , men hæver bestemt adgangsbarrieren.
Et af de største problemer med denne tilgang er omkostningerne og logistikken ved implementering; vi taler om at skulle levere fysiske enheder til hver kunde og træne dem i den nye proces. Desuden skal brugerne have enheden med sig, hvilket ikke altid er tilfældet med et fysisk token. En anden mulighed er at implementere den anden faktor af autentificering via SMS, som i 2FA kan fungere som bekræftelse på, at den person, der udfører nulstillingsprocessen, har ejerens mobiltelefon. Sådan gør Google:
Det er også nødvendigt at aktivere , men det betyder, at din mobiltelefon kan blive den anden faktor for autentificering ved næste nulstilling af adgangskoden. Lad mig demonstrere dette med min iPhone af grunde, der snart vil blive klare:
Efter identifikation af e-mailadressen til Google-kontoen, konstaterer systemet, at 2FA er aktiveret, og vi kan nulstille kontoen ved hjælp af verifikation, der sends via SMS til ejerens mobiltelefon:
Nu skal vi vælge, hvordan vi vil starte nulstillingsprocessen:
Denne handling fører til, at der sendes en e-mail til den registrerede adresse:
Denne e-mail indeholder URL'en til nulstillingen:
Når man tilgår URL'en til nulstillingen, sendes der en SMS, og webstedet beder om at indtaste den:
Her er SMS'en:
Efter at have indtastet den i browseren, vender vi tilbage til siden for klassisk nulstilling af adgangskoden:
Dette virker måske lidt omstændeligt, og det er det, men formen bekræfter, at personen, som nulstiller, har adgang til både e-mailadressen og mobiltelefonen til ejerens konto. Men dette kan være op til ni gange mere sikkert end at nulstille adgangskoden kun via e-mail. Dog er der nogle problemer...
Problemet handler om smartphones. Enheden, der vises nedenfor, kan kun autentificere én faktor for autentificering — den kan modtage SMS, men ikke e-mails:
Men denne enhed kan modtage SMS'er og modtage e-mails om nulstilling af adgangskoden:
Problemet er, at vi betragter e-mail som den første faktor for autentificering, og SMS (eller endda en token-genererende app) som den anden, men i dag er de samlet på én enhed. Det betyder naturligvis, at hvis nogen får fat i din smartphone, vil al denne bekvemmelighed føre til, at vi igen er tilbage på én kanal; denne anden faktor «den, du har» betyder, at du også har den første faktor. Og alt dette beskyttes med en PIN-kode bestående af fire cifre… hvis der overhovedet er en PIN-kode på telefonen. og den var låst.
Ja, den implementerede Google-funktion 2FA leverer bestemt ekstra beskyttelse, men den er ikke beskyttet «mod dummies», og den afhænger bestemt ikke af to helt autonome kanaler.
Nulstilling via brugernavn versus nulstilling via e-mailadresse
Skal man kun tillade nulstilling via e-mail? Eller skal brugeren have mulighed for også at nulstille med sit navn? Problemet med nulstilling med brugernavn er, at der ikke er nogen måde at underrette brugeren om et forkert brugernavn, uden at afsløre at nogen anden kan have en konto med det navn. I det forrige afsnit sikrede nulstilling via e-mail, at den legitime ejer af denne e-mail altid ville modtage feedback uden offentliggørelse af dens eksistens i systemet. Det er ikke muligt kun at gøre det med brugernavnet.
Så svaret er kort: kun e-mail. Hvis du forsøger at nulstille kun med brugernavnet, vil der opstå tilfælde, hvor brugeren er forvirret over, hvad der er sket, eller for du vil afsløre eksistensen af konti. Ja, det er kun et brugernavn og ikke en e-mail-adresse, og ja, enhver kan vælge et hvilket som helst (tilgængeligt) brugernavn, men der er stadig en stor sandsynlighed for, at du indirekte afslører ejerne af konti på grund af brugernes tendens til at genbruge navne.
Hvad sker der så, når nogen glemmer deres brugernavn? Hvis vi antager, at brugernavnet ikke er straks e-mail-adressen (hvilket ofte er tilfældet), så ligner processen det, der sker ved nulstilling af adgangskoden — indtastning af e-mail-adressen og derefter sending af en besked til denne adresse uden at afsløre dens eksistens. Den eneste forskel er, at denne gang indeholder beskeden kun brugernavnet og ikke en URL til nulstilling af adgangskode. Eller også vil der stå i e-mailen, at der ikke er nogen konto for denne adresse.
Identitetskontrol og nøjagtighed af e-mail-adresser
En central aspekt af nulstilling af adgangskoder, og faktisk måske den vigtigste aspekt er at verificere identiteten af den person, der forsøger at nulstille. Er det faktisk den legitime ejer af kontoen, eller forsøger nogen at hacke den eller påføre ejeren besvær?
Det er tydeligt, at e-mail er den mest bekvemme og udbredte kanal til identitetsbekræftelse. Den er ikke beskyttet mod uforsigtig håndtering ("fra en amatør"), og der er mange tilfælde, hvor det blot at kunne modtage e-mails på kontoejerens adresse ikke er tilstrækkeligt, hvis der kræves en høj grad af sikkerhed i identifikationen (deraf brugen af 2FA), men den er næsten altid startpunktet i nulstillingsprocessen.
Hvis e-mail skal spille en rolle i at sikre tillid, er det første, man skal gøre, at sikre, at e-mailadressen faktisk er korrekt. Hvis nogen har fejlet et tegn, vil nulstillingen tydeligvis ikke starte. E-mail-verifikationsprocessen ved registrering er en pålidelig metode til at kontrollere e-mailadressens rigtighed. Vi har alle set det i praksis: du registrerer dig, du får sendt en e-mail med et unikt URL, som du skal klikke på, hvilket bekræfter, at du faktisk er ejer af denne e-mailkonto. Manglende adgang til systemet, indtil denne proces er afsluttet, sikrer motivationen for at bekræfte adressen.
Som med mange andre aspekter af sikkerhed reducerer en sådan model brugervenligheden i bytte for en højere grad af sikkerhed med hensyn til at have tillid til brugerens identitet. Dette kan være acceptabelt for en hjemmeside, som brugeren sætter stor pris på, og villigt vil tilføje et ekstra skridt i processen (betalte tjenester, bankvirksomhed osv.), men sådanne tiltag kan afskrække brugeren, hvis de ser kontoen som "engangs" og bruger den f.eks. bare som et middel til at kommentere et indlæg.
Identifikation af den, der har initieret nulstillingsprocessen
Det er tydeligt, at der er grunde til ondsindet brug af nulstillingsfunktionen, og angribere kan udnytte den på mange forskellige måder. Et enkelt trick, som vi kan bruge til at bekræfte anmodningens kilde (dette trick virker normalt — er at tilføje anmoders IP-adresse i e-mailen med nulstillingsanmodningen. Dette giver modtageren nogle oplysninger til at identificere anmodningens kilde.
Her er et eksempel fra nulstillingsfunktionen, som jeg i øjeblikket implementerer i ASafaWeb:
Linken «find out more» («Find out more») fører brugeren til en hjemmeside , som giver oplysninger som placering og organisationen bag anmodningen om nulstilling:
Selvfølgelig har enhver, der ønsker at skjule sin identitet, adskillige måder at obfuskere sin reelle IP-adresse på, men dette er en praktisk måde at tilføje delvis identifikation af anmoderen, og i de fleste tilfælde vil det give dig en tilstrækkelig idé om, hvem der foretager anmodningen om nulstilling af adgangskoden.
Underretning om ændringer via e-mail
Dette indlæg er gennemsyret af ét tema — kommunikation; informer kontohaveren så meget som muligt om, hvad der sker på hvert trin af processen, uden at afsløre noget, der kan misbruges. Det samme gælder for situationen, hvor adgangskoden faktisk er blevet ændret — informér kontohaveren!
Årsagerne til at ændre adgangskoden kan komme fra to kilder:
- Ændring af adgangskoden efter login, fordi brugeren ønsker en ny adgangskode
- Nulstilling af adgangskoden uden login, fordi brugeren har glemt den
Selvom dette indlæg hovedsageligt handler om nulstilling, reducerer en underretning i det første tilfælde risikoen for, at nogen ændrer adgangskoden uden at den retmæssige ejer er informeret. Hvordan kan det ske? Et almindeligt scenarie er, at en angriber får adgang til den lovlige ejers password (et genbrugt password, som er blevet lækket fra en anden kilde; et password, der er opnået ved keylogging; et let gættepassword osv.), hvorefter de beslutter at ændre det og derved blokere ejeren. Uden e-mail-besked vil den faktiske ejer ikke vide noget om ændringen af adgangskoden.
Selvfølgelig bør ejeren i tilfælde af nulstilling allerede have igangsat processen selv (eller omgå de identitetsbekræftelsesmetoder, der er beskrevet ovenfor), så ændringen burde ikke overraske ham, men en bekræftelse via e-mail ville være en positiv feedback og en yderligere kontrol. Derudover sikrer det konsistens med det ovenfor beskrevne scenarie.
Åh, og i tilfælde af at det endnu ikke er tydeligt — send ikke den nye adgangskode via e-mail! Det kan få nogle til at grine, men :
Logs, logs, logs og lidt flere logs
Funktionen til nulstilling af adgangskoder er tiltrækkende for angribere: en angriber ønsker enten at få adgang til en anden persons konto eller blot forårsage ulempe for ejeren af kontoen/systemet. Mange af de ovenfor beskrevne metoder kan reducere risikoen for misbrug, men de forhindrer dem ikke, og de vil bestemt ikke stoppe folk i at forsøge at bruge funktionen på en uautoriseret måde.
En absolut uvurderlig praksis til at opdage ondsindet adfærd er logging, og jeg mener meget detaljeret logging. Registrer mislykkede loginforsøg, nulstillingsanmodninger, ændringer af adgangskoder (dvs. når brugeren allerede er logget ind) og næsten alt, der kan hjælpe dig med at forstå, hvad der sker; dette vil være meget nyttigt i fremtiden. Registrer endda separate dele af processen, for eksempel bør en god nulstillingsfunktion inkludere initiativet til at nulstille via hjemmesiden (registrer anmodningen og loginforsøg for nulstilling med et forkert brugernavn eller e-mail), registrer besøget på nulstillings-URL'en (herunder forsøg på at bruge et forkert token), og log derefter succes eller fejl i svaret på det hemmelige spørgsmål.
Når jeg taler om logging, mener jeg ikke kun at registrere faktum om sideindlæsning, men også at indsamle så mange oplysninger som muligt, såfremt de ikke er fortrolige. Folk, venligst undgå at registrere adgangskoder i logs! I logs skal identiteten af den autoriserede bruger registreres (de vil være autoriseret, hvis de ændrer en eksisterende adgangskode eller forsøger at nulstille en anden persons adgangskode efter at være logget ind), enhver brugernavn eller e-mailadresse, de forsøger, samt enhver nulstillings-token, de prøver at bruge. Men det er også værd at registrere aspekter som IP-adresser og, hvis muligt, endda anmodningsoverskrifter. Det giver dig mulighed for at genskabe ikke kun hvad brugeren (eller angriberen) forsøger at gøre, men også hvem de er.
Delegere ansvar til andre udførere.
Hvis du mener, at alt dette udgør en stor arbejdsbyrde, er du ikke alene. At bygge et pålideligt system til kontoadministration er faktisk en kompliceret opgave. Det handler ikke om, at det er teknisk svært; det rummer blot mange nuancer. Det handler ikke kun om nulstilling; der er en hel proces med registrering, sikker opbevaring af adgangskoder, behandling af adskillige forkerte loginforsøg osv. osv. Selvom , er der stadig meget mere, der skal gøres.
I dag findes der mange tredjepartsleverandører, som gerne tager sig af alle besværlighederne og abstraherer alt dette i én administreret service. Blandt disse tjenester er OpenID, OAuth og endda Facebook. Nogle mennesker (OpenID har faktisk vist sig at være meget succesfuld på Stack Overflow), mens andre .
Uden tvivl løser en service som OpenID mange udviklerproblemer, men det er også helt klart, at den tilføjer nye. Spiller de en rolle? Ja, men det er tydeligt, at vi ikke ser massivt brug af tjenester fra autentificeringsudbydere. Banker, flyselskaber og endda butikker — alle implementerer deres eget autentificeringssystem, og det er åbenlyst, at der er meget gode grunde til dette.
Ondsindet nulstilling
En vigtig aspekt af hvert af de nævnte eksempler er, at den gamle adgangskode kun anses for at være ubrugelig efter bekræftelsen af kontoejerens identitet. Det er vigtigt, fordi hvis en konto kunne nulstilles op til uden identitetsbekræftelse, ville det give mulighed for alle mulige ondsindede handlinger.
Her er et eksempel: nogen deltager i budgivning på et auktionssite, og tættere på slutningen af budgivningen blokerer de konkurrenterne ved at starte nulstillingsprocessen, hvilket eliminerer dem fra budgivningen. Det er åbenlyst, at hvis en dårligt designet nulstillingsfunktion kan udnyttes forkert, kan det føre til alvorlige negative konsekvenser. Det er værd at bemærke, at blokering af konti via forkerte loginforsøg er en lignende situation, men det er allerede et emne for et andet indlæg.
Som jeg nævnte før, hvis man giver anonyme brugere mulighed for at nulstille adgangskoden til enhver konto blot ved at kende dens e-mailadresse, så er det en oplagt situation for et 'Denial of Service'-angreb. Det er måske ikke den type, vi plejer at tale om, men der er ikke nogen hurtigere måde at blokere adgangen til en konto på end gennem en dårligt gennemtænkt nulstillingsfunktion. , som vi kender det, men der er ikke nogen hurtigere måde at blokere adgangen til en konto på end gennem en dårligt gennemtænkt nulstillingsfunktion.
Det svageste led
Når vi taler om beskyttelse af én konto, er det hele så fantastisk, men man skal altid huske på økosystemet, der omgiver den konto, man beskytter. Lad mig give et eksempel:
ASafaWeb er hostet på en fantastisk service, der leveres af AppHarbor. Processen for nulstilling af hostingkontoen forløber sådan her:
Trin 1:
Trin 2:
Trin 3:
Trin 4:
Efter at have læst al den forudgående information er det allerede nemt at forstå, hvilke aspekter vi i en ideel verden ville implementere anderledes. Men her vil jeg sige, at hvis jeg offentliggør en hjemmeside som ASafaWeb på AppHarbor, og derefter finder på fremragende hemmelige spørgsmål og svar, tilføjer to-faktor-autentificering og gør alt andet korrekt, fjerner det ikke det faktum, at det svageste led i hele processen vil være i stand til at bryde alt dette. Hvis nogen lykkes med at autentificere sig i AppHarbor ved at bruge mine oplysninger, vil de kunne ændre adgangskoden til enhver ASafaWeb-konto til hvad de ønsker!
Pointen er, at robustheden af beskyttelsesimplementeringen skal betragtes holistisk: man skal modellere truslerne ved hver indgangspunkt i systemet, selvom det er en overfladisk proces, for eksempel login i AppHarbor. Dette bør give mig et godt indblik i, hvor meget arbejde jeg skal investere i nulstillingsprocessen for ASafaWeb.
Sammensæt det hele
Dette indlæg indeholder en stor mængde information, så jeg vil forsøge at koncentrere det i et enkelt visuelt diagram:
Husk på, at der skal føres så detaljere logning som muligt for hver af disse punkter. Det er det hele, det er enkelt!
Resumé
Mit indlæg virker omfattende, men der findes mange ekstra materialer, som jeg kunne inkludere det, men besluttede at frase dette for korthedens skyld: rollen som adresse til den rednings-email, situationen hvor du mister adgangen til den tilknyttede email (for eksempel, hvis du sagde op fra jobbet) og så videre. Som jeg sagde tidligere, er nulstillingsfunktionen ikke så kompleks, men der er mange synspunkter på den.
Selv om nulstilling ikke er så svært, implementeres det ofte forkert. Ovenfor har vi set et par eksempler, hvor implementeringen kan føre til problemer, og der er mange flere præcedenser, hvor fejlagtig nulstilling faktisk forårsagede problemer. Det blev for nylig afsløret, at . Det er et alvorligt negativt resultat!
Så vær forsigtig med dine nulstillingsfunktioner, på forskellige punkter, og når du designer funktionen, skal du ikke tage din sorte hat af, for der er en stor sandsynlighed for, at den vil blive båret af nogen andre!
Annoncering
VDSina tilbyder billige med daglig betaling, hver server er tilsluttet et internet link på 500 megabit og er gratis beskyttet mod DDoS-angreb!
Kilde: habr.com
