Tofaktorautentisering
Alt du leser i berørt identifikasjon på grunnlag av at anmoderen vetHan kjenner e-postadressen sin, vet hvordan han får tilgang til den (dvs. han kjenner e-postpassordet sitt), og vet svarene på sikkerhetsspørsmålene.
«Kunnskap» regnes som én faktor for autentisering; to andre vanlige faktorer er hva du harfor eksempel en fysisk enhet, og hvem du er, som for eksempel fingeravtrykk eller netthinne.
I de fleste tilfeller er biologisk identifikasjon ikke mulig, spesielt når vi snakker om sikkerhet for webapplikasjoner, så tofaktorautentisering (2FA) bruker vanligvis et andre attributt – «noe du har». Et populært alternativ for denne andre faktoren er en fysisk token, for eksempel. :
En fysisk token brukes ofte til autentisering i bedrifts-VPN-er og finansielle tjenester. For å autentisere mot en tjeneste må du bruke både passordet og koden på tokenet (som endres ofte) i kombinasjon med en PIN-kode. I teorien må en angriper kjenne passordet, ha tokenet og også kjenne token-PIN-koden for å bli identifisert. I et scenario med tilbakestilling av passord er selve passordet åpenbart ukjent, men besittelse av tokenet kan brukes til å bevise kontoeierskap. Som med enhver sikkerhetsimplementering, , men det øker definitivt barrieren for å komme inn.
En av hovedutfordringene med denne tilnærmingen er kostnadene og logistikken knyttet til implementeringen. Vi snakker om å overlevere fysiske enheter til hver kunde og lære dem opp i en ny prosess. I tillegg må brukerne ha enheten med seg, noe som ikke alltid er tilfelle med en fysisk token. Et annet alternativ er å implementere en andre autentiseringsfaktor via SMS, som i tilfelle 2FA kan tjene som bevis på at personen som utfører tilbakestillingsprosessen har kontoeierens mobiltelefon. Slik gjør Google det:
Det er også nødvendig å muliggjøre , men dette betyr at neste gang du tilbakestiller passordet ditt, kan mobiltelefonen din bli en ekstra autentiseringsfaktor. La meg demonstrere dette med eksemplet mitt. iPhone av grunner som snart vil bli klare:
Etter å ha identifisert kontoens e-postadresse, fastslår Google at 2FA er aktivert, og vi kan tilbakestille kontoen ved hjelp av bekreftelse som sendes via SMS til kontoeierens mobiltelefon:
Nå må vi velge å starte tilbakestillingsprosessen:
Denne handlingen vil sende en e-post til den registrerte adressen:
Denne e-posten inneholder en URL-adresse for tilbakestilling:
Når du åpner tilbakestillings-URL-en, sendes en SMS, og nettstedet ber deg om å oppgi den:
Dette er SMS-en:
Etter å ha skrevet det inn i nettleseren, går vi tilbake til territoriet for klassisk tilbakestilling av passord:
Dette høres sikkert litt ordrikt ut, og det er det, men skjemaet bekrefter at personen som utfører tilbakestillingen har tilgang til kontoeierens e-postadresse og mobiltelefon. Men det kan være ni ganger sikrere enn å tilbakestille passordet ditt bare via e-post. Det finnes imidlertid problemer ...
Problemet er med smarttelefoner. Enheten vist nedenfor kan bare bekrefte én autentiseringsfaktor – den kan motta SMS, men ikke e-post:
Denne enheten kan imidlertid motta SMS и motta e-poster om tilbakestilling av passord:
Problemet er at vi tenker på e-post som den første autentiseringsfaktoren, og SMS (eller til og med en tokengenererende app) som den andre, men i dag er de kombinert i én enhet. Dette betyr selvfølgelig at hvis noen får tak i smarttelefonen din, kommer all den bekvemmeligheten ned til det faktum at vi er tilbake til én kanal; den andre faktoren «det du har» betyr at du også har den første faktoren. Og alt dette er beskyttet av en enkelt firesifret PIN-kode ... hvis telefonen i det hele tatt har en PIN-kode. и den var blokkert.
Ja, Googles 2FA-funksjon gir absolutt ekstra sikkerhet, men den er ikke idiotsikker, og den er absolutt ikke avhengig av to helt separate kanaler.
Tilbakestill via brukernavn kontra tilbakestill via e-post
Bør tilbakestilling bare tillates via e-postadresse? Eller bør brukeren også kunne tilbakestille via navn? Problemet med tilbakestilling via brukernavn er at det ikke finnes noen måte å varsle brukeren om at brukernavnet er feil. uten å avsløre at noen andre kan ha en konto med det navnet. I forrige avsnitt sørget tilbakestillingen av e-posten for at den rettmessige eieren av den e-postadressen alltid ville motta tilbakemelding uten å offentlig avsløre sin eksistens i systemet. Dette kan ikke gjøres bare med et brukernavn.
Så det korte svaret er bare e-post. Hvis du prøver å tilbakestille med bare brukernavnet, vil det være tilfeller der brukeren er forvirret over hva som skjedde, eller Du vil avsløre eksistensen av kontoer. Ja, det er bare et brukernavn, ikke en e-postadresse, og ja, hvem som helst kan velge et hvilket som helst (tilgjengelig) brukernavn, men det er fortsatt en god sjanse for at du indirekte avslører kontoeiere på grunn av brukernes tendens til å gjenbruke et navn.
Så hva skjer når noen glemmer brukernavnet sitt? Forutsatt at brukernavnet ikke også er e-postadressen (noe som ofte er tilfelle), ligner prosessen på hvordan en tilbakestilling av passord starter – skriv inn en e-postadresse, og send deretter en melding til den adressen uten å avsløre dens eksistens. Den eneste forskjellen er at denne gangen inneholder meldingen bare brukernavnet, ikke URL-adressen for tilbakestilling av passord. Enten det, eller så vil e-posten si at det ikke finnes noen konto for den adressen.
Verifisering av identitet og nøyaktighet av e-postadresser
Et viktig aspekt ved tilbakestilling av passord, og kanskje til og med mest Det viktigste er å bekrefte identiteten til personen som prøver å tilbakestille kontoen. Er dette virkelig den rettmessige eieren av kontoen, eller er det noen som prøver å hacke den eller forårsake problemer for eieren?
E-post er åpenbart den mest praktiske og vanligste kanalen for identitetsverifisering. Det er ikke idiotsikkert, og det finnes mange tilfeller der det ikke er nok å bare kunne motta e-poster til kontoeierens adresse hvis en høy grad av identifikasjon er nødvendig (derav bruken av 2FA), men det er nesten alltid utgangspunktet for tilbakestillingsprosessen.
Hvis e-post skal spille en rolle i å gi trygghet, er det første trinnet å sørge for at e-postadressen faktisk er riktig. Hvis noen staver et tegn feil, vil tilbakestillingen åpenbart ikke skje. E-postbekreftelsesprosessen ved registrering er en pålitelig måte å bekrefte at adressen er riktig. Vi har alle sett det i praksis: du registrerer deg, de sender deg en e-post med en unik URL som du klikker på, som bekrefter at du faktisk er eieren av den e-postkontoen. Hvis man ikke kan logge inn før prosessen er fullført, sikrer det at det er et insentiv til å bekrefte adressen.
Som med mange andre aspekter ved sikkerhet, går denne modellen på bekostning av brukervennlighet i bytte mot økt sikkerhet i forhold til brukerens tillit til sin identitet. Dette kan være akseptabelt for et nettsted der brukeren verdsetter registrering høyt og gjerne legger til et nytt trinn i prosessen (betalte tjenester, banktjenester osv.), men det kan være avskrekkende for brukeren hvis de oppfatter kontoen som en «engangskonto» og for eksempel bare bruker den som et middel til å kommentere et innlegg.
Identifisere hvem som startet tilbakestillingsprosessen
Det finnes åpenbart grunner til ondsinnet bruk av tilbakestillingsfunksjonen, og det finnes mange forskjellige måter angripere kan utnytte den på. Et enkelt triks vi kan bruke for å bekrefte kilden til en forespørsel (dette trikset vanligvis (fungerer) er et tillegg til et brev med et forslag om å tilbakestille IP-adressen til forespørselen. Dette gir mottakeren noen informasjon for å identifisere kilden til forespørselen.
Her er et eksempel fra tilbakestillingsfunksjonen jeg for tiden bygger inn i ASafaWeb:
Lenken «finn ut mer» tar brukeren til nettstedet , som gir informasjon som plassering og organisasjon til personen som ber om tilbakestillingen:
Selvfølgelig har alle som ønsker å skjule identiteten sin mange måter å tilsløre sin virkelige IP-adresse på, men dette er en praktisk måte å legge til delvis identifikasjon av den som ber om det, og i mest I noen tilfeller vil dette gi deg en god ide om hvem som vil sende forespørselen om tilbakestilling av passord.
Varsling om endringer via e-post
Dette innlegget handler om ett tema: kommunikasjon; hold kontoeieren så informert som mulig om hva som skjer i hvert trinn av prosessen uten å avsløre noe som kan brukes til ondsinnede formål. Det samme gjelder når passordet faktisk endres – Rapporter dette til eieren!
Det er to mulige grunner til å endre passordet ditt:
- Endre passord etter innlogging fordi brukeren ønsker nytt passord
- Tilbakestill passord uten å logge inn fordi brukeren glemte det
Selv om dette innlegget primært handler om tilbakestillinger, reduserer varsling i det første tilfellet risikoen for at noen endrer passordet uten den rettmessige eierens viten. Hvordan kan dette skje? Et veldig vanlig scenario er når den rettmessige eierens passord blir innhentet (et gjenbrukt passord lekket fra en annen kilde, et passord innhentet gjennom keylogging, et passord som er lett å gjette osv.) og en angriper bestemmer seg for å endre det, og dermed stenge ute eieren. Uten e-postvarsling vil ikke den rettmessige eieren vite om passordendringen.
Ved tilbakestilling av passord må eieren selvsagt allerede ha startet prosessen selv (eller omgått verktøyene for identifikasjonsverifisering beskrevet ovenfor), slik at endringen bør ikke være en overraskelse for ham, men bekreftelses-e-posten vil være positiv tilbakemelding og en ekstra sjekk. Det sikrer også samsvar med scenariet beskrevet ovenfor.
Å, og i tilfelle det ikke var åpenbart ennå - Ikke send det nye passordet ditt på e-post! Dette kan kanskje få noen til å le, men :
Logger, logger, logger og noen flere logger
Funksjonen for tilbakestilling av passord er attraktiv for angripere: angriperen ønsker enten å få tilgang til en annen persons konto, eller rett og slett å være til bry for konto-/systemeieren. Mange av fremgangsmåtene beskrevet ovenfor reduserer sannsynligheten for misbruk, men de forhindrer det ikke, og de hindrer absolutt ikke folk i å prøve å bruke funksjonen på måter de ikke hadde til hensikt.
Logging er en helt uvurderlig praksis for å oppdage ondsinnet oppførsel, og med det mener jeg svært detaljert loggingLogg mislykkede påloggingsforsøk, tilbakestilling av passord, passordendringer (dvs. når brukeren allerede er logget inn) og stort sett alt som kan hjelpe deg å forstå hva som skjer; det vil være veldig nyttig i fremtiden. Logg selv individuelle deler prosess, for eksempel, bør en god tilbakestillingsfunksjon inkludere å starte tilbakestillingen via nettstedet (logge forespørselen og innloggingsforsøkene for å tilbakestille med et ugyldig brukernavn eller e-postadresse), logge besøket til nettstedet til tilbakestillings-URL-en (inkludert forsøk på å bruke et ugyldig token), og deretter logge om svaret på det hemmelige spørsmålet var vellykket eller mislykket.
Når jeg snakker om logging, mener jeg ikke bare å registrere at en side har lastet inn, men også å samle inn så mye informasjon som mulig, hvis det ikke er konfidensieltGutter, Vennligst ikke skriv passord i logger! Loggene må registrere identiteten til den autoriserte brukeren (han vil bli autorisert hvis han endrer eksisterende passord eller prøver å tilbakestille noen andres passord etter innlogging), eventuelle brukernavn eller e-postadresser den prøver, pluss eventuelle tilbakestillingstokener den prøver. Men det er også verdt å logge ting som IP-adresser og, om mulig, til og med forespørselsoverskrifter. Dette lar deg rekonstruere ikke bare at brukeren (eller angriperen) prøver å gjøre, men også som Han er sånn.
Delegering av ansvar til andre utøvere
Hvis du synes alt dette er mye arbeid, er du ikke alene. Faktisk er det ikke lett å bygge et robust kontoadministrasjonssystem. Det er ikke det at det er teknisk vanskelig, det er bare at det har mange funksjoner. Det handler ikke bare om tilbakestilling, det er en hel registreringsprosess, sikker passordlagring, håndtering av flere mislykkede innloggingsforsøk, osv., osv. Selv om , i tillegg til dette, må mye mer gjøres.
I dag finnes det en mengde tredjepartsleverandører som gjerne tar bort alt bryderiet og samler alt i én enkelt, håndterbar tjeneste. Disse inkluderer OpenID, OAuth og til og med Facebook. Noen mennesker (OpenID har riktignok vist seg å være svært vellykket på Stack Overflow), men andre .
Det er ingen tvil om at en tjeneste som OpenID løser mange problemer for utviklere, men det er heller ingen tvil om at den introduserer nye. Spiller de en rolle? Ja, men det er tydelig at vi ikke ser masseadopsjon av leverandører av autentiseringstjenester. Banker, flyselskaper og til og med butikker implementerer alle sin egen autentiseringsmekanisme, og det er åpenbart svært gode grunner til dette.
Ondsinnet dumping
Det viktige aspektet ved hvert av eksemplene ovenfor er at det gamle passordet bare anses som ubrukelig etter å ha bekreftet kontoinnehaverens identitetDette er viktig fordi hvis kontoen kunne tilbakestilles til identifikasjonskontroller, ville dette gi mulighet for alle slags ondsinnede handlinger.
Her er et eksempel: noen byr på en auksjonsside, og mot slutten av budgivningsprosessen blokkerer de konkurrenter ved å starte en tilbakestillingsprosess, og eliminerer dem dermed fra budgivningen. Det er klart at hvis en dårlig utformet tilbakestillingsfunksjon kan utnyttes feil, kan det føre til alvorlige negative resultater. Det er verdt å merke seg at kontoutestengelser på grunn av ugyldige innloggingsforsøk er en lignende situasjon, men det er et tema for et annet innlegg.
Som jeg sa ovenfor, er det å gi anonyme brukere muligheten til å tilbakestille passordet til en hvilken som helst konto bare ved å vite e-postadressen en moden situasjon for et tjenestenektangrep. Det er kanskje ikke den , som vi er vant til å snakke om, men det finnes ingen raskere måte å blokkere tilgang til en konto på enn med en dårlig utformet funksjon for tilbakestilling av passord.
Det svakeste leddet
Fra et perspektiv for beskyttelse av én konto er alt det ovennevnte flott, men du må alltid være oppmerksom på økosystemet rundt kontoen du beskytter. La meg gi deg et eksempel:
ASafaWeb hostes på den fantastiske tjenesten AppHarbor. Prosessen for å tilbakestille hostingkontoen din er som følger:
Trinn 1:
Trinn 2:
Trinn 3:
Trinn 4:
Etter å ha lest all informasjonen ovenfor, er det lett å se hvilke aspekter vi ville gjort litt annerledes i en perfekt verden. Det jeg imidlertid vil si her er at hvis jeg publiserer et nettsted som ASafaWeb til AppHarbor, og deretter kommer opp med gode sikkerhetsspørsmål og svar, legger til en ekstra autentiseringsfaktor, og gjør alt annet etter boken, endrer ikke det det faktum at det svakeste leddet i hele prosessen vil være i stand til å bryte det hele. Hvis noen autentiserer seg til AppHarbor ved hjelp av min informasjon, kan de endre passordet til en hvilken som helst ASafaWeb-konto til hva de vil!
Poenget er at styrken til sikkerhetsimplementeringen bør vurderes helhetlig: du må modellere truslene mot hvert inngangspunkt i systemet, selv om det er en overfladisk prosess, som å logge inn i AppHarbor. Dette burde gi meg en god idé om hvor mye innsats jeg må legge ned i ASafaWeb-passordtilbakestillingsprosessen.
Setter det hele sammen
Dette innlegget inneholder mye informasjon, så jeg vil kondensere det til et enkelt visuelt diagram:
Husk å loggføre hver av disse elementene så detaljert som mulig. Det er det, så enkelt er det!
Resultater av
Innlegget mitt virker utfyllende, men det er mye tilleggsstoff som jeg kunne inkludere, men bestemte meg for å utelate det for korthets skyld: rollen til rednings-e-postadressen, situasjonen der du mister tilgangen til e-postadressen som er knyttet til kontoen (for eksempel hvis du slutter i jobben), og så videre. Som jeg sa tidligere, er ikke tilbakestillingsfunksjonen så komplisert, det er bare det at det finnes mange synspunkter på den.
Selv om tilbakestilling ikke er så komplisert, implementeres det ofte feil. Vi har sett et par eksempler ovenfor der implementeringen kan føre til problemer, og det finnes mange flere eksempler der en feil tilbakestilling virkelig forårsaket problemer. Det ble nylig avslørt at Dette er et alvorlig negativt resultat!
Så vær forsiktig med tilbakestillingsfunksjonene dine, på forskjellige punkter, og når du designer en funksjon, ikke ta av deg den svarte hatten, for det er stor sjanse for at noen andre tar den på!
Om rettighetene til annonsering
VDSina tilbyr rimelig Med daglig betaling er hver server koblet til en 500 Mbps internettkanal og er beskyttet mot DDoS-angrep gratis!
Kilde: www.habr.com
