For nylig havde jeg tid til at tænke over, hvordan funktionen til sikker nulstilling af adgangskoder skal fungere, først da jeg integrerede denne funktionalitet i , og så da jeg hjalp med at lave noget lignende for en anden person. I det andet tilfælde ønskede jeg at give ham et link til en kanonisk ressource med alle detaljer om sikker implementering af nulstillingsfunktionen. Problemet er, at der ikke findes sådan en ressource, i det mindste ikke en, der beskriver alt, hvad jeg anser for vigtigt. Derfor besluttede jeg at skrive den selv.
Ser du, verden af glemte adgangskoder er faktisk temmelig mystisk. Der er mange forskellige, helt acceptable synspunkter og en masse ret farlige. Der er en risiko for, at du har mødt mange af dem som slutbruger; derfor vil jeg forsøge at bruge disse eksempler til at vise, hvem der gør alt rigtigt, og hvem der ikke gør, samt hvad man skal fokusere på for korrekt implementering af funktionen i sin applikation.
Opbevaring af adgangskoder: Hashing, kryptering og (åh!) klartekst
Vi kan ikke diskutere, hvad man skal gøre med glemte adgangskoder, før vi diskuterer, hvordan de skal opbevares. I databasen opbevares adgangskoder i en af tre hovedformer:
- Klartekst. Der er en kolonne med adgangskoden, der opbevares i almindelig tekst.
- Krypteret. Normalt ved hjælp af symmetrisk kryptering (én nøgle bruges til både kryptering og dekryptering), og de krypterede adgangskoder opbevares også i én kolonne.
- Hashing. En envejelsesproces (en adgangskode kan hashes, men kan ikke dekrypteres); adgangskoden, man kunne håbe, ledsages af salt, og hver af dem findes i sin egen kolonne.
Lad os straks tage fat på det enkleste spørgsmål: opbevar aldrig adgangskoder i klartekst! Aldrig. En enkelt sårbarhed til , en uovervejet backup eller en af de mange andre simple fejl — og bingo, game over, alle dine adgangskoder — eller undskyld, adgangskoderne for alle dine kunder bliver offentligt tilgængelige. Selvfølgelig vil dette betyde en enorm risiko for, at det offentlige bliver bekendt med til alle deres konti i andre systemer. Og det vil være din skyld.
Kryptering er bedre, men har sine svagheder. Problemet med kryptering ligger i dekryptering; man kan tage disse vanvittigt udseende krypteringer og omdanne dem tilbage til almindelig tekst, og når det sker, er vi tilbage i en situation med læsbare adgangskoder. Hvordan sker det? En lille fejl kan trænge ind i koden, der håndterer dekrypteringen af adgangskoden, hvilket gør den offentligt tilgængelig — det er en måde. Hackere får adgang til den maskine, hvor de krypterede data opbevares — det er den anden måde. En anden metode er, at man igen stjæler en sikkerhedskopi af databasen, og nogen får også nøglen til krypteringen, som ofte opbevares meget usikkert.
Og det fører os til hashing. Ideen bag hashing er, at det kun kan udføres i én retning; den eneste måde at sammenligne den indtastede adgangskode med dens hash-version på, er ved at hash'e det indtastede og sammenligne dem. For at forhindre angreb ved hjælp af værktøjer som 'rainbow tables', tilføjer vi ved hjælp af salt tilfældighed til processen (for fuldstændighedens skyld, læs min om kryptografisk opbevaring). I sidste ende kan vi med stor sikkerhed sige, at hashede adgangskoder aldrig igen vil blive til almindelig tekst (jeg vil fortælle om fordelene ved forskellige hash-algoritmer i et andet indlæg).
Et kort argument for hashing og kryptering: den eneste grund til, at du nogensinde skal kryptere i stedet for at hash'e en adgangskode, er hvis du har brug for at se adgangskoden i almindelig tekst, og det skal du aldrig ønske, i det mindste ikke i situationer med en standard hjemmeside. Hvis du har brug for det, er det sandsynligt, at du laver noget forkert!
Opmærksomhed!
Længere nede i teksten i indlægget er der et skud fra en pornografisk hjemmeside ved navn AlotPorn. Det er blevet trimmet pænt, og der er ikke noget, der ikke kan ses på stranden, men hvis det stadig kan forårsage problemer, så scroll ikke ned ad siden.
Glem altid adgangskoden, aldrig minds ikke at minde om den
Er du nogensinde blevet bedt om at oprette en funktion til at minde om adgangskode? Tænk over denne anmodning baglæns: hvorfor har vi brug for denne "påmindelse"? Fordi brugeren har glemt sin adgangskode. Hvad vil vi egentlig? Hjælpe dem med at logge ind igen.
Jeg forstår, at ordet "påmindelse" bruges (ofte) i tale, men vi forsøger faktisk sikkert at hjælpe brugeren med at komme online igen. Da vi har brug for sikkerhed, er der to grunde til, at en påmindelse (dvs. at sende brugeren deres adgangskode) ikke er passende:
- E-mail er en usikker kanal. Ligesom vi ikke ville sende noget fortroligt over HTTP (vi ville bruge HTTPS), bør vi ikke sende noget over e-mail, fordi dens transportlag er usikkert. Faktisk er det meget værre end bare at sende information over en usikret transportprotokol, fordi e-mail ofte gemmes på harddiske, er tilgængelig for systemadministratorer, videresendes og distribueres, og kan tilgås af malware osv. Usikret e-mail er en ekstremt usikker kanal.
- Du bør ikke have adgang til adgangskoden under alle omstændigheder. Læs afsnittet ovenfor om opbevaring igen — du skal have en hash af adgangskoden (med en god, stærk salt), hvilket betyder, at du på ingen måde skal have mulighed for at trække adgangskoden og sende den via e-mail.
Lad mig demonstrere problemet med et eksempel : Her er en typisk login-side:
Det åbenlyse første problem er, at login-siden ikke indlæses via HTTPS, men siden tilbyder også at sende adgangskoden ("Send Adgangskode"). Måske er dette et eksempel på den nævnte taleanvendelse af termen, så lad os tage et skridt videre og se, hvad der sker:
Det ser desværre ikke meget bedre ud; og e-mail bekræfter tilstedeværelsen af problemet:
Det fortæller os to vigtige aspekter ved usoutdoor.com:
- Sitet hasher ikke adgangskoder. På bedste fald bliver de krypteret, men det er meget sandsynligt, at de gemmes i raw tekst; der er ikke noget, der indikerer det modsatte.
- Sitet sender en permanent adgangskode (vi kan gå tilbage og bruge den igen og igen) over en usikret kanal.
Når vi har forstået dette, skal vi tjekke, om nulstillingsprocessen udføres på en sikker måde. Først skal vi sikre os, at anmoderen har ret til at udføre nulstillingen. Med andre ord skal vi foretage en identitetskontrol; lad os se, hvad der sker, når identiteten bekræftes uden forudgående kontrol af, at anmoderen faktisk er ejer af kontoen.
Opregning af brugernavne og dens indflydelse på anonymitet
Dette problem er bedre illustreret visuelt. Problemet:
Ser du? Bemærk meddelelsen "There is no user registered with this email address" ("Der er ingen bruger registreret med denne e-mailadresse"). Problemet opstår åbenlyst, hvis en sådan hjemmeside bekræfter tilstedeværelse en registreret bruger med denne e-mailadresse. Bingo - du har lige opdaget din mands/chefens/naboens porno-fetich!
Selvfølgelig er porno et ret klassisk eksempel på vigtigheden af privatliv, men faren ved at knytte identitet til en bestemt hjemmeside er meget mere omfattende end den ovenfor beskrevne potentielt akavede situation. En af farerne er social engineering; hvis en angriber er i stand til at knytte en person til en tjeneste, får han information, som han kan begynde at misbruge. For eksempel kan han kontakte personen og udgive sig for at være repræsentant for hjemmesiden og anmode om yderligere information i forsøget på at begå .
Sådanne praksisser medfører også risikoen for 'brugeropregning', hvor man kan tjekke for eksistensen af en hel samling brugernavne eller e-mailadresser på en hjemmeside ved enkle batch-anmodninger og ved at analysere svarene. Har du en liste over alle medarbejdernes e-mailadresser og et par minutter til at skrive et script? Så ser du, hvad problemet er!
Hvad er alternativen? Faktisk er den ret enkel og fremragende implementeret på :
Her afslører Entropay slet ikke noget om eksistensen af en e-mailadresse i sit system for dem, der ikke ejer den e-mailadresse. Hvis du ejer denne adresse, og den findes ikke i systemet, vil du modtage en lignende e-mail:
Selvfølgelig kan der være situationer, hvor nogen tror, at de registrerede sig på hjemmesiden. men det er ikke tilfældet, eller gjorde det fra en anden e-mailadresse. Eksemplet ovenfor håndterer begge situationer godt. Åbenlyst, hvis adressen matcher, vil du modtage en e-mail, der forenkler nulstillingen af adgangskoden.
Finjusteringen af den valgte Entropay-løsning er, at identitetskontrollen udføres via e-mail før enhver online-verifikation. Nogle hjemmesider beder brugerne om at svare på et hemmeligt spørgsmål (mere om dette nedenfor) op til for hvordan nulstillingen kan starte; dog er problemet med dette, at man skal svare på spørgsmålet og samtidig give en form for identifikation (e-mail eller brugernavn), hvilket så gør det næsten umuligt at svare intuitivt uden at afsløre eksistensen af en anonym brugerkonto.
Med denne tilgang er der en lille reduktion i brugervenlighed, fordi der i tilfælde af forsøg på at nulstille en ikke-eksisterende konto ikke er nogen øjeblikkelig feedback. Selvfølgelig er det hele meningen med at sende en e-mail, men set fra den virkelige slutbrugers synspunkt, hvis de indtaster en forkert adresse, vil de først finde ud af det, når de modtager e-mailen. Dette kan skabe en vis spænding hos dem, men det er en lille pris at betale for en så sjælden proces.
En anden bemærkning, der lidt afviger fra emnet: funktioner til hjælp til log ind, der afslører korrektheden af brugernavnet eller e-mailadressen, har samme problem. Altid svar brugeren med beskeden "Brugernavn og adgangskodekombinationen er ugyldig" (Your username and password combination is invalid), og bekræft ikke eksplicit eksistensen af identifikationsoplysninger (f.eks. "brugernavnet er korrekt, men adgangskoden blev indtastet forkert").
Sending af nulstillingsadgangskode versus sending af nulstillings-URL
Det næste koncept, vi skal diskutere, er måden at nulstille adgangskoden på. Der er to populære løsninger:
- Generering af et nyt password på serveren og sende det via e-mail
- Sending af en e-mail med en unik URL, der forenkler nulstillingsprocessen
På trods af , det første punkt skal aldrig anvendes. Problemet med det er, at det betyder, at der er et gemt password, som man kan vende tilbage til og bruge igen når som helst; det blev sendt over en usikker kanal og forbliver i din indbakke. Der er en risiko for, at indbakken synkroniseres med mobile enheder og e-mailklienter, plus at de kan være online i en webtjeneste i meget lang tid. Pointen er, at e-mailkassen ikke kan betragtes som en pålidelig metode til langvarig opbevaring.
Men ud over dette er der et andet alvorligt problem med det første punkt — det maksimalt forenkler blokering af kontoen med ondsindet hensigt. Hvis jeg kender e-mailadressen på den, der ejer kontoen på et website, kan jeg blokere den til enhver tid ved blot at nulstille deres password; det er et eksempel på en tjenestenægtelsesangreb, der serveres på et sølvfad! Det er derfor, nulstillingen kun bør udføres efter en vellykket verifikation af anmoderen.
Når vi taler om nulstillings-URL'en, mener vi adressen til websitet, der er unik for denne specifikke nulstillingsproces. Selvfølgelig skal denne være tilfældig, den må ikke være let at gætte, og den må ikke indeholde nogen eksterne links til kontoen, der muliggør en lettere nulstilling. For eksempel skal nulstillings-URL'en ikke blot være en sti som "Reset/?username=JohnSmith".
Vi ønsker at skabe en unik token, som kan sendes via e-mail som nulstillings-URL, og derefter sammenligne den med posten på serveren med brugerens konto for dermed at bekræfte, at kontoejeren faktisk er den samme person, der forsøger at nulstille passwordet. For eksempel kan token have formen "3ce7854015cd38c862cb9e14a1ae552b" og opbevares i en tabel sammen med brugerens ID, der foretager nulstillingen, og tidspunktet for oprettelsen af token (mere om dette lidt senere). Når e-mailen sendes, indeholder den en URL som "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", og når brugeren indlæser den, anmoder siden om at bekræfte, at token eksisterer, hvorefter brugeroplysningerne bekræftes og ændring af password tillades.
Selvfølgelig, da den ovenfor beskrevne proces (forhåbentlig) giver brugeren mulighed for at oprette en ny adgangskode, skal det sikres, at URL'en indlæses over HTTPS. Nej, , denne URL med token skal bruge transportsikkerhed, så angrebet på formularen til indtastning af den nye adgangskode ikke er muligt. og den brugeroprettede adgangskode skal overføres over en sikker forbindelse.
Derudover skal der være en tidsbegrænsning for tokenet i forbindelse med URL'en til nulstilling, så nulstillingsprocessen kan udføres inden for et bestemt tidsrum, f.eks. inden for en time. Dette sikrer, at tidsvinduet for nulstilling er minimalt, så den, der modtager denne nulstillings-URL, kun kan handle inden for dette meget lille vindue. Selvfølgelig kan en angriber genstarte nulstillingsprocessen, men de skal have en unik nulstillings-URL igen.
Endelig skal vi sikre, at denne proces er engangsbrug. Efter nulstillingsprocessen er gennemført, skal tokenet fjernes, så nulstillings-URL'en ikke længere er aktiv. Det forrige punkt er nødvendigt, så angriberen har et meget lille vindue til at manipulere med nulstillings-URL'en. Plus, selvfølgelig, efter en vellykket nulstilling er tokenet ikke længere nødvendigt.
Nogle af disse trin kan virke overflødige, men de skader slet ikke brugervenligheden og har vi virkelig øger sikkerheden, selvom det er i situationer, som vi håber, vil være sjældne. I 99% af tilfældene vil brugeren udføre nulstillingen inden for en meget kort periode og ikke nulstille adgangskoden igen i den nærmeste fremtid.
Rollen af CAPTCHA
Åh, CAPTCHA, et beskyttelsesmiddel, som vi alle elsker at hade! Faktisk er CAPTCHA ikke så meget et beskyttelsesmiddel som en identifikationsmetode — er du en person eller en robot (eller et automatiseret script)? Formålet med den er at undgå automatisk indsendelse af formularer, som selvfølgelig kan kan anvendes som et forsøg på at bryde beskyttelsen. I forbindelse med nulstilling af adgangskoder betyder CAPTCHA, at nulstillingsfunktionen ikke vil kunne blive brudt via brute force, for derefter at spamme brugeren eller forsøge at afgøre, om konti eksisterer (hvilket selvfølgelig vil være umuligt, hvis du har fulgt rådene i afsnittet om identifikationskontrol).
Selvfølgelig er CAPTCHA ikke perfekt i sig selv; der findes mange tilfælde af programmatisk 'hacking' af den og opnåelse af tilstrækkelige succeshastigheder (60-70%). Derudover findes der en løsning, som fremhævet i mit indlæg om , hvor man kan betale mennesker et par cent for at løse hver CAPTCHA og opnå en succeshastighed på 94%. Så den er sårbar, men (let) hæver indgangsbarrieren.
Lad os tage et kig på et eksempel med PayPal:
I dette tilfælde kan proces for nulstilling ikke begynde, før CAPTCHA er løst, så teoretisk set er det umuligt at automatisere processen. Teoretisk set.
Men for de fleste webapplikationer ville det være overkill og ganske vist repræsenterer en reduktion af brugervenlighed — folk kan simpelthen ikke lide CAPTCHA! Desuden er CAPTCHA noget, man let kan vende tilbage til, hvis nødvendigt. Hvis tjenesten begynder at blive angrebet (her kommer logning til nytte, men mere om det senere), er det nemt at tilføje CAPTCHA.
Hemmelige spørgsmål og svar
Ved alle de metoder, vi har gennemgået, har vi kunnet nulstille adgangskoden blot ved at have adgang til e-mailkontoen. Jeg siger 'kun', men selvfølgelig skal ulovlig adgang til en andens e-mailkonto være en vanskelig proces. Men .
Faktisk tjener det ovenfor nævnte link om hacket af Sarah Palins Yahoo!-konto to formål; for det første illustrerer det, hvor let det er at hacke (nogle) e-mailkonti, for det andet viser det, hvordan dårlige hemmelige spørgsmål kan blive misbrugt med ondsindede hensigter. Men vi kommer tilbage til dette senere.
Problemet med at nulstille adgangskoder, der er 100% afhængige af e-mail, er, at integriteten af den konto på webstedet, hvis adgangskode du prøver at nulstille, bliver 100% afhængig af integriteten af e-mailkontoen. Enhver, der har adgang til din e-mail, har adgang til enhver konto, der kan nulstilles ved blot at modtage en e-mail. For sådanne konti er e-mailen 'nøglen til alle døre' i dit liv online.
En af måderne at mindske denne risiko på er at implementere et mønster med et hemmeligt spørgsmål og svar. Uden tvivl har du allerede set dem: du vælger et spørgsmål, som kun du skal kende svaret på, hvorefter de stiller dig det, når du nulstiller din adgangskode. Det tilføjer sikkerhed ved, at den person, der forsøger at nulstille, virkelig er ejeren af kontoen.
Lad os vende tilbage til Sarah Palin: Fejlen var, at svarene på hendes hemmelige spørgsmål/spørgsmål letteligt kunne findes. Især når du er en så betydningsfuld offentlig person, er oplysninger om din mors pigenavn, uddannelseshistorie eller hvor nogen har boet tidligere, ikke så hemmelige. Faktisk kan en stor del findes af næsten enhver. Sådan gik det med Sarah:
Hackeren David Kernell fik adgang til Palins konto ved at finde detaljer om hendes biografi, såsom hendes universitet og fødselsdato, og derefter bruge funktionen til at gendanne glemte adgangskoder til Yahoo!-konti.
Først og fremmest er dette en designfejl fra Yahoo! — ved at stille sådanne enkle spørgsmål saboterede virksomheden i praksis værdien af det hemmelige spørgsmål, og dermed beskyttelsen af deres system. Selvfølgelig er det altid sværere at nulstille adgangskoden til en e-mail-konto, fordi du ikke kan bekræfte ejerskab ved at sende ejeren en e-mail (uden at have en sekundær adresse), men heldigvis er der i dag ikke så mange måder at skabe et sådant system.
Lad os vende tilbage til de hemmelige spørgsmål — der er en mulighed for at give brugeren mulighed for at oprette egne spørgsmål. Problemet er, at der i så fald vil opstå frygtelig åbenlyse spørgsmål:
Hvilken farve har himlen?
Spørgsmål, der sætter folk i en akavet position, når det hemmelige spørgsmål anvendes til identifikation af en person (for eksempel i et callcenter):
Hvem havde jeg sex med på juleaften?
Eller helt tåbelige spørgsmål:
Hvordan staves "adgangskode"?
Når det kommer til hemmelige spørgsmål, skal brugerne reddes fra sig selv! Med andre ord, det hemmelige spørgsmål skal bestemmes af selve siden, og endnu bedre, stille en række hemmelige spørgsmål, som brugeren kan vælge imellem. Og ikke bare vælge en; ideelt set skal brugeren vælge to eller flere hemmelige spørgsmål ved oprettelse af konto, som derefter vil blive brugt som et sekundært identifikationskanal. At have flere spørgsmål øger sikkerheden i verifikationsprocessen og giver samtidig mulighed for at tilføje tilfældighed (ikke altid stille det samme spørgsmål), plus sikrer lidt redundans i tilfælde af, at den rigtige bruger glemmer adgangskoden.
Hvordan skal et godt sikkerhedsspørgsmål være? Dette afhænger af flere faktorer:
- Det skal være kort — spørgsmålet skal være klart og entydigt.
- Svaret skal være konkret — vi har ikke brug for et spørgsmål, som én person kan svare forskelligt på.
- Mulige svar skal være varierede — et spørgsmål om nogens yndlingsfarve giver et meget lille udvalg af mulige svar.
- Søgning svaret skal være komplekst — hvis svaret let kan findes enhver (lad os huske på folk med høje positioner), så er det dårligt.
- Svaret skal være konstant over tid — hvis man spørger om nogen yndlingsfilm, kan svaret være anderledes om et år.
Som man kan forestille sig, findes der en hjemmeside dedikeret til gode spørgsmål, som hedder . Nogle spørgsmål virker ganske gode, mens andre ikke klarer nogle af de nævnte tests, især testen for 'lethed ved at finde'.
Lad mig demonstrere, hvordan sikkerhedsspørgsmål implementeres i PayPal, og specielt hvilke bestræbelser siden gør for at identificere. Vi har tidligere set startskærmen for processen (med CAPTCHA), og her vil vi vise, hvad der sker, efter at du indtaster din e-mailadresse og løser CAPTCHA:
Som resultat modtager brugeren denne e-mail:
Indtil videre er alt ret normalt, men her er hvad der gemmer sig bag dette nulstillings-URL:
Så træder sikkerhedsspørgsmålene ind. Faktisk tillader PayPal også nulstilling af adgangskoden ved at bekræfte kreditkortnummeret, så der findes et ekstra kanal, som mange websteder ikke har adgang til. Jeg kan simpelthen ikke ændre adgangskoden uden at svare på begge sikkerhedsspørgsmål (eller ikke kender kortnummeret). Selv hvis nogen får adgang til min e-mail, kan de ikke nulstille adgangskoden til min PayPal-konto, medmindre de ved lidt mere personlige oplysninger om mig. Hvilke oplysninger? Her er de forslag til sikkerhedsspørgsmål, som PayPal tilbyder:
Spørgsmålet om skole og hospital kan være lidt tvivlsomt med hensyn til enkelheden i søgningen, men de andre er ikke så dårlige. For at øge sikkerheden kræver PayPal dog yderligere identifikation for Optimeringer svar på sikkerhedsspørgsmål:
PayPal er et ret utopisk eksempel på sikker nulstilling af adgangskode: det implementerer CAPTCHA for at reducere risikoen for bruteforce-angreb, kræver to sikkerhedsspørgsmål og derefter en helt anden form for identifikation blot for at ændre svarene — og det er efter brugeren allerede har logget ind. Selvfølgelig er det netop, hvad vi forventede af PayPal; det er en finansiel institution, der arbejder med store pengesummer. Det betyder ikke, at hver nulstilling af adgangskode skal følge disse trin — i de fleste tilfælde er det overkill — men det er et godt eksempel i tilfælde, hvor sikkerhed er en seriøs sag.
Fordelen ved systemet med sikkerhedsspørgsmål er, at hvis du ikke har implementeret det fra starten, kan det tilføjes senere, hvis beskyttelsesniveauet for ressourcen kræver det. Et godt eksempel på dette er Apple, som for nylig har implementeret denne mekanisme [artiklen blev skrevet i 2012]. Da jeg engang påbegyndte en opdatering af appen på iPad, så jeg følgende anmodning:
Derefter så jeg en skærm, hvor jeg kunne vælge flere par sikkerhedsspørgsmål og svar samt en rednings-e-mailadresse:
Med hensyn til PayPal er spørgsmålene valgt på forhånd, og nogle af dem er faktisk ganske gode:
Hvert af de tre par spørgsmål og svar repræsenterer et særskilt sæt mulige spørgsmål, så der er tilstrækkeligt med måder at konfigurere kontoen på.
Endnu en aspekt, der skal overvejes i forhold til svarene på sikkerhedsspørgsmål, er opbevaring. At være i en databasetekst repræsenterer næsten de samme trusler som med en adgangskode, idet påvisningen af databasen straks afslører værdien og udsætter ikke kun applikationen, men også potentielt helt andre applikationer, der bruger de samme sikkerhedsspørgsmål (det er igen ). En af mulighederne er sikker hashing (en robust algoritme og kryptografisk tilfældig salt), men i modsætning til de fleste tilfælde af adgangskodeopbevaring, kan der her være en legitim grund til at se svaret som almindelig tekst. Et typisk scenarie er identitetskontrol af en levende operatør over telefonen. Selvfølgelig er hashing også relevant her (operatøren kan blot indtaste det svar, som kunden nævner), men i værste fald bør det hemmelige svar være lagret på et eller andet niveau af kryptografisk opbevaring, selv hvis det blot er symmetrisk kryptering. Lad os opsummere: behandl hemmeligheder som hemmeligheder!
Og det sidste aspekt af hemmelige spørgsmål og svar er, at de er mere sårbare overfor social engineering. At forsøge at udspørge en adgangskode til en andens konto er én ting, men at indlede en samtale om deres uddannelse (et populært hemmeligt spørgsmål) er en helt anden. Faktisk kan du reelt kommunikere med nogen om mange aspekter af deres liv, som kunne repræsentere et hemmeligt spørgsmål, uden at vække mistanke. Selvfølgelig er hele essensen af et hemmeligt spørgsmål, at det er relateret til nogens livserfaring, hvilket gør det lettere at huske, og netop dette udgør problemet — folk elsker at tale om deres livserfaring! Der er ikke meget at gøre ved det, bortset fra at vælge sådanne muligheder for hemmelige spørgsmål, der kan være mindre sandsynlighed for at blive udtrukket med social engineering.
[Fortsættelse følger.]
Annoncering
VDSina tilbyder pålidelige , hver server er tilsluttet en internetforbindelse på 500 Megabit og er gratis beskyttet mod DDoS-angreb!
Kilde: habr.com
