Allt du ville veta om säker återställning av lösenord. Del 2

Tvåfaktorsautentisering

Allt som ni har läst i första delen handlade om identifiering baserat på vad den som begär känner till. De vet sin e-postadress, vet hur man får åtkomst till den (d.v.s. vet sitt e-postlösenord) och känner till svaren på hemliga frågor.

«Kännedom» betraktas som en autentiseringsfaktor; två andra vanliga faktorer är vad ni har, till exempel en fysisk enhet, och vem ni är, till exempel fingeravtryck eller näthinna.

I de flesta fall är det svårt att genomföra biologisk identifiering, särskilt när vi pratar om säkerheten för webbapplikationer, därför används vanligtvis den andra attributet i tvåfaktorsautentisering (two factor authentication, 2FA) — "vad ni har". En populär variant av denna andra faktor är en fysisk token, till exempel, RSA SecurID:

En fysisk token används ofta för autentisering i företags VPN och finansiella tjänster. För autentisering i tjänsten måste ni använda både lösenord och koden på token (som ofta ändras) i kombination med en PIN-kod. Teoretiskt sett, för att identifiera en angripare måste denne veta lösenordet, ha token och också känna till tokenens PIN-kod. I ett scenario för återställning av lösenord är själva lösenordet uppenbarligen okänt, men innehav av token kan användas för att bekräfta ägarskapet av kontot. Självklart erbjuder detta, som med alla skyddsmekanismer, inte "foolproof" skydd, men ökar definitivt inträdesbarriären.

Ett av de främsta problemen med denna metod är kostnaden och logistiken för att genomföra; vi talar om att ge fysiska enheter till varje kund och utbilda dem i den nya processen. Dessutom måste användarna ha enheten med sig, vilket i fallet med en fysisk token inte alltid är möjligt. Ett annat alternativ är att genomföra den andra autentiseringsfaktorn med hjälp av SMS, som i fallet med 2FA kan fungera som bekräftelse på att den som genomför återställningsprocessen har ägarens mobiltelefon. Så här gör Google:

Det är också nödvändigt att aktivera tvåstegsverifiering, men det innebär att din mobiltelefon vid nästa återställning av lösenordet kan bli en andra autentiseringsfaktor. Låt mig demonstrera detta med min iPhone av skäl som snart kommer att bli uppenbara:

Efter att e-postadressen till Google-kontot har identifierats upptäcker systemet att 2FA har aktiverats och vi kan återställa kontot genom en verifiering som skickas via SMS till kontoinnehavarens mobiltelefon:

Nu behöver vi välja att påbörja återställningsprocessen:

Denna åtgärd leder till att ett e-postmeddelande skickas till den registrerade adressen:

Detta meddelande innehåller en återställnings-URL:

Vid åtkomst av återställnings-URL:en skickas ett SMS och webbplatsen ber om att det ska anges:

Här är detta SMS:

När vi anger det i webbläsaren återvänder vi till den klassiska återställningen av lösenord:

Det verkar kanske något omständligt, och det är det, men formuläret bekräftar att den som återställer har tillgång till både kontoinnehavarens e-postadress och mobiltelefon. Men detta kan vara nio gånger säkrare än att bara återställa lösenordet via e-post. Det finns dock problem...

Problemet rör smartphones. Enheten som visas nedan kan verifiera endast en autentiseringsfaktor — den kan ta emot SMS, men inte e-post:

Men denna enhet kan ta emot SMS och ta emot e-postmeddelanden om återställning av lösenord:

Problemet är att vi betraktar e-posten som den första autentiseringsfaktorn, och SMS (eller till och med en app som genererar tokens) som den andra, men idag är de sammanslagna i en enhet. Det betyder naturligtvis att om någon får tag på din smartphone, så minimeras allt detta bekvämlighet till att vi åter är tillbaka till en kanal; den andra faktorn “något du har” innebär att du också har den första faktorn. Och allt detta skyddas av en fyrsiffrig PIN-kod… om telefonen ens har en PIN-kod och den var låst.

Ja, den implementerade Google-funktionen 2FA ger helt klart ett ytterligare skydd, men den skyddar inte mot 'dumheter', och den beror absolut inte på två helt fristående kanaler.

Återställning via användarnamn mot återställning via e-postadress

Ska man tillåta återställning endast via e-postadress? Eller ska användaren kunna återställa även med användarnamn? Problemet med att återställa med användarnamn är att det inte finns något sätt att informera användaren om ett felaktigt användarnamn, utan att avslöja att någon annan kan ha ett konto med det namnet. I föregående avsnitt garanterade återställning via e-post att den legitima ägaren av denna e-post alltid skulle få feedback utan att offentligt avslöja sin existens i systemet. Med hjälp av endast användarnamnet är detta omöjligt.

