Duela gutxi pasahitza berrezartzeko eginbide seguru batek nola funtzionatu behar zuen berriro pentsatzeko denbora izan nuen, lehenengo funtzionalitate hau eraikitzen ari nintzenean. , eta gero beste pertsona bati antzeko zerbait egiten lagundu zionean. Bigarren kasuan, baliabide kanonikorako esteka bat eman nahi nion berrezartzeko funtzioaren ezarpen seguruaren xehetasun guztiekin. Hala ere, arazoa da horrelako baliabiderik ez dagoela, ez behintzat garrantzitsua iruditzen zaidan guztia deskribatzen duenik. Beraz, nik neuk idaztea erabaki nuen.
Ikusten duzu, ahaztutako pasahitzen mundua nahiko misteriotsua da. Ikuspegi ezberdin asko daude, guztiz onargarriak eta nahiko arriskutsuak. Litekeena da azken erabiltzaile gisa haietako bakoitza askotan topatu izana; beraz, adibide hauek erabiltzen saiatuko naiz nor ari den ongi egiten, nork ez, eta zertan zentratu behar duzun funtzioa zure aplikazioan ondo ateratzeko.
Pasahitzak biltegiratzea: hashing, enkriptatzea eta (gasp!) testu arrunta
Ezin dugu eztabaidatu ahaztutako pasahitzekin zer egin behar den nola gorde behar diren eztabaidatu aurretik. Pasahitzak datu-basean hiru mota nagusietako batean gordetzen dira:
- Testu sinplea. Pasahitz zutabe bat dago, testu arruntean gordetzen dena.
- Enkriptatutakoa. Normalean zifraketa simetrikoa erabiliz (gako bat erabiltzen da bai enkriptatzeko bai deszifratzeko), eta enkriptatutako pasahitzak ere zutabe berean gordetzen dira.
- Hashed. Norabide bakarreko prozesua (pasahitza hash egin daiteke, baina ezin da hash kendu); pasahitza, Espero nuke, gatz bat jarraian, eta bakoitza bere zutabean dago.
Goazen zuzenean galdera errazenera: Inoiz ez gorde pasahitzak testu arruntean! Inoiz ez. Zaurgarritasun bakarra , arduragabeko babeskopia bat edo beste dozenaka akats soiletako bat - eta kitto, gameover, zure pasahitz guztiak - hau da, barkatu, zure bezero guztien pasahitzak jabari publiko bihurtuko da. Noski, horrek probabilitate handia esan nahi luke beste sistemetan dituzten kontu guztietatik. Eta zure errua izango da.
Enkriptatzea hobea da, baina bere ahuleziak ditu. Zifratzearen arazoa deszifratzea da; itxura zoroko zifra hauek hartu eta testu arruntera bihur ditzakegu, eta hori gertatzen denean gizakiek irakur dezaketen pasahitz egoerara itzuliko gara. Nola gertatzen da hau? Pasahitza deszifratzen duen kodean akats txiki bat sartzen da, publikoki eskuragarri jarriz - hau modu bat da. Hackerrek enkriptatutako datuak gordetzen diren makinara sarbidea lortzen dute - hau da bigarren metodoa. Beste modu bat, berriro ere, datu-basearen babeskopia lapurtzea da eta norbaitek enkriptatze-gakoa ere lortzen du, askotan oso modu seguruan gordetzen dena.
Eta honek hashingera garamatza. Hashing atzean dagoen ideia norabide bakarrekoa dela da; erabiltzaileak sartutako pasahitza bere hash bertsioarekin alderatzeko modu bakarra sarrera hash eta horiek alderatzea da. Ortzadarraren mahaiak bezalako tresnen erasoak saihesteko, prozesua ausaz gazten dugu (irakurri nire biltegiratze kriptografikoari buruz). Azken finean, behar bezala inplementatzen bada, seguru pentsa dezakegu hashed pasahitzak ez direla berriro testu arrunta bihurtuko (hashing algoritmo ezberdinen onurak beste argitalpen batean eztabaidatuko ditut).
Argumentu azkar bat hashing-a eta enkriptatzeari buruz: pasahitza hash baino gehiago enkriptatu beharko zenukeen arrazoi bakarra pasahitza testu arruntean ikusi behar duzunean da, eta ez zenuke inoiz hau nahi, webgunearen egoera estandarrean behintzat. Hau behar baduzu, ziurrenik zerbait gaizki ari zara egiten!
Arreta!
Jarraian, mezuaren testuan AlotPorn webgune pornografikoaren pantaila-argazki baten zati bat dago. Ondo moztuta dago hondartzan ikusi ezin duzun ezer, baina oraindik arazoren bat sorrarazten badu, ez joan behera.
Berrezarri pasahitza beti inoiz ez ez gogorarazi
Inoiz eskatu al zaizu funtzio bat sortzeko abisuak pasahitza? Eman pauso bat atzera eta pentsatu alderantziz eskaera hau: zergatik behar da βgogoragarriβ hori? Erabiltzaileak pasahitza ahaztu duelako. Zer egin nahi dugu benetan? Lagundu berriro saioa hasten.
Konturatzen naiz "gogoragarri" hitza zentzu kolokialean erabiltzen dela (askotan), baina benetan egiten saiatzen ari garena da segurtasunez lagundu erabiltzaileari berriro linean egoten. Segurtasuna behar dugunez, bi arrazoi daude abisua (hau da, erabiltzaileari pasahitza bidaltzea) egokia ez izatearen arrazoi:
- Posta elektronikoa kanal ez segurua da. HTTP bidez sentikorra den ezer bidaliko ez genukeen bezala (HTTPS erabiliko genuke), ez genuke posta elektronikoz bidali behar bere garraio-geruza segurua ez delako. Izan ere, hori garraio-protokolo seguru baten bidez informazioa bidaltzea baino askoz okerragoa da, maiz posta biltegiratze-gailu batean gordetzen baita, sistema-administratzaileentzat eskuragarri, birbidaltzen eta banatuta, malwarearentzat eskuragarria, etab. Zifratu gabeko posta oso segurua ez den kanala da.
- Hala ere, ez zenuke pasahitzerako sarbidea izan behar. Berriro irakurri biltegiratzeari buruzko aurreko atala - pasahitzaren hash bat izan beharko zenuke (gatz indartsuarekin), hau da, ezingo zenuke pasahitza inola ere atera eta postaz bidali.
Arazoa adibide batekin frogatuko dut : Hona hemen ohiko saioa hasteko orri bat:
Jakina, lehen arazoa da saioa hasteko orria ez dela HTTPS bidez kargatzen, baina webguneak pasahitza bidaltzeko ere eskatzen dizu ("Bidali pasahitza"). Hau izan daiteke goian aipatutako terminoaren erabilera kolokialaren adibide bat, beraz, eman dezagun urrats bat gehiago eta ikus dezagun zer gertatzen den:
Ez du itxura askoz hobea, tamalez; eta mezu elektroniko batek arazo bat dagoela baieztatzen du:
Honek usooutdoor.com-en bi alderdi garrantzitsu adierazten dizkigu:
- Guneak ez ditu pasahitzak hashik egiten. Onenean, zifratuta daude, baina litekeena da testu arruntean gordetzea; Ez dugu kontrako frogarik ikusten.
- Guneak epe luzeko pasahitza bidaltzen du (atzera egin eta behin eta berriro erabil dezakegu) seguru gabeko kanal baten bidez.
Hori baztertuta, berrezartzeko prozesua modu seguruan egiten den egiaztatu behar dugu. Horretarako lehen urratsa eskatzaileak berrezartzeko eskubidea duela ziurtatzea da. Beste era batera esanda, honen aurretik identitate-kontrola behar dugu; ikus dezagun zer gertatzen den identitate bat egiaztatzen denean, eskatzailea benetan kontuaren jabea dela egiaztatu gabe.
Erabiltzaile-izenak zerrendatzea eta anonimotasunean duen eragina
Arazo hau hobeto ilustratzen da bisualki. Arazoa:
Ikusten duzu? Erreparatu mezuari "Ez dago erabiltzailerik erregistratu helbide elektroniko honekin". Arazoa, jakina, horrelako gune batek baieztatzen badu sortzen da erabilgarritasuna helbide elektroniko horrekin erregistratutako erabiltzailea. Bingoa - zure senarraren/nagusia/auzokidearen porno-fetitxea aurkitu berri duzu!
Jakina, pornoa pribatutasunaren garrantziaren adibide nahiko ikonikoa da, baina pertsona bat webgune zehatz batekin lotzeak dituen arriskuak goian deskribatutako egoera baldarra baino askoz ere zabalagoak dira. Arrisku bat ingeniaritza soziala da; Erasotzaileak pertsona bat zerbitzuarekin parekatzen badu, orduan erabiltzen has daitekeen informazioa izango du. Adibidez, webgune baten ordezkari gisa agertzen den pertsona batekin harremanetan jar daiteke eta informazio gehigarria eska dezake konpromisoa hartu nahian .
Praktika horiek "erabiltzaile-izenen zenbaketa" arriskua ere sortzen dute, eta, horren bidez, webgune batean erabiltzaile-izen edo helbide elektronikoen bilduma osoa dagoela egiazta daiteke talde-kontsultak eginez eta horien erantzunak aztertuz. Langile guztien helbide elektronikoen zerrenda eta gidoia idazteko minutu batzuk al dituzu? Orduan ikusten duzu zein den arazoa!
Zein da alternatiba? Izan ere, nahiko erraza da, eta bikain inplementatzen da :
Hemen Entropay-k ez du ezer azaltzen bere sisteman helbide elektroniko bat egoteari buruz helbide honen jabea ez den bati... Zuk bada propioa helbide hau eta sisteman ez dago, orduan honelako mezu elektroniko bat jasoko duzu:
Jakina, egoera onargarriak egon daitezke norbaitek pentsatzen duwebgunean erregistratu duzula. baina ez da horrela, edo beste helbide elektroniko batetik egin dut. Goian erakusten den adibideak ondo maneiatzen ditu bi egoerak. Jakina, helbidea bat badator, mezu elektroniko bat jasoko duzu zure pasahitza berrezartzea errazteko.
Entropay-k aukeratutako irtenbidearen sotiltasuna da identifikazio-egiaztapena arabera egiten dela e-mail lineako edozein egiaztapen egin aurretik. Gune batzuek erabiltzaileei segurtasun galdera bati erantzuna eskatzen diete (behean honi buruzko informazio gehiago) to nola hasi daitekeen berrezartzea; hala ere, honen arazoa galderari erantzun behar diozula identifikazio motaren bat emanez (posta elektronikoa edo erabiltzaile-izena), eta horrek ia ezinezkoa egiten du intuitiboki erantzutea erabiltzaile-kontu anonimo baten existentzia agerian utzi gabe.
Planteamendu honekin, hor txikia erabilgarritasuna murriztu da, existitzen ez den kontu bat berrezartzen saiatzen bazara, ez dagoelako berehalako iritzirik. Jakina, hori da mezu elektroniko bat bidaltzearen kontua, baina benetako azken erabiltzailearen ikuspegitik, helbide okerra sartzen badute, lehen aldiz jakingo dute mezu elektronikoa noiz jasotzen duten. Horrek nolabaiteko tentsioa sor dezake bere aldetik, baina prezio txikia da hain prozesu arraro batengatik ordaintzeko.
Beste ohar bat, apur bat gaitik kanpo: erabiltzaile-izena edo helbide elektronikoa zuzena den ala ez adierazten duten saioa hasteko laguntza-funtzioek arazo bera dute. Erantzun beti erabiltzaileari "Zuk erabiltzaile-izena eta pasahitza konbinazioa baliogabea da" mezu batekin, kredentzialak daudela esplizituki baieztatu beharrean (adibidez, "erabiltzaile-izena zuzena da, baina pasahitza okerra").
Berrezarri pasahitza bidaltzea vs berrezarri URLa bidaltzea
Aztertu behar dugun hurrengo kontzeptua zure pasahitza nola berrezarri da. Bi irtenbide ezagun daude:
- Zerbitzarian pasahitz berri bat sortzea eta posta elektronikoz bidaltzea
- Bidali mezu elektroniko bat URL esklusibo batekin berrezartzeko prozesua errazteko
Hala eta guztiz ere , lehen puntua ez da inoiz erabili behar. Honen arazoa badagoela esan nahi du gordetako pasahitza, edozein unetan itzuli eta berriro erabil dezakezuna; kanal ez seguru batetik bidali da eta zure sarrera-ontzian jarraitzen du. Sarrerako ontziak gailu mugikorrekin eta posta-bezeroarekin sinkronizatzeko aukera dago, eta, gainera, sarean oinarritutako posta-zerbitzu batean sarean eduki daitezke denbora luzez. Kontua hori da postontzi bat ezin da epe luzerako biltegiratzeko baliabide fidagarritzat hartu.
Baina honetaz gain, lehen paragrafoak beste arazo larri bat du - hura ahalik eta gehien errazten du asmo txarreko kontu bat blokeatzea. Webgune batean kontu bat duen norbaiten helbide elektronikoa ezagutzen badut, edonoiz blokea dezaket bere pasahitza berrezarri besterik gabe; Zilarrezko plater batean zerbitzatutako zerbitzu-ukazio-erasoa da! Horregatik, berrezarpena eskatzaileak horretarako dituen eskubideak ongi egiaztatu ondoren bakarrik egin behar da.
Berrezarri URLari buruz hitz egiten dugunean, webgunearen helbidea esan nahi dugu, hau da berrezartzeko prozesuaren kasu zehatz honetan bakarra. Noski, ausaz izan behar du, ez da erraza izan behar asmatzen eta ez du eduki behar berrezartzea errazten duen konturako kanpoko estekarik. Adibidez, berrezarri URLak ez luke "Berrezarri/?username=JohnSmith" bezalako bide bat izan behar.
Token esklusibo bat sortu nahi dugu, posta elektronikoz berrezartzeko URL gisa bidal daitekeena, eta gero erabiltzailearen kontuaren zerbitzariaren erregistroarekin bat etor daitekeena, horrela kontuaren jabea, hain zuzen ere, pasahitza berrezartzen saiatzen ari den pertsona bera dela baieztatuz. Esate baterako, token bat "3ce7854015cd38c862cb9e14a1ae552b" izan daiteke eta taula batean gordeta, berrezartzea egiten ari den erabiltzailearen IDarekin eta tokena sortu zen denborarekin batera (behean informazio gehiago). Mezua bidaltzen denean, "Berrezarri/?id=3ce7854015cd38c862cb9e14a1ae552b" bezalako URL bat dauka, eta erabiltzaileak deskargatzen duenean, orrialdeak tokenaren existentzia eskatzen du, ondoren erabiltzailearen informazioa berresten du eta aldatzeko aukera ematen dio. pasahitza.
Noski, goiko prozesuak (espero dugu) erabiltzaileari pasahitz berri bat sortzeko aukera ematen duenez, URLa HTTPS bidez kargatzen dela ziurtatu behar dugu. Ez, , tokena duen URL honek garraio-geruzaren segurtasuna erabili behar du, pasahitz berria sartzeko inprimakiari eraso egin ez diezaion eta erabiltzaileek sortutako pasahitza konexio seguru baten bidez transmititu zen.
Berrezarri URLrako ere token-denbora-muga bat gehitu behar duzu, berrezartzeko prozesua tarte jakin batean burutu ahal izateko, esate baterako, ordu batean. Honek berrezartzeko denbora-leihoa ahalik eta gutxien mantentzen dela ziurtatzen du, berrezartzeko URLaren hartzaileak leiho oso txiki horretan soilik jardun dezan. Jakina, erasotzaileak berrezartzeko prozesua berriro has dezake, baina beste berrezartze URL esklusibo bat lortu beharko du.
Azkenik, prozesu hau botatzekoa dela ziurtatu behar dugu. Berrezartzeko prozesua amaitutakoan, tokena kendu behar da, berrezartzeko URLa baliozkoa izan ez dadin. Aurreko puntua behar da, erasotzaileak leiho txiki bat izan dezan eta bertan berrezartzeko URLa manipulatu ahal izateko. Gainera, noski, berrezarri ondoren, tokena ez da beharrezkoa.
Urrats horietako batzuk sobera soberakoak dirudite, baina ez dute erabilgarritasuna oztopatzen eta Izan ere segurtasuna hobetzea, bakanak izatea espero dugun egoeretan bada ere. Kasuen %99an, erabiltzaileak denbora gutxian berrezartzea gaituko du eta ez du pasahitza berriro berrezarri etorkizun hurbilean.
CAPTCHAren eginkizuna
O, CAPTCHA, guztiok gorrotatzen dugun segurtasun funtzioa! Izan ere, CAPTCHA ez da hainbeste babes-tresna bat, identifikazio-tresna bat baizik, pertsona edo robot bat izan (edo script automatizatu bat). Bere helburua inprimakien bidalketa automatikoa saihestea da, eta, noski, ahal segurtasuna hausteko saiakera gisa erabili. Pasahitza berrezartzearen testuinguruan, CAPTCHAk esan nahi du berrezartzeko funtzioa ezin dela bortxatu behartu erabiltzaileari spam egitera edo kontuen existentzia zehazten saiatu (hori, noski, ez da posible izango ataleko aholkuak jarraituz gero. identitateak egiaztatzea).
Jakina, CAPTCHA bera ez da perfektua; Aurrekari asko daude bere softwarea "pirateatzea" eta arrakasta-tasa nahikoak lortzeko (%60-70). Gainera, nire mezuan agertzen den irtenbide bat dago , non CAPTCHA bakoitza ebazteko eta % 94ko arrakasta-tasa lortzeko ehuneko zatiak ordain ditzakezu. Hau da, zaurgarria da, baina (pixka bat) altxatzen du sartzeko langa.
Ikus dezagun PayPal adibidea:
Kasu honetan, berrezartzeko prozesua ezin da hasi CAPTCHA konpondu arte, beraz teorikoki ezinezkoa da prozesua automatizatzea. Teorian.
Hala ere, web aplikazio gehienentzat gehiegizkoa izango da eta guztiz zuzena Erabilgarritasunaren murrizketa adierazten du - jendeari ez zaio CAPTCHA gustatzen! Gainera, CAPTCHA behar izanez gero erraz itzuli dezakezun zerbait da. Zerbitzua erasotzen hasten bada (hori komenigarria da saioa egitea, baina geroago gehiago), CAPTCHA bat gehitzea ezin da errazagoa izan.
Galdera eta erantzun sekretuak
Kontuan hartu ditugun metodo guztiekin, pasahitza berrezarri ahal izan dugu posta elektronikoko konturako sarbidea izateagatik. βBesterikβ esaten dut, baina, noski, legez kanpokoa da beste norbaiten posta elektronikoko konturako sarbidea lortzea. muztioa prozesu konplexua izan. Hala ere .
Izan ere, Sarah Palinen Yahoo!-ren hacking-ari buruzko goiko esteka. bi helburu ditu; lehenik, posta elektronikoko kontuak (batzuk) hackeatzea zein erraza den erakusten du, eta, bigarrenik, segurtasun-galdera txarrak asmo maltzurrekin nola erabil daitezkeen erakusten du. Baina honetaz gero itzuliko gara.
% XNUMX posta elektronikoaren menpe dauden pasahitzak berrezartzearen arazoa da berrezartzen saiatzen ari zaren gunearen kontuaren osotasuna posta elektronikoko kontuaren osotasunaren % XNUMX mendekoa izatea. Zure posta elektronikorako sarbidea duen edonor mezu elektroniko bat jasoz berrezarri daitekeen edozein konturako sarbidea du. Horrelako kontuetarako, posta elektronikoa zure sareko bizitzako "ate guztien giltza" da.
Arrisku hori murrizteko modu bat segurtasun galdera eta erantzun eredu bat ezartzea da. Zalantzarik gabe, dagoeneko ikusi dituzu: aukeratu zuk bakarrik erantzun dezakezun galdera muztioa jakin erantzuna, eta gero pasahitza berrezartzen duzunean eskatuko zaizu. Horrek berrezartzen saiatzen den pertsona kontuaren jabea dela ziurtatzen du.
Itzuli Sarah Palinera: akatsa izan zen bere segurtasun galdera/galderen erantzunak erraz aurki zitezkeela. Batez ere pertsonaia publiko esanguratsua zarenean, zure amaren neska-izena, hezkuntza-historia edo iraganean norbait bizi izan zitekeenari buruzko informazioa ez da horren sekretua. Izan ere, gehiena ia edonork aurki dezake. Hauxe gertatu zitzaion Sarari:
David Kernell hackerrak Palinen konturako sarbidea lortu zuen bere jatorriari buruzko xehetasunak aurkituz, hala nola bere unibertsitatea eta jaiotze data, eta gero Yahoo!-ren ahaztutako pasahitza berreskuratzeko funtzioa erabiliz.
Lehenik eta behin, hau Yahoo!-ren diseinu akats bat da! β Galdera sinple horiek zehaztuz, konpainiak funtsean segurtasun galderaren balioa saboteatu zuen, eta, beraz, bere sistemaren babesa. Jakina, posta elektronikoko kontu baten pasahitzak berrezartzea beti da zailagoa, ezin baita jabeari jabeari mezu elektroniko bat bidaliz frogatu (bigarren helbiderik izan gabe), baina, zorionez, gaur egun ez dago erabilera askorik horrelako sistema bat sortzeko.
Itzul gaitezen segurtasun galderetara - erabiltzaileari bere galderak sortzeko aukera dago. Arazoa da emaitza ikaragarri ageriko galderak izango direla:
Zer kolorekoa da zerua?
Jendea deseroso jartzen duten galderak segurtasun galdera bat identifikatzeko erabiltzen denean jende (adibidez, dei zentro batean):
Norekin lo egin nuen Gabonetan?
Edo galdera ergelak:
Nola idazten da "pasahitza"?
Segurtasun galderei dagokienez, erabiltzaileak beren buruarengandik gorde behar dira! Beste era batera esanda, segurtasun galdera guneak berak zehaztu beharko luke, edo hobeto esanda, galdetu seriea erabiltzaileak aukera ditzakeen segurtasun galderak. Eta ez da erraza aukeratzea bat; Egokiena, erabiltzaileak segurtasun-galdera bi edo gehiago hautatu beharko lituzke kontua erregistratzeko unean, gero bigarren identifikazio kanal gisa erabiliko dena. Galdera anitz izateak egiaztapen-prozesuan konfiantza-maila handitzen du, baita ausazkotasuna ahalbidetzen du (ez beti galdera bera erakusten), eta erredundantzia pixka bat ematen du benetako erabiltzaileak pasahitza ahaztuz gero.
Zein da segurtasun galdera ona? Hainbat faktorek eragiten dute:
- Izan behar luke laburra β Galderak argia eta anbiguoa izan behar du.
- Erantzuna izan behar da espezifikoa β Ez dugu behar pertsona batek modu ezberdinean erantzun dezakeen galderarik
- Erantzun posibleek izan beharko lukete askotarikoa - Norbaiten kolore gogokoena galdetzeak erantzun posibleen azpimultzo oso txikia ematen du
- bilaketa erantzunak konplexua izan behar du - erantzuna erraz aurki badaiteke Edozein (pentsatu posizio altuan dagoen jendea), orduan txarra da
- Erantzuna izan behar da iraunkorra denborarekin - norbaiten film gogokoena galdetzen baduzu, urtebete geroago erantzuna desberdina izan daiteke
Gertatzen den bezala, galdera onak egiteko deitutako webgune bat dago . Galdera batzuk nahiko onak dirudite, beste batzuk ez dituzte goian deskribatutako proba batzuk gainditzen, batez ere "bilatzeko erraztasuna" proba.
Utzidazu frogatu PayPal-ek segurtasun-galderak nola ezartzen dituen eta, bereziki, guneak autentifikazioan egiten duen ahalegina. Goian prozesua hasteko orria ikusi dugu (CAPTCHA batekin), eta hemen zure helbide elektronikoa sartu eta CAPTCHA ebatzi ondoren gertatzen dena erakutsiko dizugu:
Ondorioz, erabiltzaileak gutun hau jasotzen du:
Orain arte dena nahiko normala da, baina hona hemen berrezarri URL honen atzean ezkutatzen dena:
Beraz, galdera sekretuak sartzen dira jokoan. Izan ere, PayPal-ek zure pasahitza berrezartzeko aukera ematen du kreditu-txartelaren zenbakia egiaztatuz, beraz, gune askok sarbidea ez duten kanal gehigarri bat dago. Ezin dut pasahitza aldatu erantzun gabe Biek segurtasun galdera (edo txartelaren zenbakia ez jakitea). Norbaitek nire posta elektronikoa bahituko balu ere, ezin izango luke nire PayPal kontuaren pasahitza berrezarri niri buruzko informazio pertsonal apur bat gehiago jakin ezean. Zein informazio? Hona hemen PayPal-ek eskaintzen dituen segurtasun galderen aukerak:
Eskola eta ospitaleko galdera apur bat zalantzazkoa izan daiteke bilatzeko erraztasunari dagokionez, baina besteak ez dira hain txarrak. Hala ere, segurtasuna hobetzeko, PayPal-ek identifikazio osagarria behar du aldaketak segurtasun galderei erantzunak:
PayPal pasahitz berrezartze seguruen adibide nahiko utopikoa da: CAPTCHA bat ezartzen du indar gordineko erasoen arriskua murrizteko, segurtasun-galdera bi eskatzen ditu eta, ondoren, beste identifikazio mota bat behar du erantzunak aldatzeko soilik, eta hau erabiltzailearen ondoren. dagoeneko hasi da saioa. Jakina, horixe da guk espero zen PayPal-etik; diru kopuru handiekin jorratzen duen finantza erakundea da. Horrek ez du esan nahi pasahitza berrezartze bakoitzak urrats hauek jarraitu behar dituenik βgehienetan gehiegizkoa daβ, baina adibide ona da segurtasuna negozio serioa den kasuetarako.
Segurtasun galderen sistemaren erosotasuna da berehala inplementatu ez baduzu, geroago gehi dezakezula baliabideen babes-mailak hala eskatzen badu. Horren adibide ona Apple da, duela gutxi mekanismo hau ezarri duena [2012an idatzitako artikulua]. Nire iPad-eko aplikazioa eguneratzen hasi nintzenean, eskaera hau ikusi nuen:
Ondoren, pantaila bat ikusi nuen, non segurtasun-galdera eta erantzun pare bat hauta nezakeen, baita erreskate helbide elektroniko bat ere:
PayPal-i dagokionez, galderak aurrez hautatuta daude eta horietako batzuk nahiko onak dira:
Hiru galdera/erantzun bikote bakoitzak galdera posibleen multzo ezberdina adierazten du, beraz, kontu bat konfiguratzeko modu asko daude.
Zure segurtasun galderari erantzuteko kontuan hartu beharreko beste alderdi bat biltegiratzea da. Datu-basean testu arrunteko datu-base bat edukitzeak pasahitz baten ia mehatxu berdinak dakartza, hots, datu-basea berehala agerian uzteak balioa agerian uzten duela eta aplikazioa arriskuan jartzen ez ezik, aplikazio potentzialki guztiz desberdinak segurtasun-galdera berdinak erabiliz (berriro ere hor). ). Aukera bat hashing segurua da (algoritmo sendoa eta kriptografikoki ausazko gatz bat), baina pasahitzak biltegiratzeko kasu gehienetan ez bezala, erantzuna testu arrunt gisa ikusgai izateko arrazoi on bat egon daiteke. Egoera tipiko bat zuzeneko telefono-operadore batek nortasuna egiaztatzea da. Jakina, hashinga ere aplikagarria da kasu honetan (operadoreak bezeroak izendatutako erantzuna besterik gabe sar dezake), baina kasurik txarrenean, erantzun sekretua biltegiratze kriptografikoaren maila batean kokatu behar da, enkriptazio simetrikoa besterik ez bada ere. . Laburbildu: tratatu sekretuak sekretuak bezala!
Segurtasun galderen eta erantzunen azken alderdi bat gizarte ingeniaritzarako zaurgarriagoak direla da. Pasahitza zuzenean beste norbaiten kontura ateratzen saiatzea gauza bat da, baina bere eraketari buruzko elkarrizketa bat hastea (segurtasun-galdera ezaguna) guztiz bestelakoa da. Izan ere, oso ondo komunika zaitezke norbaitekin galdera sekretu bat sor dezaketen bizitzako alderdi askori buruz, susmoak piztu gabe. Jakina, segurtasun-galderaren puntua da norbaiten bizitza-esperientziarekin lotuta dagoela, beraz gogoangarria da, eta hor dago arazoa - jendeari gustatzen zaio bere bizitzako esperientziei buruz hitz egitea! Gutxi egin dezakezu honi buruz, segurtasun galderen aukerak aukeratzen badituzu bakarrik gutxiago ziurrenik ingeniaritza sozialak atera lezake.
[Jarraituko du.]Publizitatearen Eskubideei buruz
VDSina fidagarriak eskaintzen ditu , zerbitzari bakoitza 500 Megabit-eko Interneteko kanal batera konektatuta dago eta DDoS erasoetatik doan babestuta dago!
Iturria: www.habr.com