Kamakailan ay nagkaroon ako ng oras upang isipin muli ang tungkol sa kung paano dapat gumana ang secure na tampok na pag-reset ng password, una noong binuo ko ang pagpapagana , at pagkatapos ay kapag tumulong siya sa paggawa ng isang bagay na katulad ng ibang tao. Sa pangalawang kaso, nais kong bigyan siya ng isang link sa isang canonical na mapagkukunan na may lahat ng mga detalye kung paano ligtas na ipatupad ang pag-reset ng function. Gayunpaman, ang problema ay ang gayong mapagkukunan ay hindi umiiral, hindi bababa sa isa na naglalarawan sa lahat ng bagay na tila mahalaga sa akin. Kaya nagpasya akong isulat ito sa aking sarili.
Kita mo, ang mundo ng mga nakalimutang password ay talagang misteryoso. Mayroong maraming iba't ibang, perpektong katanggap-tanggap na mga punto ng pananaw at maraming mga medyo mapanganib. Malamang na nakatagpo mo ang bawat isa sa kanila ng maraming beses bilang isang end user; kaya't susubukan kong gamitin ang mga halimbawang ito upang ipakita kung sino ang gumagawa nito nang tama at kung sino ang hindi, at kung ano ang kailangan mong pagtuunan ng pansin upang maayos na maipatupad ang isang tampok sa iyong aplikasyon.
Pag-imbak ng password: pag-hash, pag-encrypt at (hinga!) plain text
Hindi namin matalakay kung ano ang gagawin sa mga nakalimutang password bago namin talakayin kung paano iniimbak ang mga ito. Ang mga password ay nakaimbak sa database sa isa sa tatlong pangunahing uri:
- Simpleng text. May isang column na may password, na nakaimbak sa plain text.
- naka-encrypt. Karaniwang gumagamit ng simetriko na pag-encrypt (isang key ang ginagamit para sa parehong pag-encrypt at pag-decryption), at naka-imbak din ang mga naka-encrypt na password sa parehong column.
- Hashed. One-way na proseso (ang password ay maaaring i-hash ngunit hindi i-dehash); password, Gusto kong umasa, na sinusundan ng asin, at ang bawat isa ay nasa sarili nitong hanay.
Harapin natin kaagad ang pinakasimpleng tanong: Huwag kailanman mag-imbak ng mga password sa plain text! Hindi kailanman. Isang solong kahinaan , isang walang ingat na ginawang backup na kopya o isa sa dose-dosenang iba pang simpleng pagkakamali - at iyon na, gameover, lahat ng iyong password - iyon ay, paumanhin, mga password para sa lahat ng iyong kliyente magiging pampublikong pag-aari. Siyempre, ito ay mangangahulugan ng isang malaking posibilidad na mula sa lahat ng kanilang mga account sa iba pang mga system. At ito ang magiging kasalanan mo.
Ang pag-encrypt ay mas mahusay, ngunit may mga kahinaan nito. Ang problema ng encryption ay nasa decryption; maaari nating kunin ang mga nakakalokong mukhang cipher na ito at i-convert ang mga ito pabalik sa plain text, at kapag nangyari iyon, babalik tayo sa sitwasyon na may mga nababasang password. Paano ito nangyayari? Ang isang maliit na depekto ay nakukuha sa code na nagde-decrypt ng password, na ginagawa itong available sa publiko - ito ay isang paraan. Ang pag-access sa makina kung saan naka-imbak ang naka-encrypt na data ay nakuha ng mga hacker - ito ang pangalawang paraan. Ang isa pang paraan, muli, ay ang nakawin ang backup ng database, at may nakakakuha din ng encryption key, na kadalasang nakaimbak nang walang katiyakan.
At dinadala tayo nito sa pag-hash. Ang ideya sa likod ng pag-hash ay ginagawa ito sa isang paraan; ang tanging paraan upang ihambing ang password na ipinasok ng user sa hash na bersyon nito ay ang pag-hash ng password na inilagay at paghambingin ang mga ito. Upang maiwasan ang mga pag-atake gamit ang mga tool tulad ng rainbow table, gumagamit kami ng asin upang magdagdag ng randomness sa proseso (para sa buong larawan, basahin ang aking tungkol sa cryptographic storage). Sa huli, kung ipinatupad nang tama, maaari nating ipagpalagay na ang mga hash na password ay hindi na magiging plain text muli (tatalakayin ko ang mga benepisyo ng iba't ibang algorithm ng hashing sa isa pang post).
Mabilis na argumento tungkol sa pag-hash at pag-encrypt: Ang tanging dahilan na kakailanganin mong mag-encrypt sa halip na mag-hash ng password ay kapag kailangan mong makita ang password sa plain text sa halip na hindi mo dapat gusto ito, hindi bababa sa isang karaniwang sitwasyon ng website. Kung kailangan mo ito, malamang na may ginagawa kang mali!
Warning!
Ang isang maliit na ibaba sa teksto ng post ay bahagi ng isang screenshot ng pornograpikong website na AlotPorn. Ito ay maayos na na-crop, kaya walang hindi makikita sa beach, ngunit kung nagdudulot pa rin ito ng mga problema, pagkatapos ay huwag mag-scroll pababa sa pahina.
Palaging i-reset ang iyong password hindi kailanman huwag mo siyang ipaalala
Nahilingan ka na bang gumawa ng function mga paalala password? Bumalik ng isang hakbang at isipin ang kahilingang ito nang baligtad: bakit kailangan ang "paalala" na ito? Dahil nakalimutan ng user ang password. Ano ba talaga ang gusto nating gawin? Tulungan siyang mag-log in muli.
Naiintindihan ko na ang salitang "paalala" ay ginagamit (kadalasan) sa kolokyal, ngunit ang talagang sinusubukan naming gawin ay ligtas na tulungan ang gumagamit na maging online muli. Dahil kailangan namin ng seguridad, may dalawang dahilan kung bakit hindi naaangkop ang isang paalala (i.e. pagpapadala sa user ng kanilang password):
- Ang email ay isang hindi secure na channel. Kung paanong hindi kami magpapadala ng anumang kumpidensyal sa HTTP (ginagamit namin ang HTTPS), hindi kami dapat magpadala ng kahit ano sa email dahil hindi secure ang transport layer nito. Sa katunayan, ito ay mas masahol pa kaysa sa simpleng pagpapadala ng impormasyon sa isang hindi secure na transport protocol, dahil ang mail ay madalas na nakaimbak sa drive, magagamit sa mga administrator ng system, ipinapasa at ipinamamahagi, magagamit sa malware, at iba pa. Ang hindi naka-encrypt na mail ay isang lubhang hindi secure na channel.
- Hindi ka dapat magkaroon ng access sa password pa rin. Basahin muli ang nakaraang seksyon sa imbakan - dapat ay mayroon kang hash ng password (na may mahusay na malakas na asin), ibig sabihin ay walang paraan na dapat mong makuha ang password at ipadala ito sa koreo.
Hayaan akong ipakita ang problema sa isang halimbawa : Narito ang isang karaniwang pahina sa pag-log in:
Malinaw na ang unang problema ay ang pahina sa pag-login ay hindi naglo-load sa HTTPS, ngunit nag-aalok din ang site na magpadala ng password ("Ipadala ang Password"). Marahil ito ay isang halimbawa ng kolokyal na paggamit ng terminong binanggit sa itaas, kaya hayaan natin itong isang hakbang pa at tingnan kung ano ang mangyayari:
Hindi ito mukhang mas mahusay, sa kasamaang-palad; at kinukumpirma ng email na mayroong problema:
Sinasabi nito sa amin ang tungkol sa dalawang mahalagang aspeto ng usoutdoor.com:
- Ang site ay hindi nagha-hash ng mga password. Sa pinakamainam, naka-encrypt ang mga ito, ngunit malamang na nakaimbak ang mga ito sa plain text; Wala kaming nakikitang katibayan sa kabaligtaran.
- Nagpapadala ang site ng pangmatagalang password (maaari naming balikan at gamitin ito nang paulit-ulit) sa isang hindi secure na channel.
Sa labas ng paraan, kailangan nating suriin kung ang proseso ng pag-reset ay tumatakbo sa isang ligtas na paraan. Ang unang hakbang para gawin ito ay tiyaking may karapatan ang humihiling na isagawa ang pag-reset. Sa madaling salita, bago iyon kailangan natin ng pagsusuri ng pagkakakilanlan; Tingnan natin kung ano ang mangyayari kapag na-verify ang isang pagkakakilanlan nang hindi muna nabe-verify na ang humihiling ay talagang may-ari ng account.
Pagbilang ng mga username at ang epekto nito sa hindi pagkakilala
Ang problemang ito ay pinakamahusay na inilarawan nang biswal. Problema:
Nakikita mo ba? Bigyang-pansin ang mensaheng "Walang user na nakarehistro sa email address na ito". Ang problema ay malinaw na lumitaw kung kinukumpirma ng naturang site availability nakarehistro sa naturang e-mail address ng user. Bingo - ngayon mo lang natuklasan ang porn fetish ng iyong asawa/boss/kapitbahay!
Siyempre, ang porn ay isang medyo kanonikal na halimbawa ng kahalagahan ng privacy, ngunit ang mga panganib na maitugma sa isang partikular na website ay mas malaki kaysa sa potensyal na nakakahiyang sitwasyon na inilarawan sa itaas. Ang isang panganib ay social engineering; kung maitugma ng isang umaatake ang isang tao sa isang serbisyo, magkakaroon siya ng impormasyon na maaari niyang simulang gamitin. Halimbawa, maaari siyang makipag-ugnayan sa isang taong nagpapanggap bilang isang kinatawan ng isang website at humiling ng karagdagang impormasyon sa pagtatangkang gawin ito .
Ang ganitong mga kagawian ay nagpapataas din ng panganib ng "username enumeration", kung saan posibleng suriin ang pagkakaroon ng isang buong koleksyon ng mga username o email address sa isang website sa pamamagitan ng simpleng maramihang query at pagsusuri sa mga tugon sa mga ito. Mayroon ka bang listahan ng lahat ng mga email address ng empleyado at ilang minuto para magsulat ng script? Pagkatapos ay makikita mo kung ano ang problema!
Ano ang alternatibo? Sa katunayan, ito ay medyo simple, at kapansin-pansing ipinatupad sa :
Dito, ang Entropay ay ganap na nagbubunyag ng walang tungkol sa pagkakaroon ng isang email address sa system nito sa isang taong hindi nagmamay-ari ng address na ito... kung ikaw sariling address at wala ito sa system, makakatanggap ka ng email tulad nito:
Siyempre, may mga katanggap-tanggap na sitwasyon kung saan ang isang tao Iniisipna nakarehistro sa website. ngunit hindi ito ang kaso, o ginawa ito mula sa ibang mail address. Ang halimbawa sa itaas ay matagumpay na pinangangasiwaan ang parehong mga sitwasyon. Malinaw, kung tumugma ang address, makakatanggap ka ng email na nagpapadali sa pag-reset ng iyong password.
Ang subtlety ng solusyon na pinili ng Entropay ay ang pag-verify ng pagkakakilanlan ay ginagawa ng e-mail bago ang anumang online na pagsusuri. Ang ilang mga site ay humihingi sa mga user ng sagot sa isang katanungang panseguridad (higit pa dito sa ibaba) sa kung paano magsisimula ang pag-reset; gayunpaman, ang problema dito ay kailangan mong sagutin ang tanong habang nagbibigay ng ilang anyo ng pagkakakilanlan (email o username), na ginagawang halos imposible na sumagot nang intuitive nang hindi inilalantad ang pagkakaroon ng hindi kilalang user account.
Sa ganitong paraan, doon maliit pagbaba sa kakayahang magamit, dahil sa kaso ng isang pagtatangka na i-reset ang isang hindi umiiral na account, walang instant na feedback. Siyempre, ito ang buong punto ng pagpapadala ng isang email, ngunit mula sa punto ng view ng tunay na end user, kung siya ay nagpasok ng maling address, malalaman niya lamang ito sa unang pagkakataon kapag natanggap niya ang sulat. Ito ay maaaring magdulot ng kaunting tensyon sa kanyang bahagi, ngunit ito ay isang maliit na halaga na babayaran para sa gayong bihirang proseso.
Isa pang tala na medyo off-topic: Ang mga function ng tulong sa pag-login na nagpapakita ng tamang username o email address ay may parehong problema. Palaging tumugon sa user gamit ang mensaheng "Hindi wasto ang kumbinasyon ng username at password mo", sa halip na tahasang kumpirmahin ang pagkakaroon ng impormasyon ng pagkakakilanlan (halimbawa, "tama ang username, ngunit mali ang password").
Pagpapadala ng Reset Password vs Pagpapadala ng Reset URL
Ang susunod na konsepto na kailangan nating talakayin ay may kinalaman sa paraan ng pag-reset ng password. Mayroong dalawang tanyag na solusyon:
- Pagbuo ng bagong password sa server at pagpapadala nito sa pamamagitan ng email
- Pagpapadala ng email na may natatanging URL upang pasimplehin ang proseso ng pag-reset
Sa kabila ng , hindi dapat gamitin ang unang punto. Ang kanyang problema ay ang ibig sabihin nito ay pagkakaroon nakaimbak na password, kung saan maaari kang bumalik at gamitin muli anumang oras; ipinadala ito sa isang hindi secure na channel at nananatili sa iyong inbox. May pagkakataon na ang mga inbox ay naka-sync sa mga mobile device at email client, at maaari silang panatilihing online sa isang web based na serbisyo sa email sa napakatagal na panahon. Ang punto ay iyon ang mailbox ay hindi maaaring ituring bilang isang maaasahang paraan para sa pangmatagalang imbakan.
Ngunit bukod dito, ang unang talata ay may isa pang malubhang problema - ito pinapasimple hangga't maaari pag-block ng account na may malisyosong layunin. Kung alam ko ang email address ng isang taong nagmamay-ari ng isang account sa isang website, maaari ko siyang i-block anumang oras sa pamamagitan lamang ng pag-reset ng kanyang password; ito ay isang denial of service attack sa isang pilak na pinggan! Iyon ang dahilan kung bakit ang pag-reset ay dapat gawin lamang pagkatapos ng matagumpay na pagsusuri sa humihiling ng mga karapatan dito.
Kapag pinag-uusapan natin ang pag-reset ng URL, ang ibig nating sabihin ay ang address ng website, na natatangi sa partikular na kaso ng proseso ng pag-reset. Siyempre, dapat itong random, hindi ito dapat madaling hulaan, at hindi ito dapat maglaman ng anumang mga panlabas na sanggunian sa account na nagpapadali sa pag-reset. Halimbawa, ang pag-reset ng URL ay hindi dapat isang path lang tulad ng "I-reset/?username=JohnSmith."
Nais naming lumikha ng isang natatanging token na maaaring ipadala sa koreo bilang isang pag-reset ng URL at pagkatapos ay itugma sa talaan ng server ng user account, sa gayon ay mapapatunayan na ang may-ari ng account ay talagang ang parehong tao na sumusubok na i-reset ang password. . Halimbawa, ang isang token ay maaaring magmukhang "3ce7854015cd38c862cb9e14a1ae552b" at nakaimbak sa isang talahanayan kasama ang pag-reset ng user ID at ang oras ng pagbuo ng token (higit pa tungkol doon sa ilang sandali). Kapag ipinadala ang email, naglalaman ito ng URL tulad ng "I-reset/?id=3ce7854015cd38c862cb9e14a1ae552b", at kapag na-load ito ng user, hihilingin ng page ang pagkakaroon ng token, pagkatapos ay kinukumpirma ang impormasyon ng user at pinapayagan ang password na mabago.
Siyempre, dahil ang proseso sa itaas (sana) ay nagbibigay-daan sa user na lumikha ng bagong password, kailangan naming tiyakin na ang URL ay na-load sa HTTPS. Hindi, , ang URL na ito na may token ay dapat gumamit ng transport layer security upang hindi maatake ang bagong form ng pagpasok ng password at ang password na ginawa ng user ay ipinadala sa isang secure na koneksyon.
Gayundin, para sa pag-reset ng URL, kailangan mong magdagdag ng limitasyon sa oras ng token upang makumpleto ang proseso ng pag-reset sa loob ng isang partikular na agwat, halimbawa, sa loob ng isang oras. Tinitiyak nito na ang reset time window ay pinananatiling maikli hangga't maaari upang ang tatanggap ng reset URL na ito ay makakakilos lamang sa loob ng napakaliit na window na ito. Siyempre, maaaring simulan muli ng isang attacker ang proseso ng pag-reset, ngunit kakailanganin niyang kumuha ng isa pang natatanging reset URL.
Panghuli, kailangan nating tiyakin na ang prosesong ito ay disposable. Kapag nakumpleto na ang proseso ng pag-reset, dapat alisin ang token para hindi na valid ang reset URL. Ang nakaraang punto ay kailangan upang ang umaatake ay may napakaliit na window kung saan maaari niyang manipulahin ang pag-reset ng URL. Dagdag pa, siyempre, pagkatapos ng matagumpay na pagkumpleto ng pag-reset, hindi na kailangan ang token.
Ang ilan sa mga hakbang na ito ay maaaring mukhang kalabisan, ngunit hindi ito nakakasagabal sa kakayahang magamit at sa katunayan pagbutihin ang kaligtasan, kahit na sa mga sitwasyong inaasahan naming bihira. Sa 99% ng mga kaso, papaganahin ng user ang pag-reset sa loob ng napakaikling panahon at hindi na muling ire-reset ang password sa malapit na hinaharap.
Tungkulin ng CAPTCHA
Oh, CAPTCHA, ang panukalang panseguridad na gusto nating lahat na kinasusuklaman! Sa katunayan, ang CAPTCHA ay hindi isang paraan ng proteksyon bilang pagkakakilanlan - ikaw ay isang tao o isang robot (o isang awtomatikong script). Ang layunin nito ay upang maiwasan ang mga awtomatikong pagsusumite ng form, na, siyempre, maaari gamitin bilang isang pagtatangkang sirain ang proteksyon. Sa konteksto ng pag-reset ng mga password, ang CAPTCHA ay nangangahulugan na ang reset function ay hindi maaaring pilitin na i-spam ang user o subukang tukuyin ang pagkakaroon ng mga account (na, siyempre, ay hindi magiging posible kung sinunod mo ang mga tip sa seksyon sa pagpapatunay ng pagkakakilanlan).
Siyempre, ang CAPTCHA mismo ay hindi perpekto; maraming mga precedent para sa programmatically "hack" at makamit ang sapat na mga rate ng tagumpay (60-70%). Gayundin, mayroong isang solusyon na ipinakita sa aking post tungkol sa , kung saan maaari kang magbayad sa mga tao ng fraction ng isang sentimo upang malutas ang bawat CAPTCHA at makakuha ng 94% na rate ng tagumpay. Iyon ay, ito ay mahina, ngunit (bahagyang) itinataas ang hadlang sa pagpasok.
Tingnan natin ang isang halimbawa ng PayPal:
Sa kasong ito, ang proseso ng pag-reset ay hindi maaaring magsimula bago malutas ang CAPTCHA, kaya theoretically imposibleng i-automate ang proseso. Sa teorya.
Gayunpaman, para sa karamihan ng mga web application ito ay magiging labis at ganap na tama kumakatawan sa pagbaba sa kakayahang magamit - ayaw lang ng mga tao sa CAPTCHA! Bilang karagdagan, ang CAPTCHA ay isang bagay na madali mong mababalikan kung kinakailangan. Kung ang serbisyo ay nagsimulang atakehin (ang pag-log ay madaling gamitin dito, ngunit higit pa tungkol doon sa ibang pagkakataon), kung gayon ang pagdaragdag ng CAPTCHA ay hindi magiging mas madali.
Mga Lihim na Tanong at Sagot
Sa lahat ng mga pamamaraan na aming tiningnan, nagawa naming i-reset ang password, sa pamamagitan lamang ng pagkakaroon ng access sa email account. Sinasabi ko "lang", ngunit siyempre, ilegal na nakakakuha ng access sa mail account ng ibang tao dapat maging isang kumplikadong proseso. Gayunpaman .
Sa katunayan, ang link sa itaas tungkol sa Yahoo! ni Sarah Palin! nagsisilbi ng dalawang layunin; una, inilalarawan nito kung gaano kadali ang pag-hack ng (ilang) mga email account, at pangalawa, ipinapakita nito kung paano maaaring gamitin sa malisyoso ang masamang mga lihim na tanong. Ngunit babalikan natin ito mamaya.
Ang problema sa pag-reset ng mga password na XNUMX% nakadepende sa email ay ang integridad ng account ng site na sinusubukan mong i-reset ay nagiging XNUMX% na nakadepende sa integridad ng email account. Sinumang may access sa iyong email ay may access sa anumang account na maaaring i-reset sa pamamagitan lamang ng pagtanggap ng email. Para sa mga ganoong account, ang email ang "susi sa lahat ng pintuan" ng iyong online na buhay.
Ang isang paraan upang mapagaan ang panganib na ito ay ang pagpapatupad ng panseguridad na tanong at pattern ng sagot. Walang alinlangan na nakita mo na sila: pumili ng tanong na ikaw lang mayroon alam ang sagot, pagkatapos nito, kapag na-reset mo ang iyong password, tatanungin ka. Ito ay nagdaragdag sa kumpiyansa na ang taong sinusubukang i-reset ay siya nga ang may-ari ng account.
Bumalik kay Sarah Palin: ang pagkakamali ay ang mga sagot sa kanyang pangseguridad na tanong/tanong ay madaling mahanap. Lalo na kapag ikaw ay isang mahalagang pampublikong pigura, ang impormasyon tungkol sa pangalan ng pagkadalaga ng iyong ina, kasaysayan ng edukasyon, o kung saan maaaring tumira ang isang tao sa nakaraan ay hindi lahat ng sikreto. Sa katunayan, karamihan sa mga ito ay matatagpuan ng halos kahit sino. Ito ang nangyari kay Sarah:
Ang Hacker na si David Kernell ay nakakuha ng access sa account ni Palin sa pamamagitan ng paghahanap ng kanyang mga detalye sa background, tulad ng kanyang high school at petsa ng kapanganakan, at pagkatapos ay gamit ang nawalang account password recovery feature ng Yahoo!.
Una sa lahat, ito ay isang error sa disenyo sa bahagi ng Yahoo! - Sa pamamagitan ng pagtukoy sa mga simpleng tanong, ang kumpanya ay mahalagang sinabotahe ang halaga ng lihim na tanong, at samakatuwid ay ang proteksyon ng sistema nito. Siyempre, ang pag-reset ng mga password sa isang email account ay palaging mas nakakalito, dahil hindi mo mabe-verify ang pagmamay-ari nito sa pamamagitan ng pag-email sa may-ari (nang walang pangalawang address), ngunit sa kabutihang palad ay wala nang maraming gamit para sa naturang sistema ngayon.
Bumalik sa mga lihim na tanong - may opsyon na payagan ang user na gumawa ng sarili nilang mga tanong. Ang problema ay magreresulta ito sa mga napakalinaw na tanong:
Ano ang kulay ng langit?
Mga tanong na naglalagay sa mga tao sa isang hindi komportableng posisyon kapag ang isang tanong sa seguridad ay gumagamit ng isang lihim na tanong upang makilala tao (halimbawa, sa isang call center):
Sino ang kasama ko sa pagtulog noong Pasko?
O tapat na hangal na mga tanong:
Paano mo i-spell ang "password"?
Pagdating sa mga tanong sa seguridad, ang mga user ay kailangang i-save mula sa kanilang sarili! Sa madaling salita, ang tanong na panseguridad ay dapat matukoy ng mismong site, o mas mabuti pa, itanong serye mga tanong sa seguridad kung saan maaaring piliin ng user. At huwag lang pumili isa; pinakamainam na ang gumagamit ay dapat pumili ng dalawa o higit pang mga katanungan sa seguridad sa oras ng pagpaparehistro ng account, na pagkatapos ay gagamitin bilang pangalawang channel ng pagkakakilanlan. Ang pagkakaroon ng maraming tanong ay nagpapataas ng antas ng kumpiyansa sa proseso ng pag-verify, pati na rin ang pagpapahintulot para sa randomness (hindi palaging nagpapakita ng parehong tanong), at pagbibigay ng kaunting redundancy kung sakaling ang tunay na user ay nakalimutan ang password.
Ano ang magandang tanong sa seguridad? Ito ay naiimpluwensyahan ng ilang mga kadahilanan:
- Dapat siya ay maikli Ang tanong ay dapat na malinaw at hindi malabo.
- Dapat ang sagot tiyak β hindi natin kailangan ng tanong na masasagot ng isang tao sa iba't ibang paraan
- Ang mga posibleng sagot ay dapat iba-iba Ang pagtatanong ng paboritong kulay ng isang tao ay nagbibigay ng napakaliit na subset ng mga posibleng sagot.
- paghahanap ang sagot ay dapat na kumplikado - kung ang sagot ay madaling mahanap anumang (isipin ang mga taong nasa mataas na posisyon), tapos masama siya
- Dapat ang sagot permanenteng sa oras - kung tatanungin mo ang paboritong pelikula ng isang tao, pagkatapos ng isang taon ang sagot ay maaaring iba
Habang nangyayari ito, mayroong isang website na nakatuon sa magagandang tanong na tinatawag . Ang ilan sa mga tanong ay tila napakahusay, ang iba ay nabigo sa ilan sa mga pagsusulit na inilarawan sa itaas, lalo na ang "madaling hanapin" na pagsubok.
Hayaan akong ipakita sa iyo kung paano ipinapatupad ang mga tanong sa seguridad sa PayPal at, lalo na, kung gaano kalaki ang pagsisikap ng site sa pagkilala. Nakita namin ang panimulang pahina ng proseso (na may CAPTCHA) sa itaas, at dito ipinapakita namin kung ano ang mangyayari pagkatapos mong ilagay ang iyong email address at lutasin ang CAPTCHA:
Bilang resulta, natatanggap ng user ang sumusunod na email:
Sa ngayon ang lahat ay medyo normal, ngunit narito ang nakatago sa likod ng pag-reset ng URL na ito:
Kaya, pumapasok ang mga lihim na tanong. Sa katunayan, pinapayagan ka rin ng PayPal na i-reset ang iyong password sa pamamagitan ng pag-verify ng numero ng iyong credit card, kaya mayroong karagdagang channel na maraming mga site ay walang access. Hindi ko lang mapapalitan ang aking password nang hindi sumasagot pareho lihim na tanong (o hindi alam ang numero ng card). Kahit na may mang-hijack sa aking email, hindi nila mai-reset ang kanilang password sa PayPal account maliban na lang kung alam nila ang kaunti pang personal na impormasyon tungkol sa akin. Anong impormasyon? Narito ang mga opsyon para sa mga tanong sa seguridad na inaalok ng PayPal:
Ang tanong sa paaralan at ospital ay maaaring medyo mahirap sa mga tuntunin ng kadalian ng paghahanap, ngunit ang iba ay hindi ganoon kalala. Gayunpaman, upang mapabuti ang seguridad, nangangailangan ang PayPal ng karagdagang pagkakakilanlan para sa pagbabago mga sagot sa mga tanong sa seguridad:
Ang PayPal ay isang medyo utopia na halimbawa ng isang secure na pag-reset ng password: nagpapatupad ito ng CAPTCHA upang mabawasan ang panganib ng brute force, nangangailangan ng dalawang tanong sa seguridad, at pagkatapos ay nangangailangan ng isa pang uri ng ganap na magkakaibang pagkakakilanlan para lang mabago ang mga sagot - at iyon ay pagkatapos ng user naka-sign in na. Siyempre, ito mismo ang tayo inaasahan ay mula sa PayPal; ito ay isang institusyong pinansyal na nakikitungo sa malalaking halaga ng pera. Hindi ito nangangahulugan na ang bawat pag-reset ng password ay kailangang sundin ang mga hakbang na ito - ito ay overkill sa karamihan ng mga kaso - ngunit ito ay isang magandang halimbawa para sa mga kaso kung saan ang seguridad ay seryosong negosyo.
Ang kaginhawahan ng sistema ng tanong sa seguridad ay kung hindi mo ito ipinatupad kaagad, maaari mo itong idagdag sa ibang pagkakataon kung kinakailangan ito ng antas ng proteksyon ng mapagkukunan. Ang isang magandang halimbawa nito ay ang Apple, na kamakailan lamang ay nagpatupad ng mekanismong ito [artikulo na isinulat noong 2012]. Sa sandaling sinimulan kong i-update ang application sa aking iPad, nakita ko ang sumusunod na kahilingan:
Pagkatapos ay nakakita ako ng screen kung saan makakapili ako ng maraming pares ng mga tanong at sagot sa seguridad, pati na rin ang isang rescue email address:
Tulad ng para sa PayPal, ang mga tanong ay preselected at ang ilan sa mga ito ay talagang maganda:
Ang bawat isa sa tatlong pares ng mga tanong at sagot ay kumakatawan sa isang iba't ibang hanay ng mga posibleng tanong, kaya maraming mga paraan upang i-configure ang isang account.
Ang isa pang aspeto na dapat isaalang-alang tungkol sa sagot sa tanong na panseguridad ay imbakan. Ang simpleng teksto sa DB ay nagdudulot ng halos parehong mga banta tulad ng sa kaso ng isang password, ibig sabihin, ang paglalantad sa database ay agad na nagpapakita ng halaga at naglalagay hindi lamang sa application sa panganib, ngunit potensyal na ganap na magkakaibang mga application gamit ang parehong mga katanungan sa seguridad (ito ay muli ). Ang isang opsyon ay secure na pag-hash (malakas na algorithm at cryptographically random na asin), ngunit hindi tulad ng karamihan sa mga kaso ng pag-iimbak ng password, maaaring may magandang dahilan para lumabas ang tugon bilang plain text. Ang karaniwang senaryo ay ang pagpapatunay ng pagkakakilanlan ng isang live na operator ng telepono. Siyempre, ang pag-hash ay naaangkop din sa kasong ito (maaaring ipasok lamang ng operator ang sagot na pinangalanan ng kliyente), ngunit sa pinakamasamang kaso, ang lihim na sagot ay dapat na nasa ilang antas ng cryptographic storage, kahit na ito ay simetriko na pag-encrypt. Ibuod: tratuhin ang mga lihim tulad ng mga lihim!
At ang huling aspeto ng mga lihim na tanong at sagot ay mas mahina sila sa social engineering. Ang pagsisikap na direktang humingi ng password sa account ng ibang tao ay isang bagay, ngunit ang pagsisimula ng isang pag-uusap tungkol sa kanyang edukasyon (isang sikat na lihim na tanong) ay ganap na naiiba. Sa katunayan, ito ay lubos na posible para sa iyo na makipag-usap sa isang tao tungkol sa maraming aspeto ng kanilang buhay na maaaring bumubuo ng isang lihim na tanong, at nang hindi pumukaw ng hinala. Siyempre, ang pinakadiwa ng isang lihim na tanong ay nauugnay ito sa karanasan ng isang tao, kaya ito ay naaalala, at dito nakasalalay ang problema - gustong-gusto ng mga tao na pag-usapan ang kanilang mga karanasan sa buhay! Wala kang magagawa tungkol dito maliban kung pipiliin mo ang mga opsyon sa tanong na panseguridad na iyon mas mababa malamang na ma-pull out ng social engineering.
[Ipagpapatuloy.]Sa Mga Karapatan ng Pag-advertise
VDSina nag-aalok ng maaasahan , ang bawat server ay konektado sa isang Internet channel na 500 Mbps at protektado mula sa mga pag-atake ng DDoS nang libre!
Pinagmulan: www.habr.com