Så svaret är enkelt: endast e-post. Om du försöker återställa endast med hjälp av användarnamn, kommer det att uppstå situationer där användaren undrar vad som har hänt, eller du kommer att avslöja existensen av konton. Ja, det är bara ett användarnamn, inte en e-postadress och ja, vem som helst kan välja vilket (tillgängligt) användarnamn som helst, men det finns fortfarande en stor risk att du indirekt avslöjar kontoinnehavarna på grund av användarnas benägenhet att återanvända namn.

Vad händer då när någon glömmer sitt användarnamn? Om vi antar att användarnamnet inte är samma som e-postadress (vilket ofta är fallet), så liknar processen hur återställning av lösenord börjar - vi anger e-postadressen och skickar sedan ett meddelande till denna adress utan att avslöja dess existens. Den enda skillnaden är att detta meddelande bara innehåller användarnamnet, inte en URL för återställning av lösenord. Antingen det, eller så står det i e-postmeddelandet att det inte finns något konto för denna adress.

Identitetsverifiering och noggrannhet av e-postadresser

En avgörande aspekt av lösenordsåterställningar, och kanske den mest avgörande aspekten är verifiering av identiteten hos personen som försöker återställa. Är det verkligen den legitima ägaren av kontot, eller är det någon som försöker hacka eller orsaka besvär för ägaren?

Det är uppenbart att e-post är den mest bekväma och vanligaste kanalen för identitetsverifiering. Den är inte skyddad mot klumpigt handhavande ("från en idiot"), och det finns många fall där den enkla möjligheten att ta emot mejl på en kontoinnehavares adress inte är tillräcklig, om en hög grad av säkerhet i identifieringen krävs (därför används 2FA). Men nästan alltid är det en utgångspunkt för återställningsprocessen.

Om e-post ska spela en roll för att säkerställa tillfredsställelse, är det första steget att se till att e-postadressen faktiskt är korrekt. Om någon gör ett fel tecken, kommer återställning uppenbarligen inte att påbörjas. Processen för verifiering av e-post vid registrering är ett tillförlitligt sätt att kontrollera att adressen är korrekt. Vi har alla sett det i praktiken: du registrerar dig, ett mejl med en unik URL skickas till dig, som du måste klicka på, vilket bekräftar att du verkligen är ägaren av den här e-postadressen. Oförmåga att logga in förrän denna process är slutförd garanterar att det finns motivation för att bekräfta adressen.

Som med många andra aspekter av säkerhet, minskar en sådan modell användarvänligheten för att säkerställa en högre grad av säkerhet angående användarens identitet. Detta kan vara acceptabelt för en webbplats där användaren värdesätter registreringen högt och gärna lägger till ytterligare ett steg i processen (betjänade tjänster, bankverksamhet, etc.), men sådana åtgärder kan avskräcka användaren om de ser sitt konto som "engångs" och till exempel bara använder det som ett sätt att kommentera ett inlägg.

Identifiering av vem som initierade återställningsprocessen

Det är uppenbart att det finns skäl till skadlig användning av återställningsfunktionen, och angripare kan använda den på många olika sätt. Ett enkelt trick som vi kan använda för att hjälpa till att bekräfta källan till begäran (detta trick fungerar vanligtvis och går ut på) att inkludera IP-adressen för den som begärde i mejlet med återställningserbjudandet. Detta ger mottagaren en viss information för att identifiera källan till begäran.

Här är ett exempel från en återställningsfunktion som jag för närvarande integrerar i ASafaWeb:

Länken "find out more" ("Läs mer") tar användaren till webbplatsen ip-adress.com, som ger information som plats och organisation av den som begär omställning:

Naturligtvis har alla som vill dölja sin identitet många sätt att maskera sin verkliga IP-adress, men detta är ett praktiskt sätt att lägga till delvis identifiering av den som begär, och i de flesta många fall kommer det att ge dig en bra uppfattning om vem som gör begäran om lösenordsåterställning.

E-postavisering om ändringar

Detta inlägg genomsyras av ett tema – kommunikation; informera kontoinnehavaren så mycket som möjligt om vad som händer i varje steg av processen, utan att avslöja något som kan användas i ond tro. Detta gäller även situationen när lösenordet faktiskt har ändrats – informera kontoinnehavaren om detta!

Orsakerna till att byta lösenord kan komma från två källor:

