Mi lastatempe havis tempon por pensi denove pri kiel sekura pasvorta restarigo funkcio devus funkcii, unue kiam mi konstruis ĉi tiun funkcion en , kaj tiam kiam li helpis alian homon fari ion similan. En la dua kazo, mi volis doni al li ligilon al kanona rimedo kun ĉiuj detaloj pri kiel sekure efektivigi la restarigi funkcion. Tamen la problemo estas, ke tia rimedo ne ekzistas, almenaŭ ne unu, kiu priskribas ĉion, kio ŝajnas al mi grava. Do mi decidis skribi ĝin mem.
Vi vidas, la mondo de forgesitaj pasvortoj estas fakte sufiĉe mistera. Estas multaj diversaj, tute akcepteblaj vidpunktoj kaj multaj sufiĉe danĝeraj. Eble vi renkontis ĉiun el ili multajn fojojn kiel finuzanto; do mi provos uzi ĉi tiujn ekzemplojn por montri kiu faras ĝin ĝuste, kiu ne faras, kaj pri kio vi devas koncentriĝi por akiri la funkcion ĝuste en via programo.
Stokado de pasvortoj: hashing, ĉifrado kaj (spire!) simpla teksto
Ni ne povas diskuti kion fari kun forgesitaj pasvortoj antaŭ ol ni diskutas kiel konservi ilin. Pasvortoj estas konservitaj en la datumbazo en unu el tri ĉefaj tipoj:
- Simpla teksto. Estas pasvorta kolumno, kiu estas konservita en simpla teksto.
- Ĉifrita. Tipe uzante simetrian ĉifradon (unu ŝlosilo estas uzata por kaj ĉifrado kaj malĉifrado), kaj la ĉifritaj pasvortoj ankaŭ estas konservitaj en la sama kolono.
- Haŝita. Unudirekta procezo (pasvorto povas esti haŝita, sed ne povas esti haŝita); Pasvorto, Mi ŝatus esperi, sekvata de salo, kaj ĉiu estas en sia kolumno.
Ni iru rekte al la plej simpla demando: Neniam stoku pasvortojn en simpla teksto! Neniam. Unu sola vundebleco al , unu senzorga sekurkopio, aŭ unu el dekoj da aliaj simplaj eraroj - kaj jen, gameover, ĉiuj viaj pasvortoj - tio estas, pardonu, pasvortoj de ĉiuj viaj klientoj fariĝos publika havaĵo. Kompreneble, ĉi tio signifus grandegan verŝajnecon de ĉiuj iliaj kontoj en aliaj sistemoj. Kaj estos via kulpo.
Ĉifrado estas pli bona, sed havas siajn malfortojn. La problemo kun ĉifrado estas malĉifrado; ni povas preni ĉi tiujn frenezajn ĉifrojn kaj konverti ilin reen al simpla teksto, kaj kiam tio okazas, ni revenas al la homlegebla pasvorta situacio. Kiel tio okazas? Malgranda difekto eniras la kodon, kiu malĉifras la pasvorton, farante ĝin publike havebla - ĉi tio estas unu maniero. Hackers akiras aliron al la maŝino sur kiu ĉifritaj datumoj estas stokitaj - ĉi tiu estas la dua metodo. Alia maniero, denove, estas ŝteli la datumbazan sekurkopion kaj iu ankaŭ ricevas la ĉifradan ŝlosilon, kiu ofte estas tre nesekure konservita.
Kaj ĉi tio alportas nin al hashing. La ideo malantaŭ haĉado estas, ke ĝi estas unudirekta; la nura maniero por kompari la uzantan pasvorton kun ĝia haŝita versio estas haŝi la enigaĵon kaj kompari ilin. Por malhelpi atakojn de iloj kiel ĉielarkaj tabloj, ni salas la procezon kun hazardo (legu mian pri kriptografa stokado). Finfine, se efektivigite ĝuste, ni povas esti certaj, ke haŝitaj pasvortoj neniam plu fariĝos simpla teksto (mi parolos pri la avantaĝoj de malsamaj haŝalgoritmoj en alia afiŝo).
Rapida argumento pri hakado kontraŭ ĉifrado: la nura kialo vi iam bezonus ĉifri prefere ol haŝigi pasvorton estas kiam vi devas vidi la pasvorton en simpla teksto, kaj vi neniam dezirus ĉi tion, almenaŭ en norma retejo-situacio. Se vi bezonas ĉi tion, tiam plej verŝajne vi faras ion malbone!
Singardemo
Malsupre en la teksto de la afiŝo estas parto de ekrankopio de la pornografia retejo AlotPorn. Ĝi estas bonorde tajlita do estas nenio, kion vi ne povas vidi sur la strando, sed se ĝi ankoraŭ verŝajne kaŭzos problemojn, ne rulumu malsupren.
Ĉiam restarigi vian pasvorton neniam ne memorigu lin
Ĉu vi iam petis krei funkcion memorigiloj Pasvorto? Faru paŝon malantaŭen kaj pensu pri ĉi tiu peto inverse: kial ĉi tiu "rememorigilo" bezonas? Ĉar la uzanto forgesis la pasvorton. Kion ni vere volas fari? Helpu lin ensaluti denove.
Mi rimarkas, ke la vorto "rememorigilo" estas uzata (ofte) en parollingva signifo, sed kion ni vere provas fari estas sekure helpu la uzanton esti enreta denove. Ĉar ni bezonas sekurecon, estas du kialoj kial memorigilo (t.e. sendi al la uzanto sian pasvorton) ne taŭgas:
- Retpoŝto estas nesekura kanalo. Same kiel ni ne sendus ion senteman per HTTP (ni uzus HTTPS), ni ne sendus ion senteblan per retpoŝto ĉar ĝia transporta tavolo estas nesekura. Fakte, tio estas multe pli malbona ol simple sendado de informoj per nesekura transportprotokolo, ĉar poŝto estas ofte konservita sur stoka aparato, alirebla por sistemadministrantoj, plusendita kaj distribuata, alirebla al malware, ktp. Neĉifrita retpoŝto estas ekstreme nesekura kanalo.
- Vi tamen ne havu aliron al la pasvorto. Relegu la antaŭan sekcion pri konservado - vi havu hash de la pasvorto (kun bona forta salo), tio signifas, ke vi neniel povu ĉerpi la pasvorton kaj sendi ĝin per poŝto.
Mi montru la problemon per ekzemplo : Jen tipa ensalutpaĝo:
Evidente, la unua problemo estas, ke la ensaluta paĝo ne ŝargiĝas per HTTPS, sed la retejo ankaŭ petas vin sendi pasvorton ("Sendu Pasvorton"). Ĉi tio povas esti ekzemplo de la parollingva uzo de la termino menciita supre, do ni faru ĝin iom pli kaj vidu kio okazas:
Ĝi ne aspektas multe pli bone, bedaŭrinde; kaj retpoŝto konfirmas ke estas problemo:
Ĉi tio rakontas al ni du gravajn aspektojn de usoutdoor.com:
- La retejo ne haŝigas pasvortojn. En la plej bona kazo, ili estas ĉifritaj, sed verŝajne ili estas konservitaj en simpla teksto; Ni vidas neniun pruvon kontraŭe.
- La retejo sendas longdaŭran pasvorton (ni povas reiri kaj uzi ĝin denove kaj denove) per nesekurigita kanalo.
Kun ĉi tio ekster la vojo, ni devas kontroli ĉu la rekomencigita procezo estas farita en sekura maniero. La unua paŝo por fari tion estas certigi, ke la petanto havas la rajton fari la restarigi. Alivorte, antaŭ tio ni bezonas identeckontrolon; ni rigardu kio okazas kiam identeco estas kontrolita sen unue kontroli ke la petanto estas efektive la kontoposedanto.
Listo de uzantnomoj kaj ĝia efiko al anonimeco
Ĉi tiu problemo estas plej bone ilustrita vide. Problemo:
Ĉu vi vidas? Atentu la mesaĝon "Ne estas uzanto registrita kun ĉi tiu retadreso." La problemo evidente ekestas, se tia retejo konfirmas disponibilidad uzanto registrita kun tia retadreso. Bingo - vi ĵus malkovris la pornfetiĉon de via edzo/estro/najbaro!
Kompreneble, porno estas sufiĉe ikoneca ekzemplo de la graveco de privateco, sed la danĝeroj de asocii identecon kun specifa retejo estas multe pli larĝaj ol la eble mallerta situacio priskribita supre. Unu danĝero estas socia inĝenierado; Se la atakanto povas kongrui homon kun la servo, tiam li havos informojn, kiujn li povas komenci uzi. Ekzemple, li povas kontakti personon pozanta kiel reprezentanto de retejo kaj peti pliajn informojn en provo fari .
Tiaj praktikoj ankaŭ levas la danĝeron de "uzantnomnumero", per kio oni povas kontroli la ekziston de tuta kolekto de uzantnomoj aŭ retpoŝtadresoj en retejo simple farante grupdemandojn kaj ekzamenante la respondojn al ili. Ĉu vi havas liston de retadresoj de ĉiuj dungitoj kaj kelkajn minutojn por skribi skripton? Tiam vi vidas, kio estas la problemo!
Kio estas la alternativo? Fakte, ĝi estas sufiĉe simpla, kaj estas mirinde efektivigita en :
Ĉi tie Entropay malkaŝas absolute nenion pri la ekzisto de retadreso en sia sistemo al iu, kiu ne posedas ĉi tiun adreson... Se vi propra ĉi tiu adreso kaj ĝi ne ekzistas en la sistemo, tiam vi ricevos retmesaĝon kiel ĉi:
Kompreneble, povas esti akcepteblaj situacioj en kiuj iu pensaske vi registris en la retejo. sed ĉi tio ne estas la kazo, aŭ mi faris ĝin de alia retadreso. La ekzemplo montrita supre bone pritraktas ambaŭ situaciojn. Evidente, se la adreso kongruas, vi ricevos retpoŝton faciligante rekomencigi vian pasvorton.
La subtileco de la solvo elektita de Entropay estas, ke identiga konfirmo estas farita laŭ retpoŝto antaŭ ajna interreta konfirmo. Iuj retejoj petas uzantojn pri la respondo al sekureca demando (pli pri tio ĉi sube) por kiel la reset povas komenci; tamen, la problemo kun ĉi tio estas, ke vi devas respondi la demandon dum vi havigas iun formon de identigo (retpoŝto aŭ uzantnomo), kio poste faras preskaŭ neeble respondi intuicie sen malkaŝi la ekziston de la konto de la anonima uzanto.
Kun ĉi tiu alproksimiĝo ekzistas malgranda malpliigita uzebleco ĉar se vi provas restarigi neekzistantan konton, ne estas tuja rimarko. Kompreneble, tio estas la tuta celo sendi retmesaĝon, sed el la perspektivo de vera finuzanto, se ili enmetas la malĝustan adreson, ili nur scios por la unua fojo kiam ili ricevos la retpoŝton. Ĉi tio povas kaŭzi iom da streĉiĝo liaflanke, sed ĉi tio estas malgranda prezo por pagi por tia malofta procezo.
Alia noto, iomete ekstertema: ensaluthelpaj funkcioj, kiuj malkaŝas ĉu uzantnomo aŭ retpoŝtadreso estas ĝustaj, havas la saman problemon. Ĉiam respondu al la uzanto per mesaĝo "Vi uzantnomo kaj pasvorta kombinaĵo estas malvalida" prefere ol eksplicite konfirmi la ekziston de la akreditaĵoj (ekzemple, "la uzantnomo estas ĝusta, sed la pasvorto estas malĝusta").
Sendi rekomencigitan pasvorton kontraŭ sendado de rekomencigita URL
La sekva koncepto, kiun ni devas diskuti, estas kiel restarigi vian pasvorton. Estas du popularaj solvoj:
- Generante novan pasvorton en la servilo kaj sendi ĝin retpoŝte
- Sendu retpoŝton kun unika URL por faciligi la restarigin procezon
Malgraŭ , la unua punkto neniam estu uzata. La problemo kun ĉi tio estas, ke ĝi signifas ke ekzistas konservita pasvorto, kiun vi povas reveni kaj uzi denove iam ajn; ĝi estis sendita tra nesekura kanalo kaj restas en via enirkesto. Ŝajnas, ke enirkestoj estas sinkronigitaj tra porteblaj aparatoj kaj la retpoŝta kliento, krome ili povas esti konservitaj interrete en la retpoŝta servo dum tre longa tempo. La punkto estas tio leterkesto ne povas esti konsiderata kiel fidinda rimedo de longdaŭra konservado.
Sed krom tio, la unua punkto havas alian gravan problemon - ĝi simpligas kiel eble plej multe blokante konton kun malica intenco. Se mi konas la retpoŝtadreson de iu, kiu posedas konton en retejo, tiam mi povas bari ilin iam ajn simple restarigante ilian pasvorton; Ĉi tio estas nea servo-atako servita sur arĝenta plado! Tial la restarigo devas esti farita nur post sukcesa kontrolo de la rajtoj de la petanto pri ĝi.
Kiam ni parolas pri rekomencigita URL, ni signifas la adreson de retejo kiu estas unika al ĉi tiu aparta kazo de la rekomencigita procezo. Kompreneble, ĝi devus esti hazarda, ĝi ne devus esti facile diveni, kaj ĝi ne devus enhavi iujn ajn eksterajn ligilojn al la konto, kiuj faciligas ĝin restarigi. Ekzemple, la rekomencigita URL ne devus esti simple vojo kiel "Restarigi/?username=JohnSmith".
Ni volas krei unikan ĵetonon, kiu povas esti sendita kiel rekomencigita URL, kaj tiam kongrua kun la servila rekordo de la konto de la uzanto, tiel konfirmante ke la kontoposedanto estas, fakte, la sama persono kiu provas restarigi la pasvorton . Ekzemple, ĵetono povus esti "3ce7854015cd38c862cb9e14a1ae552b" kaj konservita en tabelo kune kun la ID de la uzanto faranta la rekomencigon kaj la tempo kiam la ĵetono estis generita (pli pri ĉi tio sube). Kiam la retpoŝto estas sendita, ĝi enhavas URL kiel "Restarigi/?id=3ce7854015cd38c862cb9e14a1ae552b", kaj kiam la uzanto elŝutas ĝin, la paĝo petas pri la ekzisto de la ĵetono, post kio ĝi konfirmas la informojn de la uzanto kaj permesas al ili ŝanĝi la retpoŝton. Pasvorto.
Kompreneble, ĉar la ĉi-supra procezo (espereble) permesas al la uzanto krei novan pasvorton, ni devas certigi, ke la URL estas ŝarĝita per HTTPS. Ne, , ĉi tiu signo URL devas uzi transporttavolan sekurecon por ke la nova pasvortformularo ne estu atakata kaj la uzant-kreita pasvorto estis transdonita per sekura konekto.
Ankaŭ por la rekomencigita URL vi devas aldoni ĵetonan templimon por ke la rekomencigita procezo povas esti kompletigita en certa intervalo, ekzemple ene de unu horo. Ĉi tio certigas, ke la rekomencigita tempofenestro estas minimuma tiel ke la ricevanto de la rekomencigita URL povas nur agi ene de tiu tre malgranda fenestro. Kompreneble, la atakanto povas komenci la restarigi procezon denove, sed ili devos akiri alian unikan restarigi URL.
Fine, ni devas certigi, ke ĉi tiu procezo estas forĵetebla. Post kiam la rekomencigita procezo estas kompleta, la ĵetono devas esti forigita tiel ke la rekomencigita URL ne plu funkcias. La antaŭa punkto estas necesa por certigi, ke la atakanto havas tre malgrandan fenestron, dum kiu li povas manipuli la rekomencigitan URL. Plie, kompreneble, post kiam la restarigo sukcesas, la ĵetono ne plu bezonas.
Kelkaj el ĉi tiuj paŝoj povas ŝajni tro superfluaj, sed ili ne malhelpas uzeblecon kaj fakte plibonigi sekurecon, kvankam en situacioj, kiujn ni esperas, estos maloftaj. En 99% de kazoj, la uzanto ebligos la rekomencigon en tre mallonga tempodaŭro kaj ne rekomencos la pasvorton en proksima estonteco.
Rolo de CAPTCHA
Ho, CAPTCHA, la sekureca funkcio, kiun ni ĉiuj amas malami! Fakte, CAPTCHA ne estas tiom protekta ilo, kiom ĝi estas identiga ilo - ĉu vi estas persono aŭ roboto (aŭ aŭtomatigita skripto). Ĝia celo estas eviti aŭtomatan sendon de formularo, kiu, kompreneble, povas estu uzata kiel provo rompi la sekurecon. En la kunteksto de pasvortigiloj, CAPTCHA signifas, ke la restarigo funkcio ne povas esti krude devigata aŭ spami la uzanton aŭ provi determini la ekziston de kontoj (kio, kompreneble, ne eblos se vi sekvas la konsilojn en la sekcio pri kontrolante identecojn).
Kompreneble, la CAPTCHA mem ne estas perfekta; Estas multaj precedencoj por ĝia programaro "hakado" kaj atingado de sufiĉaj sukcesprocentoj (60-70%). Aldone, estas solvo montrita en mia afiŝo pri , kie vi povas pagi homojn frakciojn de centono por solvi ĉiun CAPTCHA kaj atingi sukcesprocenton de 94%. Tio estas, ĝi estas vundebla, sed ĝi (iom) levas la baron al eniro.
Ni rigardu la ekzemplon de PayPal:
En ĉi tiu kazo, la rekomencigita procezo simple ne povas komenciĝi ĝis la CAPTCHA estas solvita, do teorie estas neeble aŭtomatigi la procezon. En teorio.
Tamen, por la plej multaj TTT-aplikoj ĉi tio estos troa kaj tute prave reprezentas malpliiĝon de uzebleco - homoj simple ne ŝatas CAPTCHA! Krome, CAPTCHA estas io, al kiu vi povas facile reveni se necese. Se la servo komencas ataki (ĉi tie utilas registrilo, sed pli pri tio poste), tiam aldoni CAPTCHA ne povus esti pli facila.
Sekretaj demandoj kaj respondoj
Kun ĉiuj metodoj, kiujn ni pripensis, ni povis restarigi la pasvorton nur havante aliron al la retpoŝta konto. Mi diras "nur", sed, kompreneble, estas kontraŭleĝe akiri aliron al la retpoŝta konto de iu alia. devus esti kompleksa procezo. Tamen .
Fakte, la supra ligo pri la hakado de Yahoo! de Sarah Palin! servas al du celoj; unue, ĝi ilustras kiom facile estas haki (kelkaj) retpoŝtajn kontojn, kaj due, ĝi montras kiom malbonaj sekurecaj demandoj povas esti uzataj kun malica intenco. Sed ni revenos al ĉi tio poste.
La problemo kun XNUMX% retpoŝt-bazitaj pasvortigoj estas, ke la integreco de la konto por la retejo, kiun vi provas restarigi, dependas XNUMX% de la integreco de la retpoŝta konto. Ĉiu, kiu havas aliron al via retpoŝto havas aliron al iu ajn konto, kiu povas esti rekomencigita simple ricevante retpoŝton. Por tiaj kontoj, retpoŝto estas la "ŝlosilo al ĉiuj pordoj" de via interreta vivo.
Unu maniero redukti ĉi tiun riskon estas efektivigi sekurecan demandon kaj respondan ŝablonon. Sendube vi jam vidis ilin: elektu demandon, kiun nur vi povas respondi devus sciu la respondon, kaj tiam kiam vi restarigos vian pasvorton, oni petos ĝin. Ĉi tio aldonas fidon, ke la persono provanta la rekomencigon estas ja la posedanto de la konto.
Reen al Sarah Palin: la eraro estis, ke la respondoj al ŝiaj sekurecaj demando/demandoj facile troveblas. Precipe kiam vi estas tiel signifa publika figuro, informoj pri la naksnomo de via patrino, eduka historio aŭ kie iu eble vivis en la pasinteco ne estas tute sekreto. Fakte, plejparto de ĝi povas esti trovita de preskaŭ ĉiu ajn. Jen kio okazis al Sara:
Hakisto David Kernell akiris aliron al la konto de Palin trovante detalojn pri ŝia fono, kiel ekzemple ŝia universitato kaj naskiĝdato, kaj tiam uzante la forgesitan pasvortan reakiran funkcion de Yahoo!.
Antaŭ ĉio, ĉi tio estas eraro de dezajno fare de Yahoo! — precizigante tiajn simplajn demandojn, la firmao esence sabotis la valoron de la sekureca demando, kaj tial la protekton de sia sistemo. Kompreneble, restarigi pasvortojn por retpoŝta konto estas ĉiam pli malfacila, ĉar vi ne povas pruvi posedon sendante retmesaĝon al la posedanto (sen havi duan adreson), sed feliĉe ne estas multaj uzoj por krei tian sistemon hodiaŭ.
Ni revenu al sekurecaj demandoj - ekzistas eblo por permesi al la uzanto krei siajn proprajn demandojn. La problemo estas, ke tio rezultigos terure evidentajn demandojn:
Kia koloro estas la ĉielo?
Demandoj kiuj malkomfortigas homojn kiam sekureca demando estas uzata por identigi persono (ekzemple, en telefoncentro):
Kun kiu mi dormis je Kristnasko?
Aŭ sincere stultaj demandoj:
Kiel vi literumas "pasvorton"?
Kiam temas pri sekurecaj demandoj, uzantoj devas esti savitaj de si mem! Alivorte, la sekureca demando devus esti determinita de la retejo mem, aŭ pli bone, demandita serio sekurecaj demandoj el kiuj la uzanto povas elekti. Kaj ne estas facile elekti один; ideale la uzanto elektu du aŭ pli da sekurecaj demandoj dum la registriĝo de konto, kiu tiam estos uzata kiel dua identiga kanalo. Havi plurajn demandojn pliigas fidon en la konfirmprocezo, kaj ankaŭ disponigas la kapablon aldoni hazardon (ne ĉiam montrante la saman demandon), krome provizas iom da redundo en kazo la reala uzanto forgesis la pasvorton.
Kio estas bona sekureca demando? Ĉi tio estas influita de pluraj faktoroj:
- Li devas esti mallonga — la demando devas esti klara kaj malambigua.
- La respondo devas esti specifa — ni ne bezonas demandon, kiun unu persono povas respondi malsame
- Eblaj respondoj devus esti diversa - demandi la plej ŝatatan koloron de iu donas tre malgrandan subaron de eblaj respondoj
- Поиск la respondo devas esti kompleksa - se la respondo estas facile trovebla iu ajn (memoru homojn en altaj postenoj), tiam li estas malbona
- La respondo devas esti konstanta ĝustatempe - se vi demandas la plej ŝatatan filmon de iu, tiam jaron poste la respondo povas esti malsama
Kiel okazas, ekzistas retejo dediĉita al demandi bonajn demandojn nomatan . Kelkaj el la demandoj ŝajnas sufiĉe bonaj, aliaj ne trapasas kelkajn el la provoj priskribitaj supre, precipe la "facilo de serĉo" testo.
Permesu al mi pruvi kiel PayPal efektivigas sekurecajn demandojn kaj, precipe, la penadon, kiun la retejo faras en aŭtentikigon. Supre ni vidis la paĝon por komenci la procezon (kun CAPTCHA), kaj ĉi tie ni montros kio okazas post kiam vi enigas vian retadreson kaj solvas la CAPTCHA:
Kiel rezulto, la uzanto ricevas la sekvan leteron:
Ĝis nun ĉio estas sufiĉe normala, sed jen kio estas kaŝita malantaŭ ĉi tiu rekomencigita URL:
Do, sekurecaj demandoj eniras. Fakte, PayPal ankaŭ permesas al vi restarigi vian pasvorton kontrolante vian kreditkartan numeron, do ekzistas plia kanalo, al kiu multaj retejoj ne havas aliron. Mi simple ne povas ŝanĝi mian pasvorton sen respondi ambaŭ sekureca demando (aŭ ne sciante la kartnumeron). Eĉ se iu forkaptus mian retpoŝton, ili ne povus restarigi mian pasvorton de PayPal-konto krom se ili scius iom pli da personaj informoj pri mi. Kiaj informoj? Jen la sekurecaj demandoj-opcioj kiujn ofertas PayPal:
La demando pri lernejo kaj hospitalo eble estas iom neklara rilate al facileco de serĉo, sed la aliaj ne estas tro malbonaj. Tamen, por plibonigi sekurecon, PayPal postulas plian identigon por ŝanĝi respondoj al sekurecaj demandoj:
PayPal estas sufiĉe utopia ekzemplo de sekuraj pasvortaj restarigo: ĝi efektivigas CAPTCHA por redukti la danĝeron de krudfortaj atakoj, postulas du sekurecajn demandojn, kaj poste postulas alian tute malsaman identigon nur por ŝanĝi la respondojn—kaj ĉi tio post la uzanto. jam ensalutis. Kompreneble, ĉi tio estas ĝuste tio, kion ni atendita de PayPal; estas financa institucio, kiu traktas grandajn monsumojn. Ĉi tio ne signifas, ke ĉiu pasvorta restarigo devas sekvi ĉi tiujn paŝojn—plej ofte ĝi estas troa—sed ĝi estas bona ekzemplo por kazoj kie sekureco estas serioza komerco.
La oportuno de la sekureca demandosistemo estas, ke se vi ne tuj efektivigis ĝin, vi povas aldoni ĝin poste se la nivelo de resursa protekto postulas ĝin. Bona ekzemplo de tio estas Apple, kiu nur lastatempe efektivigis ĉi tiun mekanismon [artikolo skribita en 2012]. Post kiam mi komencis ĝisdatigi la aplikaĵon sur mia iPad, mi vidis la jenan peton:
Tiam mi vidis ekranon kie mi povis elekti plurajn parojn da sekurecaj demandoj kaj respondoj, kaj ankaŭ savan retadreson:
Koncerne PayPal, la demandoj estas antaŭelektitaj kaj kelkaj el ili estas vere sufiĉe bonaj:
Ĉiu el la tri demandoj/respondaj paroj reprezentas malsaman aron de eblaj demandoj, do ekzistas multaj manieroj agordi konton.
Alia aspekto por konsideri pri respondado de via sekureca demando estas stokado. Havi klartekstan datumbazon en la datumbazo prezentas preskaŭ la samajn minacojn kiel pasvorton, nome ke elmontri la datumbazon tuj malkaŝas la valoron kaj riskas ne nur la aplikaĵon, sed eble tute malsamajn aplikaĵojn uzante la samajn sekurecajn demandojn (tie denove. ). Unu opcio estas sekura haŝado (forta algoritmo kaj kriptografie hazarda salo), sed male al la plej multaj pasvortstokaj kazoj, povas esti bona kialo por ke la respondo estas videbla kiel simpla teksto. Tipa scenaro estas identeckonfirmo de viva telefonisto. Kompreneble, hashing ankaŭ aplikeblas en ĉi tiu kazo (la operatoro povas simple enigi la respondon nomitan de la kliento), sed en la plej malbona kazo, la sekreta respondo devas troviĝi je iu nivelo de ĉifrika stokado, eĉ se ĝi estas nur simetria ĉifrado. . Resumu: traktu sekretojn kiel sekretojn!
Unu fina aspekto de sekurecaj demandoj kaj respondoj estas, ke ili estas pli vundeblaj al socia inĝenierado. Provi rekte ĉerpi la pasvorton al la konto de iu alia estas unu afero, sed komenci konversacion pri ĝia formado (populara sekureca demando) estas tute alia. Fakte, vi povas tre bone komuniki kun iu pri multaj aspektoj de sia vivo, kiuj povus starigi sekretan demandon sen veki suspekton. Kompreneble, la celo mem de sekureca demando estas, ke ĝi rilatas al ies vivsperto, do ĝi estas memorinda, kaj tie kuŝas la problemo - homoj amas paroli pri siaj vivspertoj! Estas malmulto, kion vi povas fari pri tio, nur se vi elektas tiajn sekurecajn demandojn por ke ili estu malpli verŝajne povus esti eltirita per socia inĝenierado.
[Daŭrigota.]Pri la Rajtoj de Reklamado
VDSina proponas fidindajn , ĉiu servilo estas konektita al interreta kanalo de 500 Megabitoj kaj estas protektita kontraŭ DDoS-atakoj senpage!
fonto: www.habr.com