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

Nyligen fick jag tid att fundera på hur funktionen för säker lösenordsåterställning bör fungera, först när jag integrerade den här funktionen i ASafaWeb, och sedan när jag hjälpte en annan person att göra något liknande. I det andra fallet ville jag ge honom en länk till en kanonisk resurs med alla detaljer om säker implementering av återställningsfunktionen. Problemet är att en sådan resurs inte existerar, åtminstone ingen som beskriver allt som jag anser vara viktigt. Därför beslutade jag mig för att skriva den själv.

Ser ni, världen av bortglömda lösenord är faktiskt ganska mystisk. Det finns många olika, helt rimliga ståndpunkter och en hel del som är ganska farliga. Det är troligt att ni har stött på några av dessa som slutanvändare flera gånger; därför kommer jag försöka använda dessa exempel för att visa vem som gör allt rätt, vem som inte gör det och vad man bör fokusera på för att korrekt implementera funktionen i sin applikation.

Lösenordshantering: hashning, kryptering och (åh!) klartext

Vi kan inte diskutera vad man ska göra med bortglömda lösenord innan vi diskuterar hur de ska lagras. I databasen lagras lösenorden i en av tre huvudtyper:

1. Klartext. Det finns en kolumn med lösenordet som lagras i vanlig text.
2. Krypterat. Vanligtvis med symmetrisk kryptering (en nyckel används både för kryptering och dekryptering), och de krypterade lösenorden lagras också i en kolumn.
3. Hashat. En en-vägs process (lösenord kan hashats, men inte dekrypteras); lösenordet, man kan hoppas, åtföljs av en salt, och var och en lagras i sin egen kolumn.

Låt oss gå direkt till den enklaste frågan: lagra aldrig lösenord i klartext! Aldrig. En enda sårbarhet för injektion, en vårdslöst gjord säkerhetskopia eller ett av tiotals andra enkla misstag — och det är över, game over, alla era lösenord — förlåt, lösenorden för alla era kunder blir offentliga. Naturligtvis skulle detta innebära en enorm risk att alla deras lösenord från alla deras konton i andra system blir offentliga. Och det blir ditt fel. från alla deras konton i andra system. Och det skulle vara ditt fel.

Kryptering är bättre, men har sina svagheter. Problemet med kryptering ligger i dekrypteringen; man kan ta dessa galet utseende kryptor och omvandla dem tillbaka till vanlig text, och när detta sker, hamnar vi tillbaka i situationen med läsbara lösenord. Hur sker det? En liten svaghet infiltrerar koden som hanterar dekrypteringen av lösenordet, vilket gör det offentligt tillgängligt — det är ett sätt. Hackare får tillgång till maskinen där de krypterade uppgifterna lagras — det är det andra sättet. Ett tredje sätt är att en säkerhetskopia av databasen stjäls, och någon får även krypteringsnyckeln, som ofta lagras mycket osäkert.

Och det leder oss till hashning. Idén med hashning är att den utförs i en riktning; det enda sättet att jämföra det lösenord som användaren anger med dess hashade version är att hash användarens inmatning och jämföra dem. För att förhindra attacker med verktyg som "regnbågsbord", lägger vi till randomness i processen med hjälp av salt (för en fullständig bild, läs min inlägg om kryptografisk lagring). I slutändan, med en korrekt implementering, kan vi med stor säkerhet säga att hashade lösenord aldrig igen blir vanlig text (om fördelarna med olika hashalgoritmer kommer jag att berätta i ett annat inlägg).

Ett kort argument om hashning och kryptering: den enda anledningen till att du någonsin skulle behöva kryptera istället för att hash ett lösenord är när du behöver se lösenordet i vanlig text, och det borde du aldrig vilja, åtminstone i en standardwebbplats-situation. Om du behöver det är det troligt att du gör något fel!

Varning!

Lite längre ner i inlägget finns en del av en skärmdump från den pornografiska webbplatsen AlotPorn. Den är prydligt beskuren, och det finns ingenting som är osynligt på stranden, men om det kan orsaka några problem, scrolla då inte ner på sidan.

Återställ alltid lösenordet, aldrig påminn det inte

