🥇Kõik, mida soovisite teada ohutust paroolide lähtestamisest. Osa 1

Hiljuti oli mul aega uuesti mõelda sellele, kuidas peaks töötama turvalise parooli lähtestamise funktsioon, alguses kui ma integreerisin selle funktsiooni ASafaWeb, ja seejärel, kui aitasin kellegi teisega midagi sarnast teha. Teises olukorras tahtsin anda talle viite õigetele ressurssidele, kus on kõik vajalikud üksikasjad turvalise lähtestamise funktsiooni rakendamiseks. Probleem aga on selles, et sellist allikat ei eksisteeri, vähemalt mitte sellist, kus oleks kirjeldatud kõike, mis mulle näib oluline. Seetõttu otsustasin kirjutada selle ise.

Näete, unustatud paroolide maailm on tegelikult üsna salapärane. On palju erinevaid, täiesti vastuvõetavaid seisukohti ja hunnik üsna ohtlikke. On tõenäoline, et olete igaühega neist korduvalt kokku puutunud kui lõppkasutaja; seetõttu püüan neid näiteid kasutada, et näidata, kes teeb kõike õigesti ja kes mitte, ning millele tuleks oma rakenduses õige funktsiooni rakendamiseks keskenduda.

Paroolide salvestamine: krüpteerimine, hashimine ja (oh!) lihttekst

Me ei saa arutada, mida teha unustatud paroolidega, enne kui arutame, kuidas neid salvestatakse. Andmebaasis salvestatakse paroolid kolmes põhivormis:

Lihttekst. On veerg parooli jaoks, mis on salvestatud tavalisel tekstivormingul.
Krüpteeritud. Tavaliselt sümmeetrilise krüpteerimise teel (üks ja sama võti kasutatakse nii krüpteerimiseks kui dekrüpteerimiseks), ning krüpteeritud paroolid on samuti salvestatud ühes veerus.
Hashitud. Ühesuunaline protsess (parooli saab hashida, kuid ei saa dehashida); parool, loodetavasti, kaasneb soolaga ja igaüks neist on oma veerus.

Vaatame kohe üle kõige lihtsama küsimuse: ärge kunagi salvestage paroole lihttekstina! Kunagi. Üksainus haavatavus süstimise, üks hoolimatu varukoopia või üks mitmest teisest lihtsast veast — ja kõik, mäng on läbi, kõik teie paroolid — vabandust, kõik teie klientide paroolid muutuvad avalikuks. Loomulikult tähendaks see suurte tõenäosuste olemasolu, et kõik nende paroolid kõikidest nende kontodest teistes süsteemides. Ja see oleks teie süü. kõikidest nende kontodest teistes süsteemides. Ja see on teie süü.

Krüptimine on parem, kuid tal on omad nõrkused. Krüptimise probleem on dekodeerimine; neid uskumatu välja nägevaid krüpte saab võtta ja muuta tagasi lihttekstiks, ning kui see juhtub, oleme tagasi loetavate paroolide olukorras. Kuidas see juhtub? Väike viga imbub koodi, mis tegeleb parooli dekodeerimisega, tehes selle avalikult kättesaadavaks — see on üks võimalus. Ründajad pääsevad ligi masinale, kus on salvestatud krüptitud andmed — see on teine võimalus. Veel üks võimalus on see, et varastatakse andmebaasi varukoopia ning keegi saab samuti krüpteerimise võtme, mis tihti hoitakse väga ebaturvaliselt.

Ja see toob meid hashing'uni. Hashing'u idee seisneb selles, et see toimib ühes suunas; ainus võimalus võrrelda kasutaja sisestatud parooli selle hashitud versiooniga on sisestatava hashimine ja nende võrreldamine. Ründetegevuste vältimiseks selliste tööriistade nagu 'vikerkaaretabelid' abil lisame soola protsessi, et tuua sisse juhuslikkust (kogu pildi saamiseks lugege minu postitus krüptograafilise salvestamise kohta). Lõppude lõpuks, õige rakendamise korral saame suure usaldusväärsusega väita, et hashitud paroolid ei muutu kunagi enam lihttekstiks (erinevate hashimisalgoritmide eeliste kohta räägin ma teises postituses).