1. Byte av lösenord efter inloggning eftersom användaren vill ha ett nytt lösenord
2. Återställning av lösenord utan inloggning eftersom användaren har glömt det

Även om detta inlägg huvudsakligen handlar om återställning, minskar aviseringen i det första fallet risken för att någon ändrar lösenordet utan att den legitima ägaren är medveten om det. Hur kan detta hända? Ett mycket vanligt scenario är att en illvillig aktör får tag på ägarens lösenord (ett återanvänt lösenord som läckt från en annan källa; ett lösenord som fångats av tangentbordslogger; ett lätt gissat lösenord etc.), och då bestämmer sig för att ändra det, vilket låser ägaren ute. Utan e-postavisering kommer den verkliga ägaren inte att veta om lösenordsbytet.

Självklart, i händelse av en lösenordsåterställning bör ägaren redan ha initierat processen själv (eller kringgått de nämnda identitetskontrollmetoderna), så bytet bör inte vara en överraskning för honom, men en bekräftelse via e-post skulle vara positiv feedback och en extra kontroll. Dessutom säkerställer detta konsistens med det tidigare beskrivna scenariot.

Och för att det inte ska vara otydligt – skicka inte det nya lösenordet via e-post! Detta kan få någon att skratta, men sådant händer:

Loggar, loggar, loggar och lite mer loggar

Funktionen för återställning av lösenord är attraktiva för illvilliga aktörer: en angripare vill ha åtkomst till någon annans konto, eller så vill de helt enkelt orsaka besvär för kontoinnehavaren/systemet. Många av de ovan beskrivna metoderna kan minska risken för missbruk, men de förhindrar dem inte, och de kommer definitivt inte att stoppa folk från att försöka använda funktionen på ett otillåtet sätt.

En ovärderlig praxis för att upptäcka illvilligt beteende är loggning, och jag menar mycket detaljerad loggning. Logga misslyckade inloggningsförsök, återställningar av lösenord, ändringar av lösenord (d.v.s. när användaren redan är inloggad) och praktiskt taget allt som kan hjälpa dig att förstå vad som händer; detta kommer att vara mycket användbart i framtiden. Logga även individuella delar av processen, exempelvis bör en bra återställningsfunktion inkludera initiering av återställning via webbplatsen (logga begäran och inloggningsförsök för återställning med felaktigt användarnamn eller e-post), logga besök på webbsidan enligt URL:en för återställning (inklusive försök att använda en ogiltig token), och sedan logga om svar på säkerhetsfrågan var korrekt eller inte.

När jag pratar om loggning menar jag inte bara registreringen av att en sida har laddats, utan att samla så mycket information som möjligt, om den inte är konfidentiell. Hörni, vänligen skriv inte ner lösenord i loggar! I loggarna bör identiteten på den inloggade användaren registreras (han kommer att vara inloggad om han ändrar ett befintligt lösenord eller försöker återställa någon annans lösenord efter inloggning), alla användarnamn eller e-postadresser som han försöker samt vilka återställningstoken han försöker använda. Men det kan också vara nyttigt att logga sådana aspekter som IP-adresser och, om möjligt, även begärhuvuden. Detta gör att du kan återskapa inte bara vad vad användaren (eller angriparen) försöker göra, utan även vem vem han är.

Delegation av ansvar till andra aktörer

Om du tycker att allt detta verkar vara en enorm mängd arbete, så är du inte ensam. Att bygga ett pålitligt system för kontohantering är faktiskt en tuff uppgift. Det handlar inte bara om den tekniska svårigheten, utan det finns många aspekter att ta hänsyn till. Det handlar inte bara om att återställa, det finns en hel process för registrering, säker lagring av lösenord, hantering av flera misslyckade inloggningsförsök osv. Jag främjar idén om att använda färdiga lösningar som ASP.NET membership provider, men det finns fortfarande mycket mer att göra.

Idag finns det många tredjepartsleverantörer som gärna tar på sig allt besvär och abstraherar allt detta till en hanterad tjänst. Bland sådana tjänster finns OpenID, OAuth och till och med Facebook. Vissa människor har en gränslös tro på denna modell (OpenID har faktiskt visat sig vara väldigt framgångsrik på Stack Overflow), men andra ser den bokstavligen som en mardröm.

Utan tvekan löser tjänster som OpenID många problem för utvecklare, men det är också uppenbart att de tillför nya. Har de någon betydelse? Ja, men det är tydligt att vi inte ser massanvändning av autentiseringstjänster. Banker, flygbolag och till och med butiker — alla implementerar sina egna autentiseringsmekanismer, vilket uppenbarligen har mycket starka skäl.