Har du någonsin blivit ombedd att skapa en funktion för påminnelse Lösenord? Ta ett steg tillbaka och tänk på denna begäran ur motsatt perspektiv: varför behöver vi denna "påminnelse"? För att användaren har glömt sitt lösenord. Vad vill vi egentligen åstadkomma? Hjälpa dem att logga in igen.

Jag förstår att ordet "påminnelse" används (ofta) i ett vardagligt sammanhang, men vi försöker faktiskt tryggt hjälpa användaren att återfå tillgång online. Eftersom vi behöver säkerhet finns det två skäl till varför påminnelsen (dvs. att skicka användarens lösenord) inte är lämplig:

1. E-post är en osäker kanal. Precis som vi inte skulle överföra något konfidentiellt via HTTP (vi skulle använda HTTPS), bör vi inte skicka något via e-post eftersom dess transportlager är osäkert. Faktum är att detta är mycket värre än att bara överföra information via ett oskyddat transportprotokoll, eftersom e-post ofta lagras på lagringsmedia, är tillgänglig för systemadministratörer, vidarebefordras och sprids, och är tillgänglig för skadlig programvara, och så vidare. Oenkrypterad e-post är en extremt osäker kanal.
2. Du bör i vilket fall som helst inte ha tillgång till lösenordet. Läs igenom föregående avsnitt om lagring - du bör ha en hash av lösenordet (med en bra salt), vilket innebär att du på inget sätt bör kunna extrahera lösenordet och skicka det via e-post.

Låt mig demonstrera problemet med ett exempel usoutdoor.com: Här är en typisk inloggningssida:

Den första uppenbara problematiken är att inloggningssidan inte laddas via HTTPS, men webbplatsen erbjuder dessutom att skicka lösenordet ("Send Password"). Det kan vara ett exempel på den tidigare nämnda vardagliga användningen av termen, så låt oss ta ett steg till och se vad som händer:

Det ser tyvärr inte mycket bättre ut; och e-post bekräftar att det finns ett problem:

Detta berättar för oss två viktiga aspekter av usoutdoor.com:

1. Webbplatsen hashar inte lösenord. Som bäst är de krypterade, men det är troligt att de lagras i klartext; vi ser inget som motsäger detta.
2. Webbplatsen skickar ett långvarigt lösenord (vi kan gå tillbaka och använda det gång på gång) via en osäker kanal.

Efter att ha tagit itu med detta behöver vi kontrollera att återställningsprocessen sker på ett säkert sätt. Först och främst måste vi säkerställa att den som begär har rätt att genomföra återställningen. Med andra ord, vi behöver en identitetskontroll; låt oss titta på vad som händer när identiteten bekräftas utan föregående kontroll av att den som begär verkligen är ägaren av kontot.

Uppräkning av användarnamn och dess påverkan på anonymitet

Detta problem är bättre att illustrera visuellt. Problemet:

Ser du? Notera meddelandet «Det finns ingen användare registrerad med denna e-postadress». Problemet uppstår uppenbarligen om en sådan webbplats bekräftar tillgång en användare registrerad med denna e-postadress. Bingo — du har just upptäckt din mans/chefs/grannes pornofetisch!

Självklart är pornografi ett ganska klassiskt exempel på vikten av sekretess, men faran med att koppla en identitet till en viss webbplats är mycket bredare än den potentiellt pinsamma situation som beskrivits ovan. En av farorna är social ingenjörskonst; om en angripare kan koppla en person till tjänsten får de information som de kan börja använda. Till exempel kan de kontakta personen och utge sig för att vara en representant för webbplatsen och begära mer information i ett försök att göra spearphishing.

Sådana metoder medför också en risk för att «uppräkning av användarnamn» inträffar, där man kan kontrollera existensen av en hel samling användarnamn eller e-postadresser på en webbplats genom enkla gruppförfrågningar och studera svaren på dem. Har du en lista med e-postadresser till alla anställda och några minuter på att skriva ett skript? Då ser du vad problemet är!

Vad är alternativet? Det är faktiskt ganska enkelt och är utmärkt implementerat på Entropay:

