Ek het onlangs tyd gehad om weer te dink oor hoe 'n veilige wagwoordterugstelfunksie moet werk, eers toe ek hierdie funksionaliteit ingebou het , en toe hy 'n ander persoon gehelp het om iets soortgelyks te doen. In die tweede geval wou ek vir hom 'n skakel gee na 'n kanonieke hulpbron met al die besonderhede van hoe om die herstelfunksie veilig te implementeer. Die probleem is egter dat so 'n hulpbron nie bestaan nie, ten minste nie een wat alles beskryf wat vir my belangrik lyk nie. Daarom het ek besluit om dit self te skryf.
Jy sien, die wêreld van vergete wagwoorde is eintlik nogal 'n geheimsinnige een. Daar is baie verskillende, heeltemal aanvaarbare standpunte en baie baie gevaarlike. Die kans is goed dat jy elkeen van hulle al baie keer as 'n eindgebruiker teëgekom het; so ek sal probeer om hierdie voorbeelde te gebruik om te wys wie dit reg doen, wie nie, en waarop jy moet fokus om die kenmerk reg in jou toepassing te kry.
Wagwoordberging: hashing, enkripsie en (hyg!) gewone teks
Ons kan nie bespreek wat om met vergete wagwoorde te doen voordat ons bespreek hoe om dit te stoor nie. Wagwoorde word in een van drie hooftipes in die databasis gestoor:
- Eenvoudige teks. Daar is 'n wagwoordkolom wat in gewone teksvorm gestoor word.
- Geënkripteer. Gebruik tipies simmetriese enkripsie (een sleutel word vir beide enkripsie en dekripsie gebruik), en die geënkripteerde wagwoorde word ook in dieselfde kolom gestoor.
- Gehaas. Eenrigting-proses (wagwoord kan gehash word, maar kan nie onthas word nie); wagwoord, Ek wil graag hoop, gevolg deur 'n sout, en elkeen is in sy eie kolom.
Kom ons gaan reguit na die eenvoudigste vraag: Moet nooit wagwoorde in gewone teks stoor nie! Nooit nie. Een enkele kwesbaarheid vir , een sorgelose rugsteun, of een van dosyne ander eenvoudige foute - en dit is dit, gameover, al jou wagwoorde - dit is, jammer, wagwoorde van al jou kliënte publieke domein sal word. Natuurlik sou dit 'n groot waarskynlikheid beteken dat van al hul rekeninge in ander stelsels. En dit sal jou skuld wees.
Enkripsie is beter, maar het sy swakhede. Die probleem met enkripsie is dekripsie; ons kan hierdie gek kyk syfers neem en dit terug omskakel na gewone teks, en wanneer dit gebeur, is ons terug na die mens-leesbare wagwoord situasie. Hoe gebeur dit? 'n Klein fout kom in die kode wat die wagwoord dekripteer, wat dit publiek beskikbaar maak - dit is een manier. Kuberkrakers kry toegang tot die masjien waarop geënkripteerde data gestoor word – dit is die tweede metode. Nog 'n manier, weereens, is om die databasisrugsteun te steel en iemand kry ook die enkripsiesleutel, wat dikwels baie onveilig gestoor word.
En dit bring ons by hashing. Die idee agter hashing is dat dit eenrigting is; Die enigste manier om die wagwoord wat deur die gebruiker ingevoer is met sy gehashte weergawe te vergelyk, is om die invoer te hash en dit te vergelyk. Om aanvalle van gereedskap soos reënboogtafels te voorkom, sout ons die proses met willekeurigheid (lees my oor kriptografiese berging). Uiteindelik, as dit korrek geïmplementeer word, kan ons vol vertroue wees dat gehashte wagwoorde nooit weer gewone teks sal word nie (ek sal in 'n ander pos oor die voordele van verskillende hashing-algoritmes praat).
'n Vinnige argument oor hashing vs. enkripsie: die enigste rede waarom jy ooit sal moet enkripteer eerder as om 'n wagwoord te hash, is wanneer jy die wagwoord in gewone teks moet sien, en jy moet dit nooit wil hê nie, ten minste in 'n standaard webwerf situasie. As jy dit nodig het, dan doen jy heel waarskynlik iets verkeerd!
Внимание!
Onder in die teks van die pos is daar deel van 'n skermskoot van die pornografiese webwerf AlotPorn. Dit is netjies afgewerk sodat daar niks is wat jy nie op die strand kan sien nie, maar as dit steeds waarskynlik enige probleme sal veroorsaak, moenie afrol nie.
Stel altyd jou wagwoord terug nooit moet hom nie herinner nie
Is jy al ooit gevra om 'n funksie te skep aanmanings wagwoord? Neem 'n tree terug en dink omgekeerd oor hierdie versoek: hoekom is hierdie "herinnering" nodig? Omdat die gebruiker die wagwoord vergeet het. Wat wil ons regtig doen? Help hom om weer aan te meld.
Ek besef die woord "herinnering" word (dikwels) in 'n spreektaal sin gebruik, maar wat ons regtig probeer doen, is help die gebruiker veilig om weer aanlyn te wees. Aangesien ons sekuriteit nodig het, is daar twee redes waarom 'n aanmaning (d.w.s. die stuur van die gebruiker hul wagwoord) nie gepas is nie:
- E-pos is 'n onveilige kanaal. Net soos ons niks sensitiefs oor HTTP sal stuur nie (ons sal HTTPS gebruik), moet ons niks sensitiefs per e-pos stuur nie, want die vervoerlaag daarvan is onseker. Trouens, dit is baie erger as om bloot inligting oor 'n onveilige vervoerprotokol te stuur, want pos word dikwels op 'n stoortoestel gestoor, toeganklik vir stelseladministrateurs, aangestuur en versprei, toeganklik vir wanware, ensovoorts. Ongeënkripteerde e-pos is 'n uiters onveilige kanaal.
- Jy behoort in elk geval nie toegang tot die wagwoord te hê nie. Lees weer die vorige afdeling oor berging - jy moet 'n hash van die wagwoord hê (met 'n goeie sterk sout), wat beteken dat jy op geen manier die wagwoord moet kan onttrek en dit per pos kan stuur nie.
Kom ek demonstreer die probleem met 'n voorbeeld : Hier is 'n tipiese aanmeldbladsy:
Natuurlik is die eerste probleem dat die aanmeldbladsy nie oor HTTPS laai nie, maar die webwerf vra jou ook om 'n wagwoord te stuur ("Stuur wagwoord"). Dit kan 'n voorbeeld wees van die omgangstaal gebruik van die term hierbo genoem, so kom ons neem dit 'n stap verder en kyk wat gebeur:
Dit lyk ongelukkig nie veel beter nie; en 'n e-pos bevestig dat daar 'n probleem is:
Dit vertel ons twee belangrike aspekte van usoutdoor.com:
- Die webwerf het nie wagwoorde nie. Op sy beste is hulle geïnkripteer, maar dit is waarskynlik dat hulle in gewone teks gestoor word; Ons sien geen bewyse van die teendeel nie.
- Die webwerf stuur 'n langtermyn wagwoord (ons kan teruggaan en dit weer en weer gebruik) oor 'n onversekerde kanaal.
Met dit uit die pad, moet ons kyk of die herstelproses op 'n veilige manier gedoen word. Die eerste stap om dit te doen is om seker te maak dat die versoeker die reg het om die terugstelling uit te voer. Met ander woorde, voor dit het ons 'n identiteitskontrole nodig; kom ons kyk na wat gebeur wanneer 'n identiteit geverifieer word sonder om eers te verifieer dat die versoeker eintlik die rekeningeienaar is.
Lys gebruikersname en die impak daarvan op anonimiteit
Hierdie probleem word die beste visueel geïllustreer. Probleem:
Sien jy? Gee aandag aan die boodskap "Daar is geen gebruiker met hierdie e-posadres geregistreer nie." Die probleem ontstaan natuurlik as so 'n webwerf bevestig beskikbaarheid gebruiker geregistreer met sodanige e-posadres. Bingo - jy het sopas jou man/baas/buurman se porno-fetisj ontdek!
Natuurlik is pornografie 'n taamlik ikoniese voorbeeld van die belangrikheid van privaatheid, maar die gevare om 'n individu met 'n spesifieke webwerf te assosieer is baie wyer as die potensieel ongemaklike situasie hierbo beskryf. Een gevaar is sosiale ingenieurswese; As die aanvaller 'n persoon met die diens kan koppel, sal hy inligting hê wat hy kan begin gebruik. Hy kan byvoorbeeld 'n persoon kontak wat hom voordoen as 'n verteenwoordiger van 'n webwerf en bykomende inligting aanvra in 'n poging om te pleeg .
Sulke praktyke skep ook die gevaar van "gebruikersnaamopsomming," waardeur 'n mens die bestaan van 'n hele versameling gebruikername of e-posadresse op 'n webwerf kan verifieer deur bloot groepnavrae te doen en die antwoorde daarop te ondersoek. Het jy 'n lys e-posadresse van alle werknemers en 'n paar minute om 'n draaiboek te skryf? Dan sien jy wat die probleem is!
Wat is die alternatief? Trouens, dit is redelik eenvoudig, en is wonderlik geïmplementeer in :
Hier openbaar Entropay absoluut niks oor die bestaan van 'n e-posadres in sy stelsel nie aan iemand wat nie hierdie adres besit nie... As jy eie hierdie adres en dit bestaan nie in die stelsel nie, dan sal jy 'n e-pos soos hierdie ontvang:
Natuurlik kan daar aanvaarbare situasies wees waarin iemand dinkwat jy op die webwerf geregistreer het. maar dit is nie die geval nie, of ek het dit vanaf 'n ander e-posadres gedoen. Die voorbeeld hierbo hanteer beide situasies goed. Natuurlik, as die adres ooreenstem, sal jy 'n e-pos ontvang wat dit makliker maak om jou wagwoord terug te stel.
Die subtiliteit van die oplossing wat deur Entropay gekies is, is dat identifikasie verifikasie uitgevoer word volgens e-pos voor enige aanlyn verifikasie. Sommige werwe vra gebruikers vir die antwoord op 'n sekuriteitsvraag (meer hieroor hieronder) aan hoe die herstel kan begin; die probleem hiermee is egter dat jy die vraag moet beantwoord terwyl jy een of ander vorm van identifikasie (e-pos of gebruikernaam) verskaf, wat dit dan byna onmoontlik maak om intuïtief te antwoord sonder om die bestaan van die anonieme gebruiker se rekening te openbaar.
Met hierdie benadering is daar klein verminderde bruikbaarheid, want as jy probeer om 'n nie-bestaande rekening terug te stel, is daar geen onmiddellike terugvoer nie. Dit is natuurlik die hele punt om 'n e-pos te stuur, maar vanuit 'n regte eindgebruiker se perspektief, as hulle die verkeerde adres invoer, sal hulle eers vir die eerste keer weet wanneer hulle die e-pos ontvang. Dit kan 'n mate van spanning aan sy kant veroorsaak, maar dit is 'n klein prys om te betaal vir so 'n seldsame proses.
Nog 'n nota, effens buite die onderwerp: aanmeldhulpfunksies wat aandui of 'n gebruikersnaam of e-posadres korrek is, het dieselfde probleem. Reageer altyd op die gebruiker met 'n "Jou gebruikersnaam en wagwoord kombinasie is ongeldig" boodskap eerder as om die bestaan van die geloofsbriewe uitdruklik te bevestig (byvoorbeeld, "die gebruikersnaam is korrek, maar die wagwoord is verkeerd").
Stuur terugstel wagwoord vs stuur terugstel URL
Die volgende konsep wat ons moet bespreek, is hoe om jou wagwoord terug te stel. Daar is twee gewilde oplossings:
- Genereer 'n nuwe wagwoord op die bediener en stuur dit per e-pos
- Stuur 'n e-pos met 'n unieke URL om die herstelproses makliker te maak
Ten spyte van , moet die eerste punt nooit gebruik word nie. Die probleem hiermee is dat dit beteken daar is gestoor wagwoord, waarna jy enige tyd kan terugkeer en weer kan gebruik; dit is oor 'n onveilige kanaal gestuur en bly in jou inkassie. Die kans is goed dat inkassies tussen mobiele toestelle en die e-poskliënt gesinkroniseer word, en dit kan vir 'n baie lang tyd aanlyn in die web-e-posdiens gestoor word. Die punt is dat 'n posbus kan nie as 'n betroubare manier van langtermynberging beskou word nie.
Maar behalwe dit het die eerste punt nog 'n ernstige probleem - dit vereenvoudig soveel as moontlik om 'n rekening met kwaadwillige opset te blokkeer. As ek die e-posadres van iemand ken wat 'n rekening op 'n webwerf besit, dan kan ek hulle enige tyd blokkeer deur bloot hul wagwoord terug te stel; Hierdie is 'n ontkenning van diens aanval wat op 'n silwer skinkbord bedien word! Dit is hoekom die terugstelling slegs uitgevoer moet word na suksesvolle verifikasie van die versoeker se regte daarop.
As ons praat oor 'n herstel-URL, bedoel ons die adres van 'n webwerf wat is uniek aan hierdie spesifieke geval van die herstelproses. Dit moet natuurlik ewekansig wees, dit moet nie maklik wees om te raai nie, en dit moet geen eksterne skakels na die rekening bevat wat dit makliker maak om terug te stel nie. Byvoorbeeld, die terugstel-URL moet nie bloot 'n pad soos "Reset/?username=JohnSmith" wees nie.
Ons wil 'n unieke teken skep wat as 'n terugstelling-URL gepos kan word, en dan ooreenstem met die bedienerrekord van die gebruiker se rekening, om sodoende te bevestig dat die rekeningeienaar in werklikheid dieselfde persoon is wat probeer om die wagwoord terug te stel. Byvoorbeeld, 'n teken kan "3ce7854015cd38c862cb9e14a1ae552b" wees en in 'n tabel gestoor word saam met die ID van die gebruiker wat die terugstelling uitvoer en die tyd wat die teken gegenereer is (meer hieroor hieronder). Wanneer die e-pos gestuur word, bevat dit 'n URL soos “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, en wanneer die gebruiker dit aflaai, vra die bladsy vir die bestaan van die teken, waarna dit die gebruiker se inligting bevestig en hulle toelaat om die wagwoord.
Natuurlik, aangesien die proses hierbo (hopelik) die gebruiker toelaat om 'n nuwe wagwoord te skep, moet ons verseker dat die URL oor HTTPS gelaai word. Geen, , moet hierdie teken-URL vervoerlaagsekuriteit gebruik sodat die nuwe wagwoordvorm nie aangeval kan word nie en die gebruiker-geskepte wagwoord is oor 'n veilige verbinding versend.
Ook vir die terugstel-URL moet jy 'n tekentydperk byvoeg sodat die herstelproses binne 'n sekere interval voltooi kan word, sê binne 'n uur. Dit verseker dat die terugsteltydvenster tot 'n minimum beperk word sodat die ontvanger van die herstel-URL slegs binne daardie baie klein venster kan optree. Natuurlik kan die aanvaller die herstelproses weer begin, maar hulle sal 'n ander unieke terugstel-URL moet kry.
Ten slotte moet ons verseker dat hierdie proses weggooibaar is. Sodra die herstelproses voltooi is, moet die teken verwyder word sodat die herstel-URL nie meer funksioneel is nie. Die vorige punt is nodig om te verseker dat die aanvaller 'n baie klein venster het waartydens hy die reset-URL kan manipuleer. Plus, natuurlik, sodra die herstel suksesvol is, is die teken nie meer nodig nie.
Sommige van hierdie stappe lyk dalk te oorbodig, maar dit meng nie in met bruikbaarheid en in werklikheid verbeter veiligheid, al is dit in situasies wat ons hoop skaars sal wees. In 99% van die gevalle sal die gebruiker die terugstelling binne 'n baie kort tydperk aktiveer en sal nie die wagwoord weer in die nabye toekoms terugstel nie.
Rol van CAPTCHA
O, CAPTCHA, die sekuriteitskenmerk wat ons almal graag haat! Trouens, CAPTCHA is nie soseer 'n beskermingsinstrument nie, maar dit is 'n identifikasie-instrument - of jy nou 'n persoon of 'n robot (of 'n outomatiese skrif) is. Die doel daarvan is om outomatiese vorm indiening te vermy, wat natuurlik, kan gebruik word as 'n poging om die sekuriteit te breek. In die konteks van wagwoordterugstellings beteken CAPTCHA dat die terugstelfunksie nie brutaal gedwing kan word om die gebruiker óf strooipos te stuur óf die bestaan van rekeninge te probeer vasstel nie (wat natuurlik nie moontlik sal wees as jy die advies in die afdeling oor identiteite te verifieer).
Natuurlik is die CAPTCHA self nie perfek nie; Daar is baie presedente vir sy sagteware "hacking" en die bereiking van voldoende sukseskoerse (60-70%). Daarbenewens is daar 'n oplossing wat in my pos oor , waar jy mense breukdele van 'n sent kan betaal om elke CAPTCHA op te los en 'n sukseskoers van 94% te behaal. Dit wil sê, dit is kwesbaar, maar dit verhoog (effens) die hindernis vir toegang.
Kom ons kyk na die PayPal-voorbeeld:
In hierdie geval kan die herstelproses eenvoudig nie begin totdat die CAPTCHA opgelos is nie, dus in teorie dit is onmoontlik om die proses te outomatiseer. In teorie.
Vir die meeste webtoepassings sal dit egter te veel wees en absoluut reg verteenwoordig 'n afname in bruikbaarheid - mense hou net nie van CAPTCHA nie! Daarbenewens is CAPTCHA iets waarna u maklik kan terugkeer indien nodig. As die diens begin aangeval word (dit is waar aanteken handig te pas kom, maar later meer daaroor), dan kan dit nie makliker wees om 'n CAPTCHA by te voeg nie.
Geheime vrae en antwoorde
Met al die metodes wat ons oorweeg het, kon ons die wagwoord terugstel net deur toegang tot die e-posrekening te hê. Ek sê “net”, maar dit is natuurlik onwettig om toegang tot iemand anders se e-posrekening te kry. moet 'n komplekse proses wees. Egter .
Trouens, die skakel hierbo oor die inbraak van Sarah Palin se Yahoo! dien twee doeleindes; eerstens illustreer dit hoe maklik dit is om (sommige) e-posrekeninge te hack, en tweedens wys dit hoe slegte sekuriteitsvrae met kwaadwillige bedoelings gebruik kan word. Maar ons kom later hierop terug.
Die probleem met 100% e-pos-gebaseerde wagwoordterugstellings is dat die integriteit van die rekening vir die webwerf wat jy probeer terugstel 100% afhanklik word van die integriteit van die e-posrekening. Enigiemand wat toegang tot jou e-pos het het toegang tot enige rekening wat teruggestel kan word deur bloot 'n e-pos te ontvang. Vir sulke rekeninge is e-pos die "sleutel tot alle deure" van jou aanlyn lewe.
Een manier om hierdie risiko te verminder, is om 'n veiligheidsvraag-en-antwoordpatroon te implementeer. Jy het hulle ongetwyfeld al gesien: kies 'n vraag wat net jy kan beantwoord het ken die antwoord, en wanneer jy jou wagwoord terugstel, sal jy daarvoor gevra word. Dit voeg vertroue by dat die persoon wat die herstel probeer, inderdaad die rekeningeienaar is.
Terug na Sarah Palin: die fout was dat die antwoorde op haar veiligheidsvraag/-vrae maklik gevind kon word. Veral wanneer jy so 'n belangrike openbare figuur is, is inligting oor jou ma se nooiensvan, opvoedkundige geskiedenis of waar iemand dalk in die verlede gewoon het nie so geheim nie. Trouens, die meeste daarvan kan byna enigiemand gevind word. Dit is wat met Sarah gebeur het:
Die hacker David Kernell het toegang tot Palin se rekening gekry deur besonderhede oor haar agtergrond te vind, soos haar universiteit en geboortedatum, en dan Yahoo! se vergete wagwoordherstelfunksie te gebruik.
Eerstens, dit is 'n ontwerpfout aan die kant van Yahoo! — deur sulke eenvoudige vrae te spesifiseer, het die maatskappy in wese die waarde van die sekuriteitsvraag gesaboteer, en dus die beskerming van sy stelsel. Natuurlik is die terugstel van wagwoorde vir 'n e-posrekening altyd moeiliker aangesien jy nie eienaarskap kan bewys deur 'n e-pos aan die eienaar te stuur nie (sonder om 'n tweede adres te hê), maar gelukkig is daar vandag nie baie gebruike om so 'n stelsel te skep nie.
Kom ons keer terug na sekuriteitsvrae – daar is 'n opsie om die gebruiker toe te laat om hul eie vrae te skep. Die probleem is dat dit verskriklik ooglopende vrae tot gevolg sal hê:
Watter kleur is die lug?
Vrae wat mense ongemaklik maak wanneer 'n sekuriteitsvraag gebruik word om te identifiseer mense (byvoorbeeld in 'n oproepsentrum):
By wie het ek Kersfees geslaap?
Of eerlikwaar dom vrae:
Hoe spel jy "wagwoord"?
Wanneer dit by sekuriteitsvrae kom, moet gebruikers van hulself gered word! Met ander woorde, die sekuriteitsvraag moet deur die webwerf self bepaal word, of nog beter, gevra word reeks sekuriteitsvrae waaruit die gebruiker kan kies. En dit is nie maklik om te kies nie 1; ideaal gesproke moet die gebruiker twee of meer sekuriteitsvrae kies ten tyde van rekeningregistrasie, wat dan as 'n tweede identifikasiekanaal gebruik sal word. Om veelvuldige vrae te hê, verhoog vertroue in die verifikasieproses, en bied ook die vermoë om ewekansigheid by te voeg (wat nie altyd dieselfde vraag wys nie), plus bied 'n bietjie oortolligheid ingeval die werklike gebruiker die wagwoord vergeet het.
Wat is 'n goeie sekuriteitsvraag? Dit word deur verskeie faktore beïnvloed:
- Dit moet wees kort — die vraag moet duidelik en ondubbelsinnig wees.
- Die antwoord moet wees spesifiek - ons het nie 'n vraag nodig wat een persoon anders kan beantwoord nie
- Moontlike antwoorde moet wees uiteenlopend - om iemand se gunsteling kleur te vra, lewer 'n baie klein subset van moontlike antwoorde op
- soek die antwoord moet kompleks wees - as die antwoord maklik gevind kan word enige (onthou mense in hoë posisies), dan is hy sleg
- Die antwoord moet wees permanente betyds - as jy iemand se gunsteling fliek vra, dan kan die antwoord 'n jaar later anders wees
Soos dit gebeur, is daar 'n webwerf wat toegewy is om goeie vrae te vra . Sommige van die vrae lyk redelik goed, ander slaag nie sommige van die toetse wat hierbo beskryf is nie, veral die "gemak van soek"-toets.
Laat ek demonstreer hoe PayPal sekuriteitsvrae implementeer en veral die moeite wat die webwerf aan verifikasie doen. Hierbo het ons die bladsy gesien om die proses te begin (met 'n CAPTCHA), en hier sal ons wys wat gebeur nadat jy jou e-posadres ingevoer het en die CAPTCHA opgelos het:
Gevolglik ontvang die gebruiker die volgende brief:
Tot dusver is alles redelik normaal, maar hier is wat agter hierdie herstel-URL versteek is:
Dus, sekuriteitsvrae kom ter sprake. Trouens, PayPal laat jou ook toe om jou wagwoord terug te stel deur jou kredietkaartnommer te verifieer, so daar is 'n bykomende kanaal waartoe baie werwe nie toegang het nie. Ek kan net nie my wagwoord verander sonder om te antwoord nie albei sekuriteitsvraag (of nie die kaartnommer ken nie). Selfs as iemand my e-pos gekaap het, sou hulle nie my PayPal-rekeningwagwoord kon terugstel nie, tensy hulle 'n bietjie meer persoonlike inligting oor my geweet het. Watter inligting? Hier is die sekuriteitsvraagopsies wat PayPal bied:
Die skool- en hospitaalvraag is dalk 'n bietjie onduidelik in terme van maklike soektog, maar die ander is nie te sleg nie. Om sekuriteit te verbeter, vereis PayPal egter bykomende identifikasie vir veranderinge antwoorde op sekuriteitsvrae:
PayPal is 'n redelik utopiese voorbeeld van veilige wagwoordterugstellings: dit implementeer 'n CAPTCHA om die gevaar van brute-force-aanvalle te verminder, vereis twee sekuriteitsvrae, en vereis dan 'n ander soort heeltemal ander identifikasie net om die antwoorde te verander - en dit na die gebruiker het reeds aangemeld. Dit is natuurlik presies wat ons verwag van PayPal; is 'n finansiële instelling wat met groot bedrae geld handel. Dit beteken nie dat elke wagwoordterugstelling hierdie stappe moet volg nie—meestal is dit oormatig—maar dit is 'n goeie voorbeeld vir gevalle waar sekuriteit ernstige sake is.
Die gerief van die sekuriteitsvraagstelsel is dat as jy dit nie dadelik geïmplementeer het nie, jy dit later kan byvoeg as die vlak van hulpbronbeskerming dit vereis. ’n Goeie voorbeeld hiervan is Apple, wat hierdie meganisme eers onlangs geïmplementeer het [artikel geskryf in 2012]. Sodra ek die toepassing op my iPad begin opdateer het, het ek die volgende versoek gesien:
Toe sien ek 'n skerm waar ek verskeie pare sekuriteitsvrae en -antwoorde kan kies, sowel as 'n reddings-e-posadres:
Wat PayPal betref, is die vrae vooraf gekies en sommige van hulle is eintlik redelik goed:
Elk van die drie vraag/antwoord-pare verteenwoordig 'n ander stel moontlike vrae, so daar is baie maniere om 'n rekening op te stel.
Nog 'n aspek wat u moet oorweeg om u sekuriteitsvraag te beantwoord, is berging. Om 'n gewone teks databasis in die databasis te hê hou amper dieselfde bedreigings in as 'n wagwoord, naamlik dat die blootlegging van die databasis onmiddellik die waarde openbaar en nie net die toepassing in gevaar stel nie, maar moontlik heeltemal verskillende toepassings wat dieselfde sekuriteitsvrae gebruik (daar weer ). Een opsie is veilige hashing ('n sterk algoritme en 'n kriptografies ewekansige sout), maar anders as die meeste wagwoordbergingsgevalle, kan daar 'n goeie rede wees waarom die reaksie as gewone teks sigbaar is. 'n Tipiese scenario is identiteitsverifikasie deur 'n lewendige telefoonoperateur. Natuurlik is hashing ook van toepassing in hierdie geval (die operateur kan eenvoudig die antwoord invoer wat deur die kliënt genoem word), maar in die ergste geval moet die geheime reaksie op 'n sekere vlak van kriptografiese berging geleë wees, selfs al is dit net simmetriese enkripsie . Som op: behandel geheime soos geheime!
Een laaste aspek van veiligheidsvrae en -antwoorde is dat hulle meer kwesbaar is vir sosiale ingenieurswese. Om die wagwoord direk na iemand anders se rekening te probeer onttrek is een ding, maar om 'n gesprek oor die vorming daarvan te begin ('n gewilde sekuriteitsvraag) is heeltemal anders. Trouens, jy kan baie goed met iemand kommunikeer oor baie aspekte van hul lewe wat 'n geheime vraag kan stel sonder om agterdog te wek. Natuurlik is die punt van 'n sekuriteitsvraag dat dit verband hou met iemand se lewenservaring, so dit is onvergeetlik, en dit is waar die probleem lê - mense hou daarvan om oor hul lewenservarings te praat! Daar is min wat jy hieraan kan doen, net as jy sulke sekuriteitsvraagopsies kies sodat hulle is minder kan waarskynlik deur sosiale ingenieurswese uitgetrek word.
[Vervolg.]Oor die regte van reklame
VDSina bied betroubaar , is elke bediener gekoppel aan 'n internetkanaal van 500 Megabits en word gratis teen DDoS-aanvalle beskerm!
Bron: will.com