Kohene arutelu hashing'u ja krüptimise üle: ainus põhjus, miks sul kunagi on vaja parooli krüptida, mitte hashida, on see, et sul on vaja näha parooli lihttekstis ja sa ei tohiks seda kunagi soovida, vähemalt tavalise veebisaidi olukorras. Kui sul seda on vaja, siis tõenäoliselt teed sa midagi valesti!

Tähelepanu!
Postituse allosas on osa ekraanipildist pornograafilisest veebisaidist AlotPorn. See on korralikult kärbitud, ja nii pole seal midagi, mida rannas näha ei võiks, kuid kui see ikkagi võib põhjustada mingeid probleeme, siis ära kerige alla.

Alati lähtestage parool, kunagi ärge seda meelde tuletage

Kas sind on kunagi palutud luua funktsioon meeldetuletus Parooli? Astuge tagasi ja mõelge sellele palvele vastupidiselt: miks on vajalik see „meeldetuletus“? Sest kasutaja on parooli unustanud. Mida me tõeliselt tahame teha? Aidata tal taas süsteemi sisse logida.

Mõistan, et sõna „meeldetuletus“ kasutatakse (tihti) kõnekeeles, kuid tegelikult üritame ohutult aidata kasutajal taas online olla. Kuna meil on vaja turvalisust, on kaks põhjust, miks meeldetuletus (st kasutaja parooli saatmine) ei sobi:

E-post on ebaturvaline kanal. Niivõrd, kuivõrd me ei edastaks midagi konfidentsiaalset HTTP kaudu (kasutaksime HTTPS-i), ei peaks me edastama midagi e-posti teel, kuna selle transportkiht on ebaturvaline. Tegelikult on see palju hullem kui teabe edastamine kaitsmata transportprotokolli kaudu, sest e-kirjad salvestatakse sageli mäluseadmest, on süstemaatiliselt kergesti ligipääsetavad, edasi saadetavad ja levitatavad, kergesti kuritarvitavad ja nii edasi. Krüpteerimata e-post on äärmiselt ebaturvaline kanal.
Te ei tohiks mingil juhul pääseda paroolile. Lugege eelmist jaotist salvestamise kohta – teil peaks olema parooli räsi (hea soolaga), st te ei tohiks mingil viisil olla võimeline parooli välja võtma ja seda e-postiga saatma.

Las ma näitan probleemi näite abil usoutdoor.com: Siin on tüüpiline sisselogimise leht:

Ilmselgelt on esimene probleem, et sisselogimise leht ei lae HTTPS-i kaudu, kuid sait pakub ka parooli saatmist („Saada parool“). Võib-olla on see näide eelpoolmainitud kõnekeelsest kasutamisest, seega teeme veel ühe sammu ja vaatame, mis juhtub:

Kahjuks ei tundu see palju paremini; ja e-post kinnitab probleemi olemasolu:

See ütleb meile kahest olulist aspektist usoutdoor.com:

Sait ei räsi paroolide. Parimal juhul on nad krüpteeritud, aga on täiesti tõenäoline, et nad on salvestatud lihttekstina; vastupidist tõendit me ei näe.
Sait saadab pikaajalise parooli (me võime sellele tagasi pöörduda ja kasutada seda korduvalt) kaitsmata kanali kaudu.

Selgitanud sellele, peame kontrollima, kas taastamisprotsess toimub turvaliselt. Esiteks peame veenduma, et taotlejatel on õigus taastamist teostada. Teisisõnu, enne seda vajame identifitseerimise kontrolli; vaatame, mis juhtub, kui isik tuvastatakse ilma eelneva kontrollita, kas ta tõesti on konto omanik.

Kasutajanimede loetlemine ja selle mõju anonüümsusele

Seda probleemi on parem illustreerida visuaalselt. Probleem:

Kas näete? Pöörake tähelepanu sõnumile „There is no user registered with this email address“ („Sellise e-posti aadressiga kasutajat ei ole registreeritud“). Probleem tekib selgelt siis, kui selline sait kinnitab erinevate sellise e-posti aadressiga registreeritud kasutaja. Bingo – olete just avastanud oma abikaasa/ülemuse/naabrinaise porno-fetiši!