Här avslöjar Entropay inget alls om existensen av e-postadressen i sitt system för den som inte äger denna adress. Om du äger den här adressen finns inte i systemet, kommer du att få ett liknande e-postmeddelande:

Naturligtvis kan det förekomma situationer där någon tänker, att de har registrerat sig på webbplatsen. men så är inte fallet, eller har gjort det med en annan e-postadress. Exemplet ovan hanterar båda situationerna framgångsrikt. Om adressen matchar kommer du uppenbarligen att få ett e-postmeddelande som förenklar återställningen av lösenordet.

Finessen med det valda Entropay-lösningen är att identifieringsverifieringen utförs via e-post innan någon online-verifiering. Vissa webbplatser frågar användare om svaret på en hemlig fråga (mer om detta nedan) till som kan inledas för att återställa lösenordet; problemet med detta är dock att man måste svara på frågan och samtidigt tillhandahålla någon form av identifiering (e-post eller användarnamn), vilket gör det nästan omöjligt att intuitivt svara utan att avslöja existensen av ett anonymt användarkonto.

Med en sådan strategi finns det en liten minskning av användbarheten, eftersom det vid ett försök att återställa ett icke-existerande konto finns ingen omedelbar återkoppling. Naturligtvis är syftet med att skicka e-post just detta, men från det faktiska slutkundens perspektiv, om de anger en felaktig adress, får de veta detta först när de får e-postmeddelandet. Detta kan orsaka viss spänning från deras sida, men det är en liten kostnad för en så sällsynt process.

En annan anmärkning, som avviker något från ämnet: funktioner som hjälper vid inloggning, som bekräftar riktigheten av användarnamn eller e-postadress, har samma problem. Svara alltid användaren med meddelandet "Kombinationen av ditt användarnamn och lösenord är ogiltig" (Your username and password combination is invalid), istället för att bekräfta existensen av identifikationsinformation (till exempel "användarnamnet är korrekt, men lösenordet är felaktigt").

Skicka återställningslösenord kontra skicka återställningslänk

Det nästa koncept som vi behöver diskutera handlar om sättet att återställa lösenordet. Det finns två populära lösningar:

1. Generera ett nytt lösenord på servern och skicka det via e-post
2. Skicka ett e-postmeddelande med en unik URL som förenklar återställningsprocessen

Trots att många guider, den första punkten bör aldrig användas. Problemet med den är att den innebär att det finns ett sparat lösenord, som man kan återgå till och använda igen när som helst; det har överförts via en osäker kanal och finns kvar i din inkorg. Det finns en risk att inkorgen synkroniseras med mobila enheter och e-postklienten, plus att den kan lagras online i en e-posttjänst under lång tid. Poängen är att en e-postlåda inte kan betraktas som ett pålitligt medium för långsiktig lagring.

Men förutom detta har den första punkten ett annat allvarligt problem — den maximalt förenklar blockeringen av konton med ond avsikt. Om jag känner till e-postadressen till den som äger kontot på webbplatsen kan jag blockera honom eller henne när som helst genom att bara återställa lösenordet; det är en denial-of-service-attack serverad på en silverfat! Därför bör en återställning endast utföras efter en framgångsrik verifiering av rättigheten att begära det.

När vi pratar om en återställnings-URL, menar vi en webbadress som är unik för just det här specifika återställningsprocessen. Självklart bör den vara slumpmässig, lätt att inte knäcka och den bör inte innehålla några externa länkar till kontot som förenklar en återställning. Till exempel bör en återställnings-URL inte vara bara en väg som "Reset/?username=JohnSmith".

Vi vill skapa en unik token som kan skickas via e-post som en återställnings-URL, och sedan kontrollera den mot posten på servern med användarkontot, vilket sålunda bekräftar att kontoinnehavaren verkligen är samma person som försöker återställa lösenordet. Till exempel kan token se ut som "3ce7854015cd38c862cb9e14a1ae552b" och lagras i en tabell tillsammans med användarens ID som gör återställningen och tidpunkten för tokenutsändningen (mer om detta längre ner). När e-postmeddelandet skickas innehåller det en URL som "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", och när användaren laddar upp den, kontrollerar sidan existensen av token, bekräftar användarinformationen och tillåter att lösenordet ändras.

