Jag hade nyligen tid att tänka igen på hur en säker lösenordsåterställningsfunktion ska fungera, först när jag byggde in den här funktionen i , och sedan när han 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 hur man säkert implementerar återställningsfunktionen. Problemet är dock att en sådan resurs inte finns, åtminstone inte en som beskriver allt som verkar viktigt för mig. Så jag bestämde mig för att skriva det själv.
Du förstår, världen av glömda lösenord är faktiskt ganska mystisk. Det finns många olika, helt acceptabla synpunkter och många ganska farliga. Chansen är stor att du har stött på var och en av dem många gånger som slutanvändare; så jag ska försöka använda dessa exempel för att visa vem som gör det rätt, vem som inte gör det och vad du behöver fokusera på för att få funktionen rätt i din app.
Lösenordslagring: hash, kryptering och (flämt!) vanlig text
Vi kan inte diskutera vad vi ska göra med glömda lösenord innan vi diskuterar hur vi lagrar dem. Lösenord lagras i databasen i en av tre huvudtyper:
- Enkel text. Det finns en lösenordskolumn, som lagras i vanlig text.
- Krypterad. Använder vanligtvis symmetrisk kryptering (en nyckel används för både kryptering och dekryptering), och de krypterade lösenorden lagras också i samma kolumn.
- Hashed. Envägsprocess (lösenord kan hashas, men kan inte hashas); Lösenord, Jag skulle vilja hoppas, följt av ett salt, och var och en är i sin egen kolumn.
Låt oss gå direkt till den enklaste frågan: Spara aldrig lösenord i vanlig text! Aldrig. En enda sårbarhet för , en slarvig säkerhetskopia, eller ett av dussintals andra enkla misstag - och det är det, gameover, alla dina lösenord - det vill säga förlåt, lösenord för alla dina kunder kommer att bli allmän egendom. Naturligtvis skulle detta innebära en stor sannolikhet att från alla sina konton i andra system. Och det kommer att vara ditt fel.
Kryptering är bättre, men har sina svagheter. Problemet med kryptering är dekryptering; vi kan ta dessa galet utseende chiffer och konvertera dem tillbaka till vanlig text, och när det händer är vi tillbaka till den mänskliga läsbara lösenordssituationen. Hur går det till? En liten brist kommer in i koden som dekrypterar lösenordet, vilket gör det allmänt tillgängligt - detta är ett sätt. Hackare får tillgång till maskinen på vilken krypterad data lagras - detta är den andra metoden. Ett annat sätt, återigen, är att stjäla databasbackupen och någon får också krypteringsnyckeln, som ofta är väldigt osäker lagrad.
Och detta för oss till hashing. Tanken bakom hashing är att det är enkelriktat; det enda sättet att jämföra det användarinmatade lösenordet med dess hashade version är att hasha indata och jämföra dem. För att förhindra attacker från verktyg som regnbågsbord, saltar vi processen med slumpmässighet (läs min om kryptografisk lagring). I slutändan, om de implementeras korrekt, kan vi vara säkra på att hashade lösenord aldrig kommer att bli vanlig text igen (jag ska prata om fördelarna med olika hashalgoritmer i ett annat inlägg).
Ett snabbt argument om hashing vs. kryptering: den enda anledningen till att du någonsin skulle behöva kryptera istället för att hasha ett lösenord är när du behöver se lösenordet i vanlig text, och du ska aldrig vilja det här, åtminstone i en vanlig webbplatssituation. Om du behöver detta gör du troligen något fel!
Varning!
Nedan i texten till inlägget finns en del av en skärmdump av den pornografiska webbplatsen AlotPorn. Den är snyggt trimmad så att det inte finns något du inte kan se på stranden, men om det fortfarande är troligt att det orsakar några problem, scrolla inte ner.
Återställ alltid ditt lösenord aldrig påminn honom inte
Har du någonsin blivit ombedd att skapa en funktion påminnelser Lösenord? Ta ett steg tillbaka och tänk på denna begäran omvänt: varför är denna "påminnelse" nödvändig? Eftersom användaren har glömt lösenordet. Vad vill vi egentligen göra? Hjälp honom att logga in igen.
Jag inser att ordet "påminnelse" används (ofta) i en vardaglig betydelse, men vad vi verkligen försöker göra är säkert hjälpa användaren att vara online igen. Eftersom vi behöver säkerhet finns det två skäl till varför en påminnelse (dvs. skicka användaren sitt lösenord) inte är lämplig:
- E-post är en osäker kanal. Precis som vi inte skulle skicka något känsligt över HTTP (vi skulle använda HTTPS), bör vi inte skicka något känsligt via e-post eftersom dess transportlager är osäkert. Faktum är att detta är mycket värre än att bara skicka information över ett osäkert transportprotokoll, eftersom e-post ofta lagras på en lagringsenhet, tillgänglig för systemadministratörer, vidarebefordras och distribueras, tillgänglig för skadlig programvara och så vidare. Okrypterad e-post är en extremt osäker kanal.
- Du borde inte ha tillgång till lösenordet ändå. Läs om föregående avsnitt om lagring - du bör ha en hash av lösenordet (med ett bra starkt salt), vilket betyder att du inte på något sätt ska kunna extrahera lösenordet och skicka det med post.
Låt mig visa problemet med ett exempel : Här är en typisk inloggningssida:
Uppenbarligen är det första problemet att inloggningssidan inte laddas över HTTPS, men webbplatsen uppmanar dig också att skicka ett lösenord ("Skicka lösenord"). Detta kan vara ett exempel på den vardagliga användningen av termen som nämns ovan, så låt oss ta det ett steg längre och se vad som händer:
Det ser inte mycket bättre ut, tyvärr; och ett e-postmeddelande bekräftar att det finns ett problem:
Detta berättar för oss två viktiga aspekter av usoutdoor.com:
- Webbplatsen hash inte lösenord. I bästa fall är de krypterade, men det är troligt att de lagras i vanlig text; Vi ser inga bevis för motsatsen.
- Webbplatsen skickar ett långsiktigt lösenord (vi kan gå tillbaka och använda det om och om igen) över en osäkrad kanal.
Med detta ur vägen måste vi kontrollera om återställningsprocessen görs på ett säkert sätt. Det första steget för att göra detta är att försäkra sig om att begäranden har rätt att utföra återställningen. Med andra ord, innan detta behöver vi en identitetskontroll; låt oss ta en titt på vad som händer när en identitet verifieras utan att först verifiera att förfrågaren faktiskt är kontoägaren.
Lista användarnamn och dess inverkan på anonymitet
Detta problem illustreras bäst visuellt. Problem:
Ser du? Var uppmärksam på meddelandet "Det finns ingen användare registrerad med den här e-postadressen." Problemet uppstår uppenbarligen om en sådan sida bekräftar tillgänglighet användare registrerad med en sådan e-postadress. Bingo - du har precis upptäckt din mans/chefen/grannes porrfetisch!
Naturligtvis är porr ett ganska ikoniskt exempel på vikten av integritet, men farorna med att associera en individ med en specifik webbplats är mycket bredare än den potentiellt obekväma situationen som beskrivs ovan. En fara är social ingenjörskonst; Om angriparen kan matcha en person med tjänsten kommer han att ha information som han kan börja använda. Han kan till exempel kontakta en person som utger sig för att vara en representant för en webbplats och begära ytterligare information i ett försök att binda sig .
Sådan praxis ökar också risken för "uppräkning av användarnamn", där man kan verifiera existensen av en hel samling användarnamn eller e-postadresser på en webbplats genom att helt enkelt utföra gruppfrågor och undersöka svaren på dem. Har du en lista med e-postadresser till alla anställda och några minuter för att skriva ett manus? Då ser du vad problemet är!
Vad är alternativet? I själva verket är det ganska enkelt och är fantastiskt implementerat i :
Här avslöjar Entropay absolut ingenting om förekomsten av en e-postadress i sitt system till någon som inte äger denna adress... Om du egen denna adress och den inte finns i systemet, då får du ett e-postmeddelande så här:
Naturligtvis kan det finnas acceptabla situationer där någon tänkeratt du har registrerat dig på webbplatsen. men så är inte fallet, eller så gjorde jag det från en annan e-postadress. Exemplet som visas ovan hanterar båda situationerna bra. Uppenbarligen, om adressen matchar, kommer du att få ett e-postmeddelande som gör det lättare att återställa ditt lösenord.
Det subtila i lösningen som valts av Entropay är att identifieringsverifiering utförs enligt e-post innan någon onlineverifiering. Vissa webbplatser ber användare om svaret på en säkerhetsfråga (mer om detta nedan) до hur återställningen kan börja; problemet med detta är dock att du måste svara på frågan samtidigt som du tillhandahåller någon form av identifiering (e-post eller användarnamn), vilket sedan gör det nästan omöjligt att svara intuitivt utan att avslöja existensen av den anonyma användarens konto.
Med detta tillvägagångssätt finns det små minskad användbarhet eftersom om du försöker återställa ett obefintligt konto kommer det ingen omedelbar feedback. Naturligtvis är det hela poängen med att skicka ett e-postmeddelande, men ur en verklig slutanvändares perspektiv, om de anger fel adress, kommer de bara att veta för första gången när de får e-postmeddelandet. Detta kan orsaka viss spänning från hans sida, men detta är ett litet pris att betala för en så sällsynt process.
En annan anmärkning, något utanför ämnet: inloggningshjälpfunktioner som avslöjar om ett användarnamn eller e-postadress är korrekt har samma problem. Svara alltid användaren med meddelandet "Ditt användarnamn och lösenordskombination är ogiltigt" istället för att uttryckligen bekräfta existensen av referenserna (till exempel "användarnamnet är korrekt, men lösenordet är felaktigt").
Skickar återställningslösenord kontra att skicka återställnings-URL
Nästa koncept vi måste diskutera är hur du återställer ditt lösenord. Det finns två populära lösningar:
- Skapar ett nytt lösenord på servern och skickar det via e-post
- Skicka ett e-postmeddelande med en unik URL för att göra återställningsprocessen enklare
Trots , den första punkten ska aldrig användas. Problemet med detta är att det betyder att det finns lagrat lösenord, som du kan återvända till och använda igen när som helst; den skickades över en osäker kanal och ligger kvar i din inkorg. Chansen är stor att inkorgar synkroniseras mellan mobila enheter och e-postklienten, plus att de kan lagras online i webbtjänsten för e-post under mycket lång tid. Poängen är att en postlåda kan inte betraktas som ett pålitligt sätt för långtidslagring.
Men förutom detta har den första punkten ett annat allvarligt problem - det förenklar så mycket som möjligt blockera ett konto med uppsåt. Om jag känner till e-postadressen till någon som äger ett konto på en webbplats, kan jag blockera dem när som helst genom att helt enkelt återställa lösenordet; Detta är en överbelastningsattack serverad på ett silverfat! Detta är anledningen till att återställningen endast bör utföras efter framgångsrik verifiering av förfrågarens rättigheter till den.
När vi talar om en återställnings-URL, menar vi adressen till en webbplats, dvs unikt för detta speciella fall av återställningsprocessen. Självklart ska det vara slumpmässigt, det ska inte vara lätt att gissa och det ska inte innehålla några externa länkar till kontot som gör det lättare att återställa. Till exempel bör återställningsadressen inte bara vara en sökväg som "Reset/?username=JohnSmith".
Vi vill skapa en unik token som kan skickas som en återställnings-URL och sedan matchas mot serverposten för användarens konto, vilket bekräftar att kontoägaren faktiskt är samma person som försöker återställa lösenordet . Till exempel kan en token vara "3ce7854015cd38c862cb9e14a1ae552b" och lagras i en tabell tillsammans med ID för användaren som utför återställningen och tiden då token genererades (mer om detta nedan). När e-postmeddelandet skickas innehåller det en URL som "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", och när användaren laddar ner det, frågar sidan om existensen av token, varefter den bekräftar användarens information och låter dem ändra Lösenord.
Eftersom processen ovan (förhoppningsvis) tillåter användaren att skapa ett nytt lösenord, måste vi naturligtvis se till att URL:en laddas över HTTPS. Nej, , måste denna token-URL använda transportlagersäkerhet så att det nya lösenordsformuläret inte kan attackeras och det användarskapade lösenordet överfördes via en säker anslutning.
Även för återställnings-URL:n måste du lägga till en token-tidsgräns så att återställningsprocessen kan slutföras inom ett visst intervall, säg inom en timme. Detta säkerställer att återställningstidsfönstret hålls till ett minimum så att mottagaren av återställningsadressen endast kan agera inom det mycket lilla fönstret. Naturligtvis kan angriparen starta återställningsprocessen igen, men de kommer att behöva skaffa en annan unik återställnings-URL.
Slutligen måste vi se till att denna process är engångsföreteelse. När återställningsprocessen är klar måste token tas bort så att återställningsadressen inte längre fungerar. Den föregående punkten är nödvändig för att säkerställa att angriparen har ett mycket litet fönster under vilket han kan manipulera återställningsadressen. Plus, naturligtvis, när återställningen är framgångsrik, behövs inte längre token.
Vissa av dessa steg kan verka alltför överflödiga, men de stör inte användbarheten och faktiskt förbättra säkerheten, om än i situationer som vi hoppas kommer att vara sällsynta. I 99 % av fallen kommer användaren att aktivera återställningen inom en mycket kort tidsperiod och kommer inte att återställa lösenordet igen inom en snar framtid.
CAPTCHA:s roll
Åh, CAPTCHA, säkerhetsfunktionen vi alla älskar att hata! I själva verket är CAPTCHA inte så mycket ett skyddsverktyg som det är ett identifieringsverktyg – oavsett om du är en person eller en robot (eller ett automatiserat skript). Syftet är att undvika automatisk inlämning av formulär, vilket naturligtvis kan användas som ett försök att bryta säkerheten. I samband med lösenordsåterställningar betyder CAPTCHA att återställningsfunktionen inte kan brute-forced att antingen spam användaren eller försöka fastställa existensen av konton (vilket naturligtvis inte kommer att vara möjligt om du följde råden i avsnittet om verifiera identiteter).
Naturligtvis är själva CAPTCHA inte perfekt; Det finns många prejudikat för att dess mjukvara "hackar" och uppnår tillräckliga framgångar (60-70%). Dessutom finns det en lösning som visas i mitt inlägg om , där du kan betala människor bråkdelar av en cent för att lösa varje CAPTCHA och uppnå en framgångsgrad på 94 %. Det vill säga, det är sårbart, men det höjer (något) inträdesbarriären.
Låt oss ta en titt på PayPal-exemplet:
I det här fallet kan återställningsprocessen helt enkelt inte börja förrän CAPTCHA är löst, så teoretiskt det är omöjligt att automatisera processen. I teorin.
Men för de flesta webbapplikationer kommer detta att vara överdrivet och fullständigt rätt representerar en minskning av användbarheten - folk gillar bara inte CAPTCHA! Dessutom är CAPTCHA något som du enkelt kan återgå till vid behov. Om tjänsten börjar bli attackerad (det är här loggning kommer till nytta, men mer om det senare), kan det inte vara lättare att lägga till en CAPTCHA.
Hemliga frågor och svar
Med alla metoder vi övervägde kunde vi återställa lösenordet bara genom att ha tillgång till e-postkontot. Jag säger "bara", men det är naturligtvis olagligt att få tillgång till någon annans e-postkonto. должно vara en komplex process. dock .
Faktum är att länken ovan om hackningen av Sarah Palins Yahoo! tjänar två syften; för det första illustrerar det hur lätt det är att hacka (vissa) e-postkonton, och för det andra visar det hur dåliga säkerhetsfrågor kan användas med uppsåt. Men vi återkommer till detta senare.
Problemet med XNUMX % e-postbaserade lösenordsåterställningar är att integriteten för kontot för webbplatsen du försöker återställa blir XNUMX % beroende av e-postkontots integritet. Alla 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-post "nyckeln till alla dörrar" i ditt onlineliv.
Ett sätt att minska denna risk är att implementera ett säkerhetsfrågor och svarsmönster. Utan tvekan har du redan sett dem: välj en fråga som bara du kan svara på har vet svaret, och när du återställer ditt lösenord kommer du att bli tillfrågad om det. Detta ger förtroende för att personen som försöker återställa verkligen är kontoägaren.
Tillbaka till Sarah Palin: misstaget var att svaren på hennes säkerhetsfråga/frågor lätt kunde hittas. Särskilt när du är en så betydande offentlig person är information om din mammas flicknamn, utbildningshistoria eller var någon kan ha bott tidigare inte så hemlig. Faktum är att det mesta kan hittas av nästan vem som helst. Detta är vad som hände med Sarah:
Hackaren David Kernell fick tillgång till Palins konto genom att hitta detaljer om hennes bakgrund, som hennes universitet och födelsedatum, och sedan använda Yahoo!s funktion för återställning av glömda lösenord.
För det första är detta ett designfel från Yahoo! — Genom att ange sådana enkla frågor saboterade företaget i huvudsak värdet av säkerhetsfrågan och därmed skyddet av dess system. Naturligtvis är det alltid svårare att återställa lösenord för ett e-postkonto eftersom du inte kan bevisa ägande genom att skicka ett e-postmeddelande till ägaren (utan att ha en andra adress), men lyckligtvis finns det inte många användningsområden för att skapa ett sådant system idag.
Låt oss återgå till säkerhetsfrågor - det finns ett alternativ att låta användaren skapa sina egna frågor. Problemet är att detta kommer att resultera i fruktansvärt uppenbara frågor:
vilken färg har himlen?
Frågor som gör människor obekväma när en säkerhetsfråga används för att identifiera människor (till exempel i ett callcenter):
Vem låg jag med på julen?
Eller ärligt talat dumma frågor:
Hur stavar man "lösenord"?
När det kommer till säkerhetsfrågor måste användarna räddas från sig själva! Med andra ord bör säkerhetsfrågan bestämmas av webbplatsen själv, eller ännu bättre, ställas serier säkerhetsfrågor som användaren kan välja bland. Och det är inte lätt att välja en; helst bör användaren välja två eller flera säkerhetsfrågor vid tidpunkten för kontoregistrering, som sedan kommer att användas som en andra identifieringskanal. Att ha flera frågor ökar förtroendet för verifieringsprocessen och ger också möjligheten att lägga till slumpmässighet (visar inte alltid samma fråga), plus ger lite redundans i fall den faktiska användaren har glömt lösenordet.
Vad är en bra säkerhetsfråga? Detta påverkas av flera faktorer:
- Det borde vara kort — Frågan måste vara klar och entydig.
- Svaret måste vara specifik – vi behöver inte en fråga som en person kan svara olika på
- Möjliga svar bör vara olika - Att fråga någons favoritfärg ger en mycket liten delmängd av möjliga svar
- Sök svaret måste vara komplext - om svaret lätt kan hittas någon (kom ihåg folk i höga positioner), då är han dålig
- Svaret måste vara permanent i tid - om du frågar någons favoritfilm, ett år senare kan svaret vara annorlunda
Som det händer, det finns en webbplats dedikerad till att ställa bra frågor kallas . Vissa av frågorna verkar ganska bra, andra klarar inte några av de ovan beskrivna testerna, särskilt testet "lätt att söka".
Låt mig demonstrera hur PayPal implementerar säkerhetsfrågor och i synnerhet den ansträngning som webbplatsen lägger ner på autentisering. Ovan såg vi sidan för att starta processen (med en CAPTCHA), och här kommer vi att visa vad som händer efter att du har skrivit in din e-postadress och löst CAPTCHA:
Som ett resultat får användaren följande brev:
Än så länge är allt ganska normalt, men här är vad som döljer sig bakom denna återställnings-URL:
Så säkerhetsfrågor spelar in. Faktum är att PayPal också låter dig återställa ditt lösenord genom att verifiera ditt kreditkortsnummer, så det finns en extra kanal som många sajter inte har tillgång till. Jag kan bara inte ändra mitt lösenord utan att svara båda säkerhetsfråga (eller att inte veta kortnumret). Även om någon kapade min e-post, skulle de inte kunna återställa mitt PayPal-konto lösenord om de inte visste lite mer personlig information om mig. Vilken information? Här är alternativen för säkerhetsfrågor som PayPal erbjuder:
Skol- och sjukhusfrågan kan vara lite osäker när det gäller enkel sökning, men de andra är inte så illa. Men för att öka säkerheten kräver PayPal ytterligare identifiering för förändringar svar på säkerhetsfrågor:
PayPal är ett ganska utopiskt exempel på säkra lösenordsåterställningar: det implementerar en CAPTCHA för att minska risken för brute-force-attacker, kräver två säkerhetsfrågor och kräver sedan en annan typ av helt annan identifiering bara för att ändra svaren – och detta efter användaren har redan loggat in. Naturligtvis är detta precis vad vi förväntas från PayPal; är ett finansinstitut som hanterar stora summor pengar. Detta betyder inte att varje lösenordsåterställning måste följa dessa steg – oftast är det överdrivet – men det är ett bra exempel för fall där säkerhet är en allvarlig sak.
Bekvämligheten med säkerhetsfrågesystemet är att om du inte har implementerat det direkt kan du lägga till det senare om nivån av resursskydd kräver det. Ett bra exempel på detta är Apple, som nyligen implementerade denna mekanism [artikel skriven 2012]. När jag började uppdatera applikationen på min iPad såg jag följande begäran:
Sedan såg jag en skärm där jag kunde välja flera par säkerhetsfrågor och svar, samt en räddningse-postadress:
När det gäller PayPal är frågorna förvalda och några av dem är faktiskt ganska bra:
Vart och ett av de tre fråga/svar-paren representerar olika möjliga frågor, så det finns många sätt att konfigurera ett konto.
En annan aspekt att tänka på när det gäller att svara på din säkerhetsfråga är lagring. Att ha en vanlig textdatabas i databasen utgör nästan samma hot som ett lösenord, nämligen att exponera databasen omedelbart avslöjar värdet och utsätter inte bara applikationen för risk, utan potentiellt helt olika applikationer som använder samma säkerhetsfrågor (återigen ). Ett alternativ är säker hashing (en stark algoritm och ett kryptografiskt slumpmässigt salt), men till skillnad från de flesta lösenordslagringsfall kan det finnas en bra anledning till att svaret är synligt som vanlig text. Ett typiskt scenario är identitetsverifiering av en livetelefonoperatör. Naturligtvis är hash även tillämpligt i detta fall (operatören kan helt enkelt ange svaret som namngetts av klienten), men i värsta fall måste det hemliga svaret finnas på någon nivå av kryptografisk lagring, även om det bara är symmetrisk kryptering . Sammanfatta: behandla hemligheter som hemligheter!
En sista aspekt av säkerhetsfrågor och svar är att de är mer sårbara för social ingenjörskonst. Att försöka extrahera lösenordet direkt till någon annans konto är en sak, men att starta en konversation om dess bildande (en populär säkerhetsfråga) är helt annorlunda. Faktum är att du mycket väl kan kommunicera med någon om många aspekter av deras liv som kan ställa en hemlig fråga utan att väcka misstankar. Självklart är själva poängen med en säkerhetsfråga att den relaterar till någons livserfarenhet, så den är minnesvärd, och det är där problemet ligger - människor älskar att prata om sina livserfarenheter! Det finns lite du kan göra åt detta, bara om du väljer sådana säkerhetsfrågealternativ så att de är det mindre skulle förmodligen kunna dras ut av social ingenjörskonst.
[Fortsättning följer.]Om reklamens rättigheter
VDSina erbjuder pålitliga , varje server är ansluten till en internetkanal på 500 megabit och skyddas från DDoS-attacker gratis!
Källa: will.com