Loomulikult on pornograafia üsna klassikaline näide privaatsuse olulisusest, kuid oht isikute sidumisest kindla veebisaidiga on palju laiem kui eespool kirjeldatud potentsiaalselt piinlik olukord. Üks oht on sotsiaalne inseneritehnika; kui ründaja suudab isiku teenusega seostada, siis tal on teave, mida ta saab hakata kasutama. Näiteks võib ta võtta ühendust isikuga, et esineda veebisaidi esindajana ja küsida lisainfot, püüdes teha sihtkalastamist (spearphishing).

Sellised praktikud toovad esile „kasutajanimede loetlemise“ ohu, kus saab lihtsate grupipäringute ja nende vastuste analüüsi abil kontrollida, kas veebisaidil on terve kogum kasutajanimesid või e-posti aadresse. Kas teil on nimekiri kõikidest töötajate e-posti aadressidest ja paar minutit skripti kirjutamiseks? Siis näete, milles probleem seisneb!

Mis oleks alternatiiv? Tegelikult on see üsna lihtne ja suurepäraselt ellu viidud Entropay:

Siin ei avalikusta Entropay absoluutset mitte midagi selle süsteemis oleva e-posti aadressi kohta isegi sellele, kes ei oma seda aadressi. Kui te omanik olete kui see aadress ei eksisteeri süsteemis, saate sellise elektronkirja:

Muidugi on olemas vastuvõetavad olukorrad, kus keegi arvab, et on registreerunud veebisaidil. kuid see ei ole nii või tegi seda teise e-posti aadressiga. Ülaltoodud näide käsitleb mõlemaid olukordi tõhusalt. Ilmselgelt, kui aadress vastab, saadetakse teile e-kiri, mis lihtsustab parooli lähtestamist.

Valitud Entropay lahenduse nüanss on see, et identiteedi kontroll toimub e-posti kaudu enne mis tahes veebikontrolli. Mõned saidid küsivad kasutajatelt salajase küsimuse vastust (rohkem sellest allpool) kuni kuidas saab lähtestamine alata; probleemiks on see, et tuleb vastata küsimusele, esitades samal ajal mingit tüüpi identiteedi (e-posti või kasutajanime), mis teeb intuitiivse vastamise peaaegu võimatuks, paljastades samas anonüümse kasutaja konto olemasolu.

Sel viisil on väike kasutajamugavuse langus, sest olemasoleva konto lähtestamise katse korral ei ole kohest tagasisidet. Muidugi, selles seisneb e-kirja saatmise mõte, kuid tavalise lõppkasutaja seisukohalt, kui ta sisestab vale aadressi, saab ta sellest esmakordselt teada alles e-kirja saades. Selline olukord võib tekitada stressi, kuid see on väike hind nii harva esineva protsessi eest.

Veel üks tähelepanek, mis veidi teemast kõrvale kaldu, on, et sisselogimise abifunktsioonid, mis paljastavad kasutajanime või e-posti aadressi õigsuse, esinevad sama probleemiga. Alati vastake kasutajale sõnumiga „Kasutajanime ja parooli kombinatsioon ei ole kehtiv”, mitte kinnitades selgelt identifitseerimisalast teavet (näiteks „kasutajanimi on õige, kuid parool on vale”).

Parooli lähtestamise saatmine versus lähtestamise URL-i saatmine

Järgmine kontseptsioon, mida peame arutama, on seotud parooli lähtestamise meetodiga. On kaks populaarsemat lahendust:

Uue parooli genereerimine serveris ja selle saatmine e-posti teel
E-kirja saatmine unikaalse URL-iga, mis lihtsustab lähtestamisprotsessi