Självklart, eftersom den beskrivna processen (vi får hoppas) gör det möjligt för användaren att skapa ett nytt lösenord, måste vi säkerställa att URL:en laddas via HTTPS. Nej, att skicka den med en POST-begäran via HTTPS är inte tillräckligt,, denna URL med token måste använda transportsäkerhet för att förhindra att ett angrepp görs på formuläret för att ange det nya lösenordet. MITM och det användarskapade lösenordet skickas över en säker anslutning.

Dessutom bör URL:en för återställning ha en tidsgräns för token så att återställningsprocessen kan genomföras inom en viss tidsram, till exempel inom en timme. Detta säkerställer att tidsfönstret för återställning är minimalt, så att den som mottagit denna återställnings-URL bara kan agera inom detta mycket lilla fönster. Självklart kan angriparen starta återställningsprocessen igen, men de behöver få en ny unik återställnings-URL.

Slutligen måste vi säkerställa att denna process är engångsbruk. Efter att återställningsprocessen har slutförts måste token tas bort så att återställnings-URL:en inte längre fungerar. Den föregående punkten är nödvändig för att ge angriparen ett mycket litet fönster där de kan manipulera återställnings-URL:en. Dessutom, självklart, efter att återställningen har slutförts behöver vi inte längre token.

Några av dessa steg kan verka överdrivna, men de påverkar inte användbarheten och som faktiskt ökar säkerheten, även om i situationer som vi hoppas kommer att vara sällsynta. I 99% av fallen kommer användaren att använda återställningen under en mycket kort tidsperiod och inte återställa lösenordet igen inom en överskådlig framtid.

Roll av CAPTCHA

Åh, CAPTCHA, skyddsmedlet som vi alla älskar att hata! Faktum är att CAPTCHA inte bara är ett skydd, utan också en identifiering — är du människa eller robot (eller automatiserat skript). Syftet är att förhindra automatisk inskickning av formulär, vilket självklart 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. kan användas som ett försök att bryta skyddet. I kontexten av lösenordsåterställning betyder CAPTCHA att återställningsfunktionen inte kan hackas med bruteforce, för att antingen skicka skräppost till användaren, eller försöka fastställa existensen av konton (vilket självklart inte är möjligt om du följt råd från avsnittet om identitetsverifiering).

Självklart, CAPTCHA i sig är inte perfekt; det finns många exempel på dess programvaruhackning och uppnådda framgångsnivåer (60-70%). Dessutom finns det en lösning, som jag visade i mitt inlägg om hackning av CAPTCHA med hjälp av automatiserade människor, där man kan betala människor några ören för att lösa varje CAPTCHA och få en framgångsnivå på 94%. Det vill säga, den är sårbar, men (något) höjer ingångströskeln.

Låt oss titta på exemplet PayPal:

I det här fallet kan processen för att återställa bara inte påbörjas förrän CAPTCHA har lösts, så teoretiskt är det omöjligt att automatisera processen. Teoretiskt.

Men för de flesta webbapplikationer skulle det vara en överdrift och det är helt klart en minskning av användbarheten – folk gillar helt enkelt inte CAPTCHA! Dessutom är CAPTCHA något som man enkelt kan återkomma till vid behov. Om en tjänst börjar utsättas för angrepp (här hjälper loggning, men mer om det senare), är det enklare än någonsin att lägga till CAPTCHA.

Säkra frågor och svar

Vid alla de metoder vi har diskuterat har vi kunnat återställa lösenordet enbart med tillgång till e-postkontot. Jag säger "enbart", men självklart är det olagligt att få obehörig åtkomst till någon annans e-postkonto bör vara en komplicerad process. Men så är det inte alltid.

Faktum är att den länk som presenterades ovan om hackning av Sarah Palins konto på Yahoo! tjänar två syften; för det första illustrerar den hur lätt det kan vara att hacka (vissa) e-postkonton, för det andra visar den hur dåliga säkra frågor kan användas med ond avsikt. Men vi återkommer till det senare.