Skadlig återställning

En viktig aspekt av varje av de tidigare nämnda exemplen är att det gamla lösenordet betraktas som värdelöst först efter att identiteten hos kontoinnehavaren har bekräftats. Detta är viktigt eftersom om ett konto kunde återställas till utan identitetsverifiering, skulle det möjliggöra alla möjliga skadliga handlingar.

Här är ett exempel: någon deltar i budgivning på en auktionssajt, och när budgivningen börjar närma sig sitt slut blockerar de sina konkurrenter genom att påbörja återställningsprocessen, vilket på så sätt eliminerar dem från budgivningen. Uppenbart, om en dåligt utformad återställningsfunktion kan utnyttjas på fel sätt, kan det leda till allvarliga negativa konsekvenser. Det bör noteras att kontoblockering genom flera misslyckade inloggningsförsök är en liknande situation, men det är ett ämne för ett annat inlägg.

Som jag nämnde tidigare, om man ger anonyma användare möjlighet att återställa lösenord för vilken konto som helst bara genom att känna till e-postadressen, så är det en perfekt situation för en "överbelastningsattack". Det här kanske inte är den DoS, som vi är vana vid att diskutera, men det finns inget snabbare sätt att blockera åtkomsten till ett konto än med en dåligt tänkt återställningsfunktion.

Den svagaste länken

Ur perspektivet av att skydda ett konto är allt ovanstående utmärkt, men man måste alltid tänka på ekosystemet som omger det skyddade kontot. Låt mig ge ett exempel:

ASafaWeb är värd på en fantastisk tjänst som tillhandahålls av AppHarbor. Återställningsprocessen för kontot i hostingtjänsten går till så här:

Steg 1:

Steg 2:

Steg 3:

Steg 4:

Efter att ha läst all tidigare information är det redan lätt att förstå vilka aspekter som vi skulle genomföra annorlunda i en perfekt värld. Men här vill jag säga att om jag skulle publicera en webbplats liknande ASafaWeb på AppHarbor och sedan komma på utmärkta hemliga frågor och svar, lägga till tvåfaktorsautentisering och göra allt annat enligt reglerna, så avskaffar det inte det faktum att den svagaste länken i hela processen fortfarande kan bryta ner allt detta. Om någon framgångsrikt autentiserar sig på AppHarbor med min information, så kan de ändra lösenordet för vilket konto som helst på ASafaWeb!

Poängen är att robustheten i säkerhetsimplementeringen bör betraktas helhetsmässigt: man måste modellera hoten från varje ingångspunkt till systemet, även om det är en ytlig process som att logga in på AppHarbor. Detta bör ge mig en god uppfattning om hur mycket arbete jag behöver lägga ner i återställningsprocessen för lösenordet på ASafaWeb.

Sammanfoga allt

Detta inlägg innehåller mycket information, så jag vill sammanfatta det i ett enkelt visuellt schema:

Kom ihåg att man bör utföra så detaljerad loggning som möjligt av var och en av dessa punkter. Det är allt, det är enkelt!

Sammanfattning

Mitt inlägg verkar vara omfattande, men det finns många ytterligare material som jag skulle kunna inkludera det, men beslutade att avstå från detta för korthetens skull: rollen av adressen för räddande e-post, en situation där du förlorar tillgång till den e-post som är kopplad till kontot (till exempel om du slutade på jobbet) och så vidare. Som jag sa tidigare, är återställningsfunktionen inte så komplicerad, det finns bara många synpunkter på den.

Trots att återställningen inte är så svår, implementeras den ofta felaktigt. Ovan såg vi ett par exempel på när implementeringen hantera plötsliga kraschar och visa användbara detaljer för felsökning, som stacktrace. Att skicka felmeddelanden har förenklats — det räcker att klicka på länken. ledde till problem, och det finns mycket fler exempel där felaktig återställning verkligen orsakade problem. Nyligen avslöjades det att återställning av lösenord har använts för att stjäla bitcoins till ett värde av 87 000 dollar.Det här är ett allvarligt negativt resultat!

Därför, var försiktig med dina återställningsfunktioner, modellera hot på olika punkter, och när du designar funktionen, ta inte av din svarta hatt, för det finns en stor sannolikhet att någon annan kommer att ta på sig den!

I reklamens namn

VDSina erbjuder prisvärda servrar för uthyrning med daglig betalning, varje server är ansluten till en internetkanal på 500 Megabit och är gratis skyddad mot DDoS-attacker!

Källa: habr.com