Kuigi palju juhendeid, esimest punkti ei tohiks kunagi kasutada. Selle probleem seisneb selles, et see tähendab, et olemas on salvestatud parool, millega võib igal ajal tagasi pöörduda ja uuesti kasutada; see edastati kaitsmata kanaliga ja jääb teie sisse tulekutesse. On oht, et sisse tulekud sünkroonitakse mobiilseadmete ja e-posti kliendiga ning neid võib veebiteenuses pika aja jooksul ka veebis hoida. Idee on see, et e-posti kast ei ole usaldusväärne vahend pikaajaliseks salvestamiseks.

. Kuid peale selle on esimesel punktil veel üks tõsine probleem — see kergendab maksimaalselt kahjulikku konto lukustamist. Kui tean e-posti aadressi, millel on konto veebilehel, siis võin selle igal ajal lukustada, lihtsalt lähtestades tema parooli; see on teenuse keelamise rünnak, mis on „serveeritud sinise äärega taldrikul“! Just seetõttu peaks lähtestamine toimuma ainult pärast eduka kontrolli, et küsijal on selleks õigus.

Kui räägime lähtestamise URL-ist, siis mõtleme veebilehe aadressile, mis on ainulaadne selle konkreetse lähtestamisprotsessi jaoks. Loomulikult peab see olema juhuslik, seda ei tohi kergesti arvata ning see ei tohi sisaldada mingeid välist linke kontole, mis lihtsustaks lähtestamist. Näiteks ei tohiks lähtestamise URL olla lihtsalt tee nagu „Reset/?username=JohnSmith“.

Tahame luua ainulaadse tokeni, mida saab saata e-kirjas kui lähtestamise URL, ja seejärel võrrelda seda serveri talletusega kasutajakontoga, kinnitades seeläbi, et konto omanik on tõepoolest sama inimene, kes püüab parooli lähtestada. Näiteks token võib olla kujul „3ce7854015cd38c862cb9e14a1ae552b“ ja see salvestatakse tabelisse koos lähtestamise eest vastutava kasutaja ID ja tokeni genereerimise ajaga (rohkem selle kohta allpool). Kui e-kiri saadetakse, sisaldab see URL-i nagu „Reset/?id=3ce7854015cd38c862cb9e14a1ae552b“, ning kui kasutaja selle avab, küsib leht tokeni olemasolu, millele järgneb kasutaja info kinnitamine ja parooli muutmise lubamine.

Muidugi, kuna eespool kirjeldatud protsess (loodetavasti) võimaldab kasutajal luua uue parooli, tuleb tagada, et URL laaditakse HTTPS kaudu. Ei, saata see POST-päringuga HTTPS kaudu ei piisa, see URL koos tokeniga peab kasutama transportkihi turvalisust, et uue parooli sisestamise vormile ei oleks võimalik rünnakut teostada MITM ja kasutaja loodud parool edastataks kaitstud ühenduse kaudu.

Samuti peab parooli lähtestamise URL-ile lisama tokeni aegumistähtaega, et lähtestamise protsess saaks toimuda kindla aja jooksul, näiteks tunni jooksul. See tagab, et lähtestamise ajavahemik oleks minimaalne, et see, kes on saanud selle lähtestamise URL-i, saaks tegutseda ainult selle väga väikese akna jooksul. Muidugi võib ründaja protsessi uuesti alustada, kuid tal on vaja hankida veel üks ainulaadne lähtestamise URL.

Lõpuks peame tagama, et see protsess oleks ühekordne. Pärast lähtestamise protsessi lõpetamist tuleb token eemaldada, et lähtestamise URL ei oleks enam aktiivne. Eelmine punkt on vajalik, et ründajal oleks väga väike aken, mille jooksul ta võiks lähtestamise URL-i manipuleerida. Pluss, muidugi, pärast eduka lähtestamise lõpetamist pole token enam vajalik.

Mõned nendest sammudest võivad tunduda liialdatud, kuid need ei takista kasutatavust ning tõeliselt suurendavad turvalisust, ehkki olukordades, mille arvame, et saavad olema harvad. 99% juhtudest kasutab kasutaja lähtestamist väga lühikese aja jooksul ega käi parooli uuesti lähitulevikus lähtestamas.

CAPTCHA roll