Problemet med att återställa lösenord med en fullständig beroende av e-post är att integriteten hos det webbplatskonto vars lösenord du försöker återställa blir helt beroende av integriteten hos e-postkontot. Den som har tillgång till din e-post har tillgång till vilket konto som helst som kan återställas genom att helt enkelt få ett e-postmeddelande. För sådana konton är e-posten "nyckeln till alla dörrar" i ditt liv online.

Ett av sätten att minska denna risk är att implementera en metod med hemliga frågor och svar. Utan tvekan har du redan sett dem: du väljer en fråga vars svar endast du måste känner till, som sedan ställs till dig när du återställer ditt lösenord. Detta ger en ökad säkerhet för att personen som försöker genomföra återställningen verkligen är kontoinnehavaren.

Låt oss återvända till Sarah Palin: felet var att svaren på hennes hemliga frågor enkelt kunde hittas. Särskilt när du är en så betydande offentlig person, är information om din mors flicknamn, utbildningshistorik eller var någon kanske har bott i det förflutna inte särskilt hemlig. Faktum är att en stor del av detta kan hittas av nästan vem som helst. Så blev det även för Sarah:

Hackaren David Kernell fick tillgång till Palins konto genom att hitta detaljer från hennes biografi, såsom hennes universitet och födelsedatum, och sedan använda funktionen för att återställa glömda lösenord för Yahoo!-konton.

Detta är i första hand en designfel från Yahoo:s sida - genom att ställa sådana enkla frågor saboterade företaget i praktiken värdet av den hemliga frågan och därmed skyddet av sitt system. Självklart är det alltid svårare att återställa lösenord för ett e-postkonto, eftersom du inte kan bekräfta ägandeskapet genom att skicka ett e-postmeddelande till ägaren (utan att ha en andra adress), men lyckligtvis finns det inte så många sätt att implementera ett sådant system idag.

Åter till de hemliga frågorna - ett alternativ är att ge användaren möjlighet att skapa sina egna frågor. Problemet är att det resulterar i fruktansvärt uppenbara frågor:

Vilken färg har himlen?

Frågor som ställer människor i en obekväm position när den hemliga frågan identifierar personen (till exempel i en kundtjänst):

Vem sov jag med på juldagen?

Eller rentav idiotiska frågor:

Hur stavas "lösenord"?

När det kommer till hemliga frågor måste användarna skyddas från sig själva! Med andra ord, den hemliga frågan bör bestämmas av själva webbplatsen, och ännu bättre, ställa en serie hemliga frågor som användaren kan välja bland. Och inte bara välja en; i idealfallet bör användaren välja två eller flera hemliga frågor vid registreringen av kontot., som sedan kommer att användas som en andra identifikationskanal. Att ha flera frågor ökar säkerheten i verifieringsprocessen och ger också en möjlighet att lägga till slumpmässighet (att inte alltid visa samma fråga), plus ger lite redundans om den verkliga användaren skulle glömma sitt lösenord.

Vad bör en bra hemlig fråga vara? Flera faktorer påverkar detta:

1. Den bör vara kortfattad — frågan bör vara tydlig och entydig.
2. Svaret bör vara specifikt — vi behöver inte en fråga som olika personer kan svara på olika sätt.
3. Möjliga svar bör vara varierande — en fråga om någons favoritfärg ger en mycket liten mängd möjliga svar.
4. Sökandet efter svaret bör vara svårt — om svaret lätt kan hittas av någon (tänk på personer i höga positioner), är det dåligt.
5. Svaret bör vara konstant Över tid — om man frågar efter någons favoritfilm kan svaret vara annorlunda om ett år.

Som det ofta är, finns det en webbplats dedikerad till bra frågor som kallas GoodSecurityQuestions.com. Vissa frågor verkar ganska bra, medan andra inte klarar en del av de ovan beskrivna testerna, särskilt testet för "lätthet att hitta".

Låt mig visa hur hemliga frågor implementeras i PayPal och specifikt vilka insatser webbplatsen gör för att identifiera. Ovan såg vi sidan där processen inleds (med CAPTCHA), och här visar vi vad som händer efter att du har angett din e-postadress och löst CAPTCHA:

Resultatet är att användaren får ett sådant mejl:

Hitills ser allt ganska normalt ut, men här är vad som döljer sig bakom den här återställnings-URL:en:

Så här kommer de hemliga frågorna in i bilden. Faktum är att PayPal också tillåter att återställa lösenordet genom att bekräfta kreditkortsnummer, så det finns en ytterligare kanal som många webbplatser inte har tillgång till. Jag kan helt enkelt inte ändra lösenordet utan att svara på båda de hemliga frågorna (eller veta nummer till kortet). Även om någon skulle ta över min e-post, kan de inte återställa lösenordet till PayPal-kontot om de inte vet lite mer personlig information om mig. Vilken information? Här är alternativen för hemliga frågor som erbjuds av PayPal:

Frågan om skolan och sjukhuset kan vara något tveksam utifrån enkelheten i sökandet, men de andra är inte så dåliga. Men för att öka säkerheten kräver PayPal ytterligare identifiering för för svar på hemliga frågor:

PayPal är ett ganska utopiskt exempel på säker återställning av lösenord: det implementerar CAPTCHA för att minska risken för brute force-attacker, kräver två hemliga frågor och sedan ytterligare en form av helt annan identifiering bara för att ändra svaren - och detta efter att användaren redan har loggat in. Självklart är detta exakt vad vi förväntade av PayPal; det är en finansiell institution som hanterar stora summor pengar. Det betyder inte att varje återställning av lösenord måste följa dessa steg - i de flesta fall är det överdrivet - men det är ett bra exempel på fall där säkerhet är en seriös affär.

Fördelarna med systemet med hemliga frågor är att om du inte implementerade det direkt, kan det läggas till senare om resursens skyddsnivå kräver det. Ett bra exempel på detta är Apple, som nyligen implementerade denna mekanism [artikeln skrevs 2012]. En gång när jag uppdaterade en app på iPad såg jag följande meddelande:

Sedan såg jag en skärm där jag kunde välja flera par av hemliga frågor och svar, samt en räddnings-e-postadress:

När det gäller PayPal väljs frågorna i förväg och några av dem är faktiskt ganska bra:

Varje av de tre paren av frågor och svar representerar en separat uppsättning möjliga frågor, så det finns tillräckligt med sätt att konfigurera kontot.

En annan aspekt som måste beaktas angående svaret på den hemliga frågan är lagringen. Att finnas i en vanlig textdatabas innebär nästan samma hot som i fallet med lösenord, nämligen att ett databasintrång omedelbart avslöjar värdet och utsätter inte bara applikationen, utan potentiellt helt andra applikationer som använder samma hemliga frågor (detta är återigen frågan om acai-bär). Ett av alternativen är säker hashing (en robust algoritm och kryptografiskt slumpmässig salt), men till skillnad från de flesta fall av lösenordshantering kan det här finnas en legitim anledning till att svaret visas som ren text. Ett typiskt scenario är identitetsverifiering av en levande operatör via telefon. Självklart är hashing också tillämpligt här (operatören kan helt enkelt ange svaret som kunden nämnt), men i värsta fall måste det hemliga svaret lagras på något nivå i en kryptografisk lagring, även om det bara är symmetrisk kryptering. Sammanfattningsvis: behandla hemligheter som hemligheter!

Och den sista aspekten av hemliga frågor och svar — de är mer sårbara för social ingenjörskonst. Att försöka få ut ett lösenord till någons konto direkt är en sak, men att inleda ett samtal om deras utbildning (en populär hemlig fråga) är något helt annat. I själva verket kan du helt realistiskt prata med någon om många aspekter av deras liv som kan utgöra en hemlig fråga, utan att väcka misstankar. Naturligtvis är själva poängen med den hemliga frågan att den är kopplad till någons livserfarenhet, så den minns, och det är just detta som är problemet — människor älskar att berätta om sina livserfarenheter! Detta finns det inte mycket att göra åt, annat än att välja sådana alternativ för hemliga frågor som med mindre sannolikhet kan dras ut genom social ingenjörskonst.

[Fortsättning följer.]

I reklamens namn

VDSina erbjuder pålitliga servrar med daglig betalning, varje server är ansluten till en internetkanal på 500 megabit och är gratis skyddad mot DDoS-attacker!

Källa: habr.com