Jeg havde for nylig tid til at tænke igen over, hvordan en sikker adgangskode-nulstillingsfunktion skulle fungere, først da jeg byggede denne funktionalitet ind i , og så når han hjalp en anden person med at gøre noget lignende. I det andet tilfælde ville jeg give ham et link til en kanonisk ressource med alle detaljer om, hvordan man sikkert implementerer nulstillingsfunktionen. Problemet er dog, at sådan en ressource ikke findes, i hvert fald ikke en, der beskriver alt, hvad der forekommer mig vigtigt. Så jeg besluttede at skrive det selv.
Du kan se, verden af glemte adgangskoder er faktisk ret mystisk. Der er mange forskellige, fuldstændig acceptable synspunkter og mange ret farlige. Chancerne er, at du har stødt på hver af dem mange gange som slutbruger; så jeg vil prøve at bruge disse eksempler til at vise, hvem der gør det rigtigt, hvem der ikke gør det, og hvad du skal fokusere på for at få funktionen rigtigt i din app.
Kodeordslagring: hashing, kryptering og (gisp!) almindelig tekst
Vi kan ikke diskutere, hvad vi skal gøre med glemte adgangskoder, før vi diskuterer, hvordan vi gemmer dem. Adgangskoder gemmes i databasen i en af tre hovedtyper:
- Simpel tekst. Der er en adgangskodekolonne, som er gemt i almindelig tekstform.
- Krypteret. Typisk ved hjælp af symmetrisk kryptering (en nøgle bruges til både kryptering og dekryptering), og de krypterede adgangskoder gemmes også i samme kolonne.
- Hashed. Envejsproces (adgangskode kan hash, men kan ikke dehashes); adgangskode, Jeg vil gerne håbe, efterfulgt af et salt, og hver af dem er i sin egen kolonne.
Lad os gå direkte til det enkleste spørgsmål: Gem aldrig adgangskoder i almindelig tekst! Aldrig. En enkelt sårbarhed overfor , en skødesløs sikkerhedskopi eller en af snesevis af andre simple fejl - og det er det, gameover, alle dine adgangskoder - det vil sige undskyld, adgangskoder til alle dine kunder bliver offentlig ejendom. Det ville selvfølgelig betyde en stor sandsynlighed for det fra alle deres konti i andre systemer. Og det vil være din skyld.
Kryptering er bedre, men har sine svagheder. Problemet med kryptering er dekryptering; vi kan tage disse skøre cifre og konvertere dem tilbage til almindelig tekst, og når det sker, er vi tilbage til den menneskeligt læsbare adgangskodesituation. Hvordan sker dette? En lille fejl kommer ind i koden, der dekrypterer adgangskoden, hvilket gør den offentlig tilgængelig - dette er en måde. Hackere får adgang til den maskine, hvor krypterede data er gemt - dette er den anden metode. En anden måde er igen at stjæle databasens backup og nogen får også krypteringsnøglen, som ofte er meget usikkert gemt.
Og dette bringer os til hashing. Ideen bag hashing er, at det er envejs; den eneste måde at sammenligne den brugerindtastede adgangskode med dens hash-version er at hash input og sammenligne dem. For at forhindre angreb fra værktøjer som regnbueborde salter vi processen med tilfældighed (læs min om kryptografisk opbevaring). I sidste ende, hvis implementeret korrekt, kan vi være sikre på, at hash-kodeord aldrig bliver almindelig tekst igen (jeg vil tale om fordelene ved forskellige hashing-algoritmer i et andet indlæg).
Et hurtigt argument om hashing vs. kryptering: den eneste grund til, at du nogensinde har brug for at kryptere frem for at hash en adgangskode er, når du skal se adgangskoden i almindelig tekst, og du burde aldrig ønske dette, i det mindste i en standard hjemmesidesituation. Hvis du har brug for dette, så gør du højst sandsynligt noget forkert!
Advarsel!
Nedenfor i teksten til indlægget er der en del af et skærmbillede af den pornografiske hjemmeside AlotPorn. Det er pænt trimmet, så der ikke er noget, du ikke kan se på stranden, men hvis det stadig er sandsynligt, at det vil give problemer, skal du ikke scrolle ned.
Nulstil altid din adgangskode aldrig ikke minde ham
Er du nogensinde blevet bedt om at oprette en funktion påmindelser adgangskode? Træd et skridt tilbage og tænk på denne anmodning omvendt: hvorfor er denne "påmindelse" nødvendig? Fordi brugeren har glemt adgangskoden. Hvad vil vi egentlig gøre? Hjælp ham med at logge ind igen.
Jeg er klar over, at ordet "påmindelse" bruges (ofte) i dagligdags betydning, men det, vi virkelig forsøger at gøre, er sikkert hjælpe brugeren med at være 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 følsomt over HTTP (vi ville bruge HTTPS), bør vi ikke sende noget følsomt via e-mail, fordi dets transportlag er usikkert. Faktisk er dette meget værre end blot at sende information over en usikker transportprotokol, fordi mail ofte er gemt på en lagerenhed, tilgængelig for systemadministratorer, videresendt og distribueret, tilgængelig for malware og så videre. Ukrypteret e-mail er en ekstremt usikker kanal.
- Du burde alligevel ikke have adgang til adgangskoden. Læs det forrige afsnit om opbevaring igen - du bør have en hash af adgangskoden (med et godt stærkt salt), hvilket betyder, at du ikke på nogen måde skal kunne udtrække adgangskoden og sende den med posten.
Lad mig demonstrere problemet med et eksempel : Her er en typisk login-side:
Det første problem er naturligvis, at login-siden ikke indlæses over HTTPS, men siden beder dig også om at sende en adgangskode ("Send adgangskode"). Dette kan være et eksempel på den daglige brug af udtrykket nævnt ovenfor, så lad os tage det et skridt videre og se, hvad der sker:
Det ser ikke meget bedre ud, desværre; og en e-mail bekræfter, at der er et problem:
Dette fortæller os to vigtige aspekter af usoutdoor.com:
- Siden hash ikke adgangskoder. I bedste fald er de krypteret, men det er sandsynligt, at de er gemt i almindelig tekst; Vi ser ingen beviser for det modsatte.
- Siden sender en langsigtet adgangskode (vi kan gå tilbage og bruge den igen og igen) over en usikret kanal.
Med dette af vejen, skal vi kontrollere, om nulstillingsprocessen er udført på en sikker måde. Det første skridt til at gøre dette er at sikre, at anmoderen har ret til at udføre nulstillingen. Med andre ord, før dette har vi brug for et identitetstjek; lad os tage et kig på, hvad der sker, når en identitet bekræftes uden først at bekræfte, at anmoderen faktisk er kontoejeren.
Angivelse af brugernavne og dets indvirkning på anonymitet
Dette problem illustreres bedst visuelt. Problem:
Ser du? Vær opmærksom på beskeden "Der er ingen bruger registreret med denne e-mailadresse." Problemet opstår naturligvis, hvis et sådant websted bekræfter tilgængelighed bruger registreret med en sådan e-mailadresse. Bingo - du har lige opdaget din mand/boss/nabos pornofetich!
Selvfølgelig er porno et ret ikonisk eksempel på vigtigheden af privatlivets fred, men farerne ved at forbinde en person med et specifikt websted er meget bredere end den potentielt akavede situation beskrevet ovenfor. En fare er social engineering; Hvis angriberen kan matche en person med tjenesten, vil han have information, som han kan begynde at bruge. For eksempel kan han kontakte en person, der udgiver sig for at være repræsentant for et websted og anmode om yderligere oplysninger i et forsøg på at forpligte sig .
Sådan praksis rejser også faren for "brugernavneumeration", hvorved man kan verificere eksistensen af en hel samling af brugernavne eller e-mailadresser på et websted ved blot at udføre gruppeforespørgsler og undersøge svarene på dem. Har du en liste over mailadresser på alle medarbejdere og et par minutter til at skrive et manuskript? Så kan du se, hvad problemet er!
Hvad er alternativet? Faktisk er det ret simpelt og er fantastisk implementeret i :
Her oplyser Entropay absolut intet om eksistensen af en e-mailadresse i sit system til en person, der ikke ejer denne adresse... hvis du egen denne adresse og den ikke findes i systemet, så vil du modtage en e-mail som denne:
Selvfølgelig kan der være acceptable situationer, hvor nogen tænkerat du har registreret dig på hjemmesiden. men dette er ikke tilfældet, eller jeg gjorde det fra en anden e-mailadresse. Eksemplet ovenfor håndterer begge situationer godt. Hvis adressen matcher, vil du naturligvis modtage en e-mail, der gør det nemmere at nulstille din adgangskode.
Det fine ved løsningen valgt af Entropay er, at identifikationsverifikation udføres iht e-mail før enhver online verifikation. Nogle websteder beder brugerne om svaret på et sikkerhedsspørgsmål (mere om dette nedenfor) til hvordan nulstillingen kan begynde; problemet med dette er dog, at du skal besvare spørgsmålet samtidig med at du angiver 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 den anonyme brugers konto.
Med denne tilgang er der lille nedsat brugervenlighed, fordi hvis du forsøger at nulstille en ikke-eksisterende konto, er der ingen øjeblikkelig feedback. Det er selvfølgelig hele pointen med at sende en e-mail, men fra en reel slutbrugers perspektiv, hvis de indtaster den forkerte adresse, vil de først vide, hvornår de modtager e-mailen. Dette kan forårsage nogle spændinger fra hans side, men det er en lille pris at betale for en så sjælden proces.
En anden note, lidt uden for emnet: login-hjælpefunktioner, der afslører, om et brugernavn eller en e-mailadresse er korrekt, har det samme problem. Svar altid brugeren med en "Dit brugernavn og adgangskodekombination er ugyldig"-meddelelse i stedet for eksplicit at bekræfte eksistensen af legitimationsoplysningerne (f.eks. "brugernavnet er korrekt, men adgangskoden er forkert").
Sender nulstillet adgangskode vs afsendelse af nulstillet URL
Det næste koncept, vi skal diskutere, er, hvordan du nulstiller din adgangskode. Der er to populære løsninger:
- Genererer en ny adgangskode på serveren og sender den via e-mail
- Send en e-mail med en unik URL for at gøre nulstillingsprocessen nemmere
Trods , bør det første punkt aldrig bruges. Problemet med dette er, at det betyder, at der er gemt adgangskode, som du til enhver tid kan vende tilbage til og bruge igen; den blev sendt over en usikker kanal og forbliver i din indbakke. Chancerne er, at indbakker synkroniseres på tværs af mobile enheder og e-mail-klienten, plus at de kan blive gemt online i web-e-mail-tjenesten i meget lang tid. Pointen er det en postkasse kan ikke betragtes som et pålideligt middel til langtidsopbevaring.
Men udover dette har det første punkt et andet alvorligt problem - det forenkler så meget som muligt blokering af en konto med ondsindet hensigt. Hvis jeg kender e-mailadressen på en person, der ejer en konto på et websted, så kan jeg til enhver tid blokere dem ved blot at nulstille deres adgangskode; Dette er et lammelsesangreb serveret på et sølvfad! Dette er grunden til, at nulstillingen kun bør udføres efter vellykket verifikation af anmoderens rettigheder til den.
Når vi taler om en nulstillet URL, mener vi adressen på et websted, dvs unik for dette særlige tilfælde af nulstillingsprocessen. Det skal selvfølgelig være tilfældigt, det skal ikke være nemt at gætte, og det skal ikke indeholde eksterne links til kontoen, der gør det nemmere at nulstille. For eksempel skal nulstillings-URL'en ikke blot være en sti som "Reset/?brugernavn=JohnSmith".
Vi ønsker at oprette et unikt token, der kan sendes som en nulstillings-URL og derefter matches mod serverposten for brugerens konto, og dermed bekræfte, at kontoejeren faktisk er den samme person, som forsøger at nulstille adgangskoden . For eksempel kunne et token være "3ce7854015cd38c862cb9e14a1ae552b" og gemt i en tabel sammen med ID'et på den bruger, der udfører nulstillingen, og tidspunktet, hvor tokenet blev genereret (mere om dette nedenfor). Når e-mailen sendes, indeholder den en URL som "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", og når brugeren downloader den, spørger siden om eksistensen af tokenet, hvorefter den bekræfter brugerens oplysninger og giver dem mulighed for at ændre adgangskode.
Da processen ovenfor (forhåbentlig) tillader brugeren at oprette en ny adgangskode, skal vi selvfølgelig sikre, at URL'en indlæses over HTTPS. Ingen, , skal denne token-URL bruge transportlagssikkerhed, så den nye adgangskodeformular ikke kan angribes og den brugeroprettede adgangskode blev overført via en sikker forbindelse.
Også for nulstillings-URL'en skal du tilføje en token-tidsgrænse, så nulstillingsprocessen kan afsluttes inden for et bestemt interval, f.eks. inden for en time. Dette sikrer, at nulstillingstidsvinduet holdes på et minimum, så modtageren af nulstillings-URL'en kun kan handle inden for det meget lille vindue. Selvfølgelig kan angriberen starte nulstillingsprocessen igen, men de bliver nødt til at få en anden unik nulstillings-URL.
Endelig skal vi sikre, at denne proces er til engangsbrug. Når nulstillingsprocessen er fuldført, skal tokenet fjernes, så nulstillings-URL'en ikke længere fungerer. Det foregående punkt er nødvendigt for at sikre, at angriberen har et meget lille vindue, hvor han kan manipulere den nulstillede URL. Plus, selvfølgelig, når nulstillingen er vellykket, er tokenet ikke længere nødvendigt.
Nogle af disse trin kan virke alt for overflødige, men de forstyrrer ikke brugervenligheden og faktisk forbedre sikkerheden, omend i situationer, som vi håber vil være sjældne. I 99 % af tilfældene vil brugeren aktivere nulstillingen inden for en meget kort periode og vil ikke nulstille adgangskoden igen i den nærmeste fremtid.
CAPTCHA's rolle
Åh, CAPTCHA, sikkerhedsfunktionen vi alle elsker at hade! Faktisk er CAPTCHA ikke så meget et beskyttelsesværktøj, som det er et identifikationsværktøj – uanset om du er en person eller en robot (eller et automatiseret script). Dens formål er at undgå automatisk formularindsendelse, hvilket naturligvis kan bruges som et forsøg på at bryde sikkerheden. I forbindelse med nulstilling af adgangskode betyder CAPTCHA, at nulstillingsfunktionen ikke kan blive brute-forced til hverken at spamme brugeren eller forsøge at fastslå eksistensen af konti (hvilket selvfølgelig ikke vil være muligt, hvis du fulgte rådene i afsnittet om bekræftelse af identiteter).
Selvfølgelig er CAPTCHA i sig selv ikke perfekt; Der er mange præcedenser for dets software "hacking" og opnåelse af tilstrækkelige succesrater (60-70%). Derudover er der vist en løsning i mit indlæg om , hvor du kan betale folk brøkdele af en cent for at løse hver CAPTCHA og opnå en succesrate på 94%. Det vil sige, at den er sårbar, men den hæver (lidt) adgangsbarrieren.
Lad os tage et kig på PayPal-eksemplet:
I dette tilfælde kan nulstillingsprocessen simpelthen ikke begynde, før CAPTCHA er løst, så i teorien det er umuligt at automatisere processen. I teorien.
Men for de fleste webapplikationer vil dette være overkill og fuldstændig ret repræsenterer et fald i brugervenlighed - folk kan bare ikke lide CAPTCHA! Derudover er CAPTCHA noget, du nemt kan vende tilbage til, hvis det er nødvendigt. Hvis tjenesten begynder at blive angrebet (det er her, logning kommer til nytte, men mere om det senere), så kunne det ikke være nemmere at tilføje en CAPTCHA.
Hemmelige spørgsmål og svar
Med alle de metoder, vi overvejede, var vi i stand til at nulstille adgangskoden blot ved at have adgang til e-mail-kontoen. Jeg siger "bare", men det er selvfølgelig ulovligt at få adgang til en andens e-mail-konto. skal være en kompleks proces. Imidlertid .
Faktisk er linket ovenfor om hackingen af Sarah Palins Yahoo! tjener to formål; for det første illustrerer det, hvor nemt det er at hacke (nogle) e-mail-konti, og for det andet viser det, hvor dårlige sikkerhedsspørgsmål kan bruges med ondsindet hensigt. Men det vender vi tilbage til senere.
Problemet med XNUMX % e-mail-baserede adgangskoder er, at integriteten af kontoen for det websted, du forsøger at nulstille, bliver XNUMX % afhængig af e-mail-kontoens integritet. 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-mail "nøglen til alle døre" i dit onlineliv.
En måde at reducere denne risiko på er at implementere et sikkerhedsspørgsmål og -svar-mønster. Du har uden tvivl allerede set dem: Vælg et spørgsmål, som kun du kan svare på have kender svaret, og når du nulstiller din adgangskode, bliver du bedt om det. Dette tilføjer tillid til, at den person, der forsøger at nulstille, faktisk er kontoejeren.
Tilbage til Sarah Palin: fejlen var, at svarene på hendes sikkerhedsspørgsmål/-spørgsmål nemt kunne findes. Især når du er en så betydningsfuld offentlig person, er oplysninger om din mors pigenavn, uddannelseshistorie, eller hvor nogen måske har boet i fortiden, ikke så hemmelige. Faktisk kan det meste af det findes af næsten alle. Dette er, hvad der skete med Sarah:
Hackeren David Kernell fik adgang til Palins konto ved at finde detaljer om hendes baggrund, såsom hendes universitet og fødselsdato, og derefter bruge Yahoo!s funktion til gendannelse af glemt adgangskode.
Først og fremmest er dette en designfejl fra Yahoo! — Ved at specificere sådanne simple spørgsmål saboterede virksomheden i det væsentlige værdien af sikkerhedsspørgsmålet og dermed beskyttelsen af sit system. Naturligvis er nulstilling af adgangskoder til en e-mail-konto altid sværere, da du ikke kan bevise ejerskab ved at sende en e-mail til ejeren (uden at have en anden adresse), men heldigvis er der ikke mange anvendelser til at oprette et sådant system i dag.
Lad os vende tilbage til sikkerhedsspørgsmål - der er mulighed for at give brugeren mulighed for at oprette deres egne spørgsmål. Problemet er, at dette vil resultere i frygtelig indlysende spørgsmål:
Hvilken farve er himlen?
Spørgsmål, der gør folk utilpas, når et sikkerhedsspørgsmål bruges til at identificere mennesker (f.eks. i et callcenter):
Hvem sov jeg med i julen?
Eller helt ærligt dumme spørgsmål:
Hvordan staver man "adgangskode"?
Når det kommer til sikkerhedsspørgsmål, skal brugerne reddes fra sig selv! Med andre ord bør sikkerhedsspørgsmålet bestemmes af webstedet selv, eller endnu bedre, stilles serie sikkerhedsspørgsmål, som brugeren kan vælge imellem. Og det er ikke nemt at vælge en; ideelt set bør brugeren vælge to eller flere sikkerhedsspørgsmål på tidspunktet for kontoregistrering, som derefter vil blive brugt som en anden identifikationskanal. At have flere spørgsmål øger tilliden til verifikationsprocessen og giver også mulighed for at tilføje tilfældigheder (ikke altid at vise det samme spørgsmål), plus giver en smule redundans, hvis den faktiske bruger har glemt adgangskoden.
Hvad er et godt sikkerhedsspørgsmål? Dette påvirkes af flere faktorer:
- Det må han være kort — Spørgsmålet skal være klart og utvetydigt.
- Svaret må være bestemt - vi har ikke brug for et spørgsmål, som én person kan besvare forskelligt
- Mulige svar bør være alsidig - At spørge nogens yndlingsfarve giver en meget lille delmængde af mulige svar
- søgning svaret skal være komplekst – hvis svaret let kan findes enhver (husk folk i høje stillinger), så er han dårlig
- Svaret må være permanent med tiden - hvis du spørger nogens yndlingsfilm, så et år senere kan svaret være anderledes
Som det sker, er der en hjemmeside dedikeret til at stille gode spørgsmål kaldet . Nogle af spørgsmålene virker ganske gode, andre består ikke nogle af de test, der er beskrevet ovenfor, især testen "lethed at søge".
Lad mig demonstrere, hvordan PayPal implementerer sikkerhedsspørgsmål og især den indsats, webstedet lægger i godkendelse. Ovenfor så vi siden for at starte processen (med en CAPTCHA), og her vil vi vise, hvad der sker, efter du har indtastet din e-mailadresse og løst CAPTCHA:
Som et resultat modtager brugeren følgende brev:
Indtil videre er alt ganske normalt, men her er hvad der gemmer sig bag denne nulstillede URL:
Så sikkerhedsspørgsmål spiller ind. Faktisk giver PayPal dig også mulighed for at nulstille din adgangskode ved at bekræfte dit kreditkortnummer, så der er en ekstra kanal, som mange websteder ikke har adgang til. Jeg kan bare ikke ændre min adgangskode uden at svare begge sikkerhedsspørgsmål (eller ikke at kende kortnummeret). Selv hvis nogen kaprede min e-mail, ville de ikke være i stand til at nulstille min PayPal-konto adgangskode, medmindre de kendte lidt mere personlige oplysninger om mig. Hvilken information? Her er mulighederne for sikkerhedsspørgsmål, som PayPal tilbyder:
Skole- og hospitalsspørgsmålet kan være lidt usikkert med hensyn til nem søgning, men de andre er ikke så dårlige. Men for at øge sikkerheden kræver PayPal yderligere identifikation for ændringer svar på sikkerhedsspørgsmål:
PayPal er et ret utopisk eksempel på sikker nulstilling af adgangskoder: den implementerer en CAPTCHA for at reducere faren for brute-force-angreb, kræver to sikkerhedsspørgsmål og kræver så en anden slags helt anden identifikation bare for at ændre svarene - og dette efter brugeren har allerede logget ind. Det er selvfølgelig præcis, hvad vi forventet fra PayPal; er en finansiel institution, der beskæftiger sig med store summer. Dette betyder ikke, at enhver nulstilling af adgangskode skal følge disse trin – det meste af tiden er det overkill – men det er et godt eksempel i tilfælde, hvor sikkerhed er en seriøs forretning.
Det praktiske ved sikkerhedsspørgsmålssystemet er, at hvis du ikke har implementeret det med det samme, kan du tilføje det senere, hvis niveauet af ressourcebeskyttelse kræver det. Et godt eksempel på dette er Apple, som først for nylig implementerede denne mekanisme [artikel skrevet i 2012]. Da jeg begyndte at opdatere applikationen på min iPad, så jeg følgende anmodning:
Så så jeg en skærm, hvor jeg kunne vælge flere par sikkerhedsspørgsmål og -svar, samt en rednings-e-mailadresse:
Hvad angår PayPal, er spørgsmålene forudvalgte, og nogle af dem er faktisk ret gode:
Hvert af de tre spørgsmål/svar-par repræsenterer et andet sæt mulige spørgsmål, så der er masser af måder at konfigurere en konto på.
Et andet aspekt at overveje i forbindelse med besvarelsen af dit sikkerhedsspørgsmål er opbevaring. At have en almindelig tekstdatabase i databasen udgør næsten de samme trusler som en adgangskode, nemlig at blotlæggelse af databasen øjeblikkeligt afslører værdien og sætter ikke kun applikationen i fare, men potentielt helt forskellige applikationer, der bruger de samme sikkerhedsspørgsmål (der igen) ). En mulighed er sikker hashing (en stærk algoritme og et kryptografisk tilfældigt salt), men i modsætning til de fleste password-lagringssager kan der være en god grund til, at svaret er synligt som almindelig tekst. Et typisk scenarie er identitetsbekræftelse af en direkte telefonoperatør. Selvfølgelig er hashing også anvendelig i dette tilfælde (operatøren kan blot indtaste det svar, som klienten har navngivet), men i værste tilfælde skal det hemmelige svar være placeret på et niveau af kryptografisk lagring, selvom det blot er symmetrisk kryptering . Sammenfatte: behandle hemmeligheder som hemmeligheder!
Et sidste aspekt af sikkerhedsspørgsmål og -svar er, at de er mere sårbare over for social engineering. At prøve at udtrække adgangskoden direkte til en andens konto er én ting, men at starte en samtale om dens dannelse (et populært sikkerhedsspørgsmål) er helt anderledes. Faktisk kan du meget vel kommunikere med nogen om mange aspekter af deres liv, der kan stille et hemmeligt spørgsmål uden at vække mistanke. Selvfølgelig er selve pointen med et sikkerhedsspørgsmål, at det relaterer til en persons livserfaring, så det er mindeværdigt, og det er der, problemet ligger - folk elsker at fortælle om deres livserfaringer! Der er lidt du kan gøre ved dette, kun hvis du vælger sådanne sikkerhedsspørgsmål, så de er det mindre kunne sandsynligvis trækkes ud af social engineering.
[Fortsættes.]Om reklamernes rettigheder
VDSina tilbyder pålidelige , hver server er forbundet til en internetkanal på 500 megabit og er gratis beskyttet mod DDoS-angreb!
Kilde: www.habr.com