Oi, CAPTCHA, kaitsevahend, mida me kõik armastame vihata! Tegelikult on CAPTCHA vahend mitte niivõrd kaitseks, kuivõrd identifitseerimiseks — kas oled inimene või robot (või automatiseeritud skript). Selle eesmärk on vältida automaatset vormide saatmist, mis, muidugi, võib rakendatakse katse rikkuda kaitset. Paroolide lähtestamise kontekstis tähendab CAPTCHA, et lähtestamisfunktsiooni ei saa rünnata jõhkrate katsete kaudu, et kas spammida kasutajat hiljem või püüda määrata konto olemasolu (mis, muidugi, oleks võimatu, kui oled järginud identifitseerimise kontrollimise osas antud nõuandeid).

Muidugi ei ole CAPTCHA iseenesest ideaalne; on palju juhtumeid selle tarkvara "häkkimisest" ja piisavate eduvõimaluste saavutamisest (60-70%). Lisaks on olemas lahendus, mida näidatakse minu postituses CAPTCHA häkkimisest automatiseeritud inimeste poolt, kus saab maksta inimestele sentidest, et nad lahendaksid iga CAPTCHA ja saavutaksid 94% eduvõime. See tähendab, et see on haavatav, kuid (veidi) tõstab sissepääsuläve.

Vaadakem näiteks PayPali:

Selles olukorras ei saa parooli taastamisprotsess alata enne CAPTCHA lahendamist, seega teoreetiliselt on protsessi automatiseerimine võimatu. Teoreetiliselt.

Kuid enamikul veebirakendustest oleks see ülepingutamine ja kindlasti tähendab see kasutatavuse vähenemist — inimesed lihtsalt ei armasta CAPTCHA-d! Lisaks on CAPTCHA midagi, millele on vajadusel lihtne tagasi pöörduda. Kui teenus hakkab rünnaku all olema (siin on hea logimine, kuid sellest räägime hiljem), siis on CAPTCHA lisamine väga lihtne.

Salajased küsimused ja vastused

Käideldud meetodite puhul saime parooli taastada lihtsalt, kui meil oli juurdepääs e-posti kontole. Räägin "lihtsalt" sellest, kuid muidugi on kellegi teise e-posti kontole ebaseaduslik juurdepääsu saamine peab võib olla keeruline protsess. Kuid see ei ole alati nii.

Tegelikult illustreerib ülaltoodud link Sarah Pailini Yahoo! konto häkkimise kohta kaht eesmärki; esimene on näidata, kui lihtne on (mõningaid) e-posti kontosid häkkida, teine on näidata, kuidas halbu salajasi küsimusi saab pahatahtlikult kasutada. Kuid naaseme selle juurde hiljem.

Paroolide taastamise probleem, mis sõltub sajaprotsendiliselt e-postist, on selles, et saidi konto, mille parooli te üritate taastada, terviklikkus sõltub sajaprotsendiliselt e-posti konto terviklikkusest. Igaühel, kes pääseb teie e-posti kontole, on juurdepääs igale kontole, mille parooli saab taastada lihtsa e-kirja saamisega. Selliste kontode jaoks on e-post teie veebielu "kõikide uste võtme".

Üks viis seda riski vähendada on rakendada salajase küsimuse ja vastuse mustrit. Ilmselt olete neid juba näinud: valite küsimuse, millele ainult teie peate teama vastust, mille peale üksikasjalikult küsitakse parooli lähtestamisel. See suurendab kindlustunnet, et isik, kes püüab lähtestada, on tõepoolest konto omanik.

Naaseme Sarah Palini juurde: viga oli selles, et vastused tema salajastele küsimustele olid liiga kergesti leitavad. Eriti, kui olete nii oluline avaliku elu tegelane, pole teave ema neiupõlvenime, hariduse ajaloo või selle kohta, kus keegi oleks võinud elada, just salajane. Tegelikult saab suur osa sellest infot leida praktiliselt igaüks. Just nii juhtus Sarahiga:

Häkker David Kernell pääses Paliniga seotud kontole, leidnud detailid tema eluloo kohta, nagu tema ülikool ja sünniaeg, ning seejärel kasutas Yahoo! unustatud parooli taastamise funktsiooni.

See on eelkõige Yahoo! projekteerimisviga — selliste lihtsate küsimuste esitamise kaudu saboteeris ettevõte salajase küsimuse väärtust ja seega ka oma süsteemi kaitset. Loomulikult on konto paroolide lähtestamine alati keerulisem, sest te ei saa omaniku tuvastamiseks saata talle e-kirja (ilma teise aadressita), kuid õnneks pole täna sellise süsteemi loomiseks palju võimalusi.

Naaseme salajaste küsimuste juurde — on variant pakkuda kasutajale võimalust luua oma küsimusi. Probleem on selles, et tulemuseks on kohutavalt ilmseid küsimusi:

Mis värvi on taevas?

Küsimused, mis panevad inimesi piinlikkusse, kui salajane küsimus kasutab inimest (näiteks helistuskeskuses):

Kellest ma jõulude ajal voodis olin?

Või avameelselt lollakad küsimused:

Kuidas kirjutatakse 'parool'?

Kui rääkida salajastest küsimustest, peavad kasutajad end ise päästma! Teisisõnu, salajane küsimus peaks määrama ise veebisait, veel parem, esitama seeria salajasi küsimusi, mille hulgast kasutaja saab valida. Ja mitte lihtsalt valida ühte; ideaaljuhul peaks kasutaja valima kaks või rohkem salajast küsimust konto loomise ajal., mis kasutatakse seejärel teise tuvastuskanalina. Mitme küsimuse olemasolu suurendab kontrollimise usaldusväärsust ning annab võimaluse juhuslikkuse lisamiseks (mitte alati sama küsimust esitada), samuti tagab veidi liialdatust juhuks, kui tegelik kasutaja on parooli unustanud.

Milline peaks olema hea salajane küsimus? Sellele mõjutavad mitmed tegurid:

See peaks olema lühike — küsimus peab olema selge ja ühemõtteline.
Vastus peab olema konkreetne — me ei vaja küsimust, millele üks inimene võib vastata erinevalt
Võimalikud vastused peavad olema mitmekesised — küsimus kellegi lemmikvärvi kohta annab väga väikese vastuste hulga
Vastuse otsimine peab olema keeruline — kui vastust on lihtne leida igaühel (mõelgem kõrgesse ametisse olevatele inimestele), siis on see halb püsiv
Vastus peab olema aja jooksul — kui küsida kellegi lemmikfilmi, siis aasta pärast võib vastus olla teine Nagu alati, on olemas veebisait, mis on pühendatud headest küsimustest, nimega

GoodSecurityQuestions.com . Osad küsimused tunduvad täiesti head, teised ei vasta eespool kirjeldatutele, eelkõige „otsimise lihtsuse” testile.Las ma demonstreerin, kuidas salajased küsimused on rakendatud PayPalis ja eriti, milliseid jõupingutusi sait osutab tuvastamiseks. Ülal nägime protsessi alguse lehte (CAPTCHA-ga), ja siin näitame, mis juhtub pärast seda, kui olete sisestanud oma e-posti aadressi ja lahendanud CAPTCHA:

Tulemusena saab kasutaja sellise kirja:

Siiani on kõik üsna tavaline, kuid mis peitub selle parooli lähtestamise URL-i taga:

Nii et astuvad mängu salajased küsimused. Tegelikult võimaldab PayPal ka parooli lähtestamist, kinnitades krediitkaardi numbrit, seega on olemas täiendav kanal, millele paljud saidid ei pääse ligi. Ma ei saa lihtsalt parooli muuta, vastamata

kumbagi salajasele küsimusele (või teadmata kaardi numbrit). Isegi kui keegi pääseb ligi minu e-postile, ei saa ta PayPali konto parooli lähtestada, kui ta ei tea minust veidi rohkem isiklikku teavet. Millist teavet? Siin on PayPali pakutavad salajaste küsimuste valikud: salajaste küsimuste (või mitte teades kaardi numbrit). Isegi kui keegi haarab mu e-posti, ei saa ta PayPali konto parooli lähtestada, kui ta ei tea minust veidi rohkem isiklikku teavet. Millist teavet? Siin on PayPali pakutavad salajaste küsimuste valikud:

Küsimus kooli ja haigla kohta võib olla veidi kaheldav lihtsa otsingu seisukohast, kuid ülejäänud pole nii halvad. Siiski, PayPali turvalisuse tõstmiseks nõuab see täiendavat tuvastamist muudatused salajastele küsimustele vastamiseks:

PayPal on üsna utoopiline näide turvalisest parooli lähtestamisest: see kasutab CAPTCHA-d, et vähendada bruteforce rünnakute ohtu, nõuab kahte salajast küsimust ja seejärel nõuab veel ühte täiesti erinevat tuvastamisviisi ainult vastuste muutmiseks — ja see kõik toimub pärast seda, kui kasutaja on juba sisse logitud. Loomulikult ootasime just seda PayPalilt; see on finantsorganisatsioon, mis tegeleb suurte rahasummadega. See ei tähenda, et iga parooli lähtestamine peaks järgima neid samme — enamikul juhtudel on see liialdus — kuid see on hea näide juhtudest, kus turvalisus on tõsine asi. Salajaste küsimuste süsteemi mugavuseks on see, et kui te ei rakendanud seda kohe, saab seda hiljem lisada, kui ressursi kaitse tase seda nõuab. Hea näitena toob Apple, kes rakendas selle mehhanismi alles hiljuti

[artikkel kirjutatud 2012. aastal] . Ühe korra iPadil rakendust uuendades nägin ma järgmist soovi:Siis nägin ekraanile, kus oli võimalik valida mitmeid salajaste küsimuste ja vastuste paare, samuti varu e-posti aadress:

Mis puutub PayPali, siis küsimused on eelnevalt valitud ja mõned neist on tegelikult üsna head:

Iga kolme küsimuste ja vastuste paari puhul esindab eraldi hulk võimalikke küsimusi, seega on konto konfigureerimiseks piisavalt võimalusi.

Teine aspekt, mida tuleks arvesse võtta seoses salajasele küsimusele vastamisega, on säilitamine. Lihtteksti hoidmine andmebaasis esitab peaaegu samu ohte kui parooliga, nimelt lekib andmebaasi paljastamine koheselt väärtusi ja seab ohtu mitte ainult rakenduse, vaid potentsiaalselt ka täiesti teised rakendused, mis kasutavad samu salajasi küsimusi (see on jälle

küsimus acai marjadest ainu küsimus). Üks võimalus on ohutu räsimine (tuginev algoritm ja krüptograafiliselt juhuslik sool), kuid erinevalt enamikest paroolide hoidmise juhtumitest võib siin olla põhjendatud vajadus vastuse nähtavuse järele tavalise tekstina. Tüüpiliseks stsenaariumiks on isiku tuvastamine elava operaatori kaudu telefoni teel. Loomulikult on ka räsimine kohaldatav (operaator saab lihtsalt sisestada kliendi edastatud vastuse), kuid halvematel juhtudel peaks salajane vastus olema mingil krüptograafilise hoiustamise tasemel, isegi kui see on lihtsalt sümmeetriline krüptimine. Kokkuvõtteks: tehke saladustega nii, nagu need oleks saladused!

Ja viimane aspekt salajaste küsimuste ja vastuste kohta — need on rohkem avatud sotsiaalsele inseneritööle. Proovida jätkuvalt välja uurida parooli kellegi teise kontole — see on üks asi, kuid rääkida tema haridusest (populaarne salajane küsimus) — see on hoopis teine. Tegelikult saate täiesti reaalselt suhelda kellegagi paljude tema elu aspektide kohta, mis võivad esindada salajast küsimust, ja mitte tekitada kahtlusi. Loomulikult on salajase küsimuse olemus selles, et see on seotud kellegi elu kogemusega, seega on see meelespidamise seisukohalt lihtne, ja just siin peitub probleem — inimesed armastavad rääkida oma elukogemusest! Sellele on raske midagi ette võtta, kui valida salajaste küsimuste variandid, et neid vähem tõenäoliselt oleks võimalik välja uurida sotsiaalse inseneritööga. [Jätkub.]

pakub usaldusväärseid