Hiljuti oli mul aega uuesti mõelda, kuidas peaks turvaline parooli lähtestamise funktsioon töötama, esmalt kui ma seda funktsionaalsust integreerisin , ja hiljem, kui aitasin teisel inimesel midagi sarnast teha. Teisel juhul tahtsin anda talle lingi kantud allikale, kus on kõik üksikasjad turvalise lähtestamise funktsiooni rakendamise kohta. Probleem on aga selles, et sellist allikat ei eksisteeri, vähemalt mitte sellist, kus on kirjas kõik, mis mulle oluline tundub. Seetõttu otsustasin kirjutada selle ise.
Noh, unustatud paroolide maailm on tegelikult üsna salapärane. On olemas palju erinevaid, täiesti vastuvõetavaid vaatenurki ja hulgaliselt üsna ohtlikke. On tõenäoline, et olete nendega kõikide kasutajana korduvalt kokku puutunud; seetõttu püüan kasutada neid näiteid, et näidata, kes teeb kõik õigesti ja kes mitte, ning millele tuleks keskenduda õigesti rakendatud funktsiooni jaoks oma rakenduses.
Paroolide hoidmine: hashimine, krüpteerimine ja (oh!) lihttekst
Me ei saa arutada, mida teha unustatud paroolidega, enne kui räägime nende säilitamisest. Andmebaasis hoitakse paroole kolmes peamises vormis:
- Lihttekst. On veerg parooliga, mis on hoitud tavapärases tekstivormis.
- Krüpteeritud. Tavaliselt sümmeetrilise krüptimise abil (üks võti kasutatakse nii krüpteerimiseks kui ka dekrüpteerimiseks), ja krüpteeritud paroolid on samuti ühes veerus.
- Hashitud. Ühesuunaline protsess (parooli saab hashida, kuid seda ei saa tagasi dehashida); parool , võiks loota, kaasneb soolaga ning igaühel neist on oma veerg.
Alustame kohe kõige lihtsama küsimusega: Ärge kunagi hoidke paroole lihttekstina! Kunagi. Üksainus haavatavus , üks hooletu varukoopia või üks tosin muud lihtsat viga — ja kõik, mäng läbi, kõik teie paroolid — vabandust, kõik teie klientide paroolid muutuvad avalikuks. Loomulikult tähendab see, et suur tõenäosus, et avalikuks saavad kõikide nende kontoandmete jaoks teistes süsteemides. Ja see on teie süü.
Krüptimine on parem, kuid tal on oma nõrkused. Krüptimise probleem seisneb dekrüptimises; neid hullumeelseid näivaid krüpte saab võtta ja muuta tagasi tavaliseks tekstiks, ja kui see juhtub, naaseme olukorda, kus paroolid on loetavad. Kuidas see juhtub? Väike viga hiilib dekrüptimise koodi, mis muudab selle avalikult kättesaadavaks — see on üks viis. Häkkerid saavad juurdepääsu masinale, kus on salvestatud krüpteeritud andmed — see on teine viis. Veel üks viis on, et varastatakse andmebaasi varukoopia ja keegi saab ka krüpteerimisvõtme, mis on sageli salvestatud väga ebatäpselt.
See to, et viib meid hashingu juurde. Hashimise idee seisneb selles, et see toimub ühes suunas; ainus viis kasutaja sisestatud parooli ja selle hashitud versiooni võrdlemiseks on sisendi hashimine ja nende võrdlemine. Rünnakute vältimiseks, kasutades selliseid tööriistu nagu 'vikerkaare tabelid', lisame soolaga protsessi juhuslikkuse (täiendav info on minu krüptograafilise salvestuse kohta). Õige rakendamise korral saame suure usaldusväärsusega väita, et hashitud paroolid ei muutu kunagi enam tavaliseks tekstiks (erinevate hashimisalgoritmide eeliseid käsitlen muudes postitustes).
Lühike argument hashimise ja krüptimise kohta: ainus põhjus, miks sul võib kunagi olla vaja parooli krüptida, mitte hashida — on see, kui soovid parooli näha tavalises tekstis ja seda ei peaks kunagi tahtma, vähemalt standardse veebisaidi kontekstis. Kui sul seda vaja on, siis tõenäoliselt teed sa midagi valesti!
Tähelepanu!
Allpool postituses on ekraanipilt AlotPorni pornosaidist. See on korralikult lõigatud ja seal pole midagi sellist, mida ei võiks rannas näha, kuid kui see ikkagi võib probleeme tekitada, siis ärge kerige allapoole.
Alati resettingi parooli, kunagi ärge kunagi meelde tuletage seda
Kas teilt on kunagi küsitud, et loote parooli meeldetuletuse Parooli? Astuge samm tagasi ja mõelge sellele palvele vastupidiselt: miks on see "meeldetuletus" vajalik? Sest kasutaja on parooli unustanud. Mida me tegelikult tahame teha? Aitame tal uuesti süsteemi sisse logida.
Mõistan, et sõna „meeldetuletus” kasutatakse (tihti) kõnekeeles, kuid tegelikult püüame me ohutult aidata kasutajal uuesti veebis olla.Kuna me vajame turvalisust, on kaks põhjust, miks meeldetuletus (st parooli saatmine kasutajale) ei sobi:
- E-post on ebaturvaline kanal. Nagu me ei edastaks midagi konfidentsiaalset HTTP kaudu (kasutame HTTPS-i), ei tohiks ka e-posti kaudu edastada midagi, kuna selle transportkihi turvalisus on puudulik. Tegelikult on see palju hullem kui teabe edastamine kaitsmata transportprotokolli kaudu, kuna e-post salvestatakse sageli salvestusseadmetesse, on nüüdisaegsete süsteemiadministraatorite juurdepääsetav, edastatakse ja levitatakse, ning on ligipääsetav pahavarale jne. Krüpteerimata e-post on äärmiselt kaitsmata kanal.
- Te ei tohiks igal juhul omada juurdepääsu paroolile. Lugege uuesti eelmist jaotist ladustamise kohta — teil peaks olema parooli räsi (hea soolaga), see tähendab, et te ei tohiks mingil moel olla võimeline parooli välja tõmbama ja seda e-posti teel saatma.
Las ma demonstreerin probleemi näiteks : Siin on tüüpiline sisselogimise leht:
Ilmselt on esimene probleem selles, et sisselogimisleht ei lae HTTPS-i kaudu, kuid saiti pakutakse ka parooli saatmiseks («Send Password»). See võib olla eespool mainitud kõnekeelse kasutuse näide, seega teeme veel ühe sammu ja vaatame, mis juhtub:
Kahjuks ei tundu see ka mitte oluliselt parem; ja e-kiri kinnitab probleemi olemasolu:
See ütleb meile kahest olulisest aspektist usoutdoor.com:
- Sait ei hash'i paroole. Parim juhul on need krüpteeritud, kuid tõenäoliselt säilitatakse neid tekstivormingus; vastupidist tõendit me ei näe.
- Sait saadab pikaajalise parooli (me saame seda uuesti ja uuesti kasutada) kaitsmata kanali kaudu.
Selgeks saades peame veenduma, et lähtestamisprotsess toimub turvaliselt. Esiteks peame veenduma, kas taotlejal on õigus lähtestada. Teisisõnu, enne seda vajame identiteedi kontrollimist; vaatame, mis juhtub, kui isik tuvastatakse ilma eelneva kontrollita, et veenduda, et taotleja on tõeliselt konto omanik.
Kasutajanime loetelu ja selle mõju anonüümsusele
Seda probleemi on parem illustreerida visuaalselt. Probleem:
Näete? Pange tähele sõnumit 'There is no user registered with this email address' ('Selle e-posti aadressiga kasutajat ei ole registreeritud'). Probleem tekib selgelt siis, kui selline veebisait kinnitab olemasolu konto, millel on selline e-posti aadress. Bingo – te just avastasite oma abikaasa/juhataja/naabri porno-fetiši!
Muidugi on porno üsna klassikaline näide privaatsuse olulisusest, kuid oht siduda isik teatud veebisaidiga on palju laiem kui eelpool kirjeldatud potentsiaalselt ebamugav olukord. Üks oht on sotsiaalne inseneerimine; kui ründaja suudab isiku siduda teenusega, siis on tal teave, mida ta suudab hakata ära kasutama. Näiteks võib ta võtma ühendust inimesega, esinedes veebisaidi esindajana, ja küsida lisainfot, püüdes teha .
Sarnased praktikud põhjustavad ka kasutajanime loendamise ohtu, kus saab kontrollida kogu kasutajanimede või e-posti aadresside kogumi olemasolu veebisaidil lihtsate grupipäringute ja nende vastuste uurimise kaudu. Kas teil on töötajate e-posti aadresside nimekiri ja paar minutit skripti kirjutamiseks? Siis näete, milles probleem seisneb!
Mis on alternatiiv? Tegelikult on see üsna lihtne ja suurepäraselt rakendatud :
Entropay ei avalda oma süsteemis e-posti aadressi olemasolu. kellel seda aadressi pole.. Kui te omanik olete ja see aadress ei eksisteeri süsteemis, siis saate sellise e-kirja:
Muidugi on vastuvõetavaid olukordi, kus keegi arvab, et on registreerunud veebisaidile, aga see ei ole nii, või on ta seda teinud teise e-posti aadressiga. Ülaltoodud näide käsitleb mõlemat olukorda. Kui aadress on õige, saate kirja, mis lihtsustab parooli lähtestamist.
Valitud Entropay lahenduse peenusus seisneb selles, et identiteedi kontrollimine toimub e-posti kaudu enne igasugust veebikontrolli. Mõned saidid küsivad kasutajatelt salajase küsimuse vastust (rohkem infot selle kohta allpool) kuni enne parooli lähtestamise alustamist; siiski on selle probleem selles, et küsimusele tuleb vastata, esitades samal ajal mingit liiki identifitseerimist (e-post või kasutajanimi), mistõttu on seejärel raske intuitiivselt vastata, paljastamata anonüümse konto olemasolu.
Selle lähenemisviisiga on olemas väike kasutatavuse langus, kuna kui proovite lähtestada mittes olemasolevat kontot, ei ole kohest tagasisidet. Loomulikult on selle e-kirja saatmise mõte seesama, kuid tavalise lõppkasutaja seisukohalt saab ta vale aadressi sisestades selle tõeliselt teada alles pärast kirja saamist. See võib tekitada teatud pinget, kuid see on väike hind nii harva esineva protsessi eest.
Veel üks tähelepanek, mis veidi teemast kõrvale kaldu: sisselogimise abifunktsioonid, mis paljastavad kasutajanime või e-posti aadressi õigsuse, kannatavad sama probleemi all. Alati vastake kasutajale sõnumiga 'Kasutajanime ja parooli kombinatsioon on vale' (Your username and password combination is invalid), mitte ära kinnitage identifitseerimisteave olemasolu (näiteks 'kasutajanimi on õige, kuid parool on vale').
Parooli lähtestamise saatmine vs lähtestamise URL-i saatmine
Järgmine idee, millest me rääkida peame, on seotud parooli lähtestamise meetodiga. On kaks populaarset lahendust:
- Uue parooli genereerimine serveris ja selle saatmine e-posti teel
- E-kirja saatmine unikaalse URL-iga, mis lihtsustab parooli taastamise protsessi
Vaatamata , esimest punkti ei tohiks kunagi kasutada. Selle probleem seisneb selles, et see tähendab salvestatud parooli, millele on võimalik tagasi pöörduda ja uuesti kasutada igal ajal; see on edastatud kaitsmata kanali kaudu ja jääb teie sisse tulevatesse kirjadessse. On tõenäosus, et sisse tulevad kirjad sünkroonitakse mobiilsete seadmete ja e-posti kliendiga, lisaks võivad need veebiteenustes olla väga kaua salvestatud. Punkt on selles, et posti karpi ei saa pidada usaldusväärseks vahendiks pikaajaliseks säilitamiseks.
Ent lisaks sellele on esimesel punktis veel üks tõsine probleem — see maksimaalselt lihtsustab konto blokeerimine pahatahtlikult. Kui ma tean e-posti aadressi, millel konto veebisaidil kuulub, siis saan ma seda igal ajal blokeerida, lihtsalt tema parooli lähtestades; see on teenuskatkestuse rünnak, serveeritud sinise servaga taldrikul! Seetõttu peaks lähtestamine toimuma ainult pärast nõudja õiguste edukat kontrollimist.
Kui räägime lähtestamise URL-ist, siis mõtleme veebisaidi aadressile, mis on ainulaadne selle konkreetse lähtestamise protsessi korral. Muidugi peab see olema juhuslik, seda ei tohiks kergesti arvata ja see ei peaks sisaldama mingeid väliseid linke kontole, mis lihtsustaks lähtestamist. Näiteks ei tohiks lähtestamise URL olla lihtsalt tee nagu "Reset/?username=JohnSmith".
Soovime luua unikaalse tokeni, mille saab e-kirjana saata URL-i jälgimiseks, ning seejärel võrrelda seda salvestatud andmetega serveris, et kinnitada, et konto omanik on tõepoolest sama isik, kes üritab parooli lähtestada. Näiteks võib token olla kujul „3ce7854015cd38c862cb9e14a1ae552b” ja see salvestatakse tabelisse koos kasutaja ID-ga, kes lähtestamist sooritab, ja tokeni genereerimise ajaga (lisainfo allpool). E-kirja saadetuna sisaldab see midagi sellist nagu „Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, ja kui kasutaja selle avab, küsitakse lehelt tokeni olemasolu, kinnitatakse seejärel kasutaja teave ja lubatakse parooli muutmine.
Muidugi, kuna ülaltoodud protsess (loodame) lubab kasutajal luua uue parooli, tuleb tagada, et URL laaditakse HTTPS-i kaudu. Ei, , see URL tokeniga peab kasutama transpordikihi turvalisust, et uue parooli sisestamise vormile ei oleks võimalik rünnakut teostada, ja kasutaja loodud parool edastati turvalise ühenduse kaudu.
Samuti tuleb URL-i lähtestamise jaoks lisada tokeni kehtivuse aeg, et lähtestamisprotsessi saaks teostada teatud aja jooksul, näiteks tunni jooksul. See tagab, et lähtestamise ajakenal on minimaalsed piirangud, et saaja saaks tegutseda ainult selle väga lühikese perioodi jooksul. Loomulikult võib ründaja alustada lähtestamisprotsessi jälle, kuid tal on vaja veel üht unikaalset lähtestamise URL-i.
Lõpuks peame tagama, et see protsess oleks ühekordne. Pärast lähtestamisprotsessi lõpuleviimist tuleb token eemaldada, et lähtestamise URL ei oleks enam aktiivne. Eelmine punkt on vajalik selleks, et ründajal oleks väga väike aken, milles ta saaks lähtestamise URL-i mõjutada. Lisaks, loomulikult ei ole token pärast edukat lähtestamist enam vajalik.
Mõned neist sammudest võivad tunduda liialt liialdatud, kuid need ei häiri kasutatavust ja tõepoolest suudavad suurendada turvalisust, kuigi loodetavasti harvadel juhtudel. 99% juhtudest kasutab kasutaja lähtestamist väga lühikese aja jooksul ja ei lähtesta parooli uuesti lähitulevikus.
CAPTCHA roll
Ah, CAPTCHA, kaitsevahend, mida me kõik armastame vihata! Tegelikult on CAPTCHA vahend rohkem identifitseerimise eesmärgil — olles inimene või robot (või automatiseeritud skript). Selle mõte on vältida automaatset vormide saatmist, mis on loomulikult suuteline rakendatud katse kaudu kaitse murdmiseks. Paroolide lähtestamise kontekstis tähendab CAPTCHA, et lähtestamise funktsiooni ei saa murda bruteforce'iga, et kas spämmeerida kasutajat või proovida tuvastada kontode olemasolu (mida on loomulikult võimatu teha, kui järgite identifitseerimise kontrollimise jaotises antud nõuandeid).
Loomulikult ei ole CAPTCHA iseenesest ideaalne; on mitmeid juhtumeid, kus on saavutatud selle programmilise "murdmise" ja piisava edu määr (60-70%). Lisaks on olemas lahendus, mis on esitatud minu postituses , kus on võimalik maksta inimestele paar senti iga CAPTCHA lahendamise eest ja saavutada 94% edu määra. See tähendab, et see on haavatav, kuid (veidi) tõstab sisenemisse barrieri.
Vaadakem näidet PayPalist:
Antud juhul ei saa lähtestamisprotsess alata enne CAPTCHA lahendamist, seega teoreetiliselt on protsessi automatiseerimine võimatu. Teoreetiliselt.
Kuid enamikele veebirakendustele oleks see üle pingutamine ja absoluutselt tähendab kasutusmugavuse langust — inimesed lihtsalt ei armasta CAPTCHA-d! Lisaks on CAPTCHA selline asi, mille juurde on vajadusel lihtne tagasi pöörduda. Kui teenus hakkab rünnaku alla, (siin tuleb appi logimine, kuid sellest räägime hiljem), siis on CAPTCHA lisamine imelihtne.
Salajased küsimused ja vastused
Kaikse arutatud meetodite abil oli meil võimalik parool lähtestada, omades lihtsalt juurdepääsu e-posti kontole. Ma ütlen «lihtsalt», kuid loomulikult on e-posti konto ebaseaduslik juurdepääsu saamine peab olema keeruline protsess. Kuid .
Tegelikult teenib ülaltoodud link Sarah Palini Yahoo! kontole sisenemise kohta kahte eesmärki: esiteks edastab see, kui kergesti on võimalik (mõningaid) postkaste häkkida, ja teiseks näitab, kuidas võivad halvad salajased küsimused pahatahtlikult kasutada. Kuid naaseme selle juurde hiljem.
Paroolide lähtestamise probleem, mis sõltub täielikult meilidost, on see, et veebisaidi konto, mille parooli te püüate lähtestada, terviklikkus on täielikult sõltuv teie meilidost. Igaüks, kellel on juurdepääs teie meilile, omab juurdepääsu igale kontole, mille parooli saab lihtsalt e-kirja kaudu lähtestada.. Selliste kontode puhul on e-post teie online-elus "kõikide uste võti".
Üks viis selle riski vähendamiseks on rakendada salajase küsimuse ja vastuse mustrit. Kindlasti olete neid juba näinud: valite küsimuse, millele ainult te peavad teada vastus, pärast mida küsitakse seda parooli lähtestamisel. See suurendab usaldusväärsust, et isik, kes proovib lähtestada, on tõepoolest konto omanik.
Naaseme Sarah Palini juurde: viga oli selles, et vastused tema salajasele küsimusele/küsimustele olid kergesti leitavad. Eriti kui sa oled nii olulise avaliku elu tegelane, pole ema neiupõlvenimi, hariduse ajalugu või koht, kus keegi võis minevikus elada, tõeliselt salajane. Tegelikult võib suure osa neist infodest leida praktiliselt igaüks. Just nii juhtus Saraga:
Häkker David Kernell pääses Palini kontole, leides üksikasju tema eluloo kohta, näiteks tema ülikooli ja sünnipäeva ning kasutas seejärel Yahoo! kontode parooli taastamise funktsiooni.
Esiteks on see Yahoo! poolt projekteerimisviga — selliste lihtsate küsimuste esitamisega on ettevõte sisuliselt saboteerinud salajase küsimuse väärtust ja seega ka oma süsteemi kaitset. Loomulikult on e-posti konto paroolide lähtestamine alati keerulisem, kuna te ei saa tõestada selle omamist, saates omanikule e-kirja (ilma teise aadressita), kuid õnneks on täna sellise süsteemi loomiseks palju võimalusi.
Naaseme salajaste küsimuste juurde — kasutajale on võimalik anda ka võimalus luua oma küsimusi. Probleem on selles, et tulemusena saadakse kohutavalt ilmsed küsimused:
Milline on taeva värv?
Küsimused, mis panevad inimesi piinlikku olukorda, kui salajane küsimus kasutab identifitseerimiseks inimest (näiteks kõnekeskuses):
Kellega ma jõulu ajal voodis olin?
Või siiralt rumalad küsimused:
Kuidas kirjutatakse "parool"?
Kui tegemist on salajaste küsimustega, peab kasutaja olema enda eest kaitstud! Teisisõnu, salajane küsimus peaks olema määratud saidi enda poolt, veel parem on esitada seeria salajaste küsimusi, millest kasutaja saab valida. Ja mitte lihtsalt valida ühe; ideaalis peaks kasutaja valima kaks või enam salajast küsimust kontot registreerimise hetkel, mida kasutatakse seejärel teise identifitseerimisviisina. Mitme küsimuse olemasolu suurendab usaldusväärsust kontrolliprotsessis, tagab juhuslikkuse (ei näita alati sama küsimust) ning annab veidi ülejääki juhuks, kui tõeline kasutaja unustab parooli.
Milline peaks olema hea salajane küsimus? Sellele mõjutavad mitmed tegurid:
- See peaks olema lühiülevaade — küsimus peab olema selge ja üheselt mõistetav.
- Vastus peab olema konkreetne — meil ei ole 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 võimalike vastuste alamhulga
- Otsi vastus peab olema keeruline — kui vastuse leidmine on kerge igaühe (mõelgem kõrgelt asetatud inimestele), siis on see halb
- Vastus peab olema püsiv ajaliselt — kui küsida kedagi lemmikfilmi, siis aasta pärast võib vastus olla teine
Nagu see sageli juhtub, on olemas veebisait, mis on pühendatud headest küsimustest ja selle nimi on . Osa küsimustest näib üsna headena, teised ei saa osa eespool kirjeldatud testidest läbi, eriti "lihtsuse leidmise" kontrolli.
Las ma demonstreerin, kuidas salaküsimused on rakendatud PayPalis, ja eriti, milliseid jõupingutusi sait teeb tuvastamiseks. Eelnevalt nägime protsessi alguse lehte (CAPTCHA-ga), ning siin näitame, mis juhtub pärast e-posti aadressi sisestamist ja CAPTCHA lahendamist:
Tulemusena saab kasutaja sellise kirja:
Kõik see on üsna tavaline, aga siin, mis peitub selle lähtestamisse URL-is:
Nii et salaküsimused astuvad mängu. Tegelikult lubab PayPal ka parooli lähtestada, kinnitades krediitkaardi numbrit, seega on olemas täiendav kanal, millele paljud saidid juurdepääsu ei oma. Ma lihtsalt ei saa parooli muuta, ilma et vastaksin mõlemale salajase küsimuste (või teadmata kaardi numbrit). Isegi kui keegi saab mu e-posti, ei suuda ta PayPali konto parooli tagasi seadistada, kui ei tea minust veidi rohkem isiklikku teavet. Millist teavet? Siin on PayPali pakutavad salajaste küsimuste valikud:
Küsimus koolist ja haiglast võib otsimise lihtsuse seisukohalt olla veidi kaheldav, kuid teised ei ole nii halvad. Siiski, PayPal nõuab turvalisuse tõstmiseks täiendavat tuvastamist, et muudatused vastata salajastele küsimustele:
PayPal on üsna utoopiline näide turvalisest parooli lähtestamisest: see rakendab CAPTCHA-d, et vähendada jõhkrate rünnakute ohtu, nõuab kahte salajast küsimust ja seejärel nõuab veel üht täiesti erinevat tuvastamise meetodit ainult vastuste muutmiseks — ja see pärast seda, kui kasutaja on juba sisse loginud. Muidugi, just seda me ootasime PayPalilt; tegemist on rahandusasutusega, mis tegeleb suurte rahasummadega. See ei tähenda, et iga parooli lähtestamine peab neid samme järgima — enamasti on see üleliigne — kuid see on hea näide olukordadest, kus turvalisus on tõsine äri. бы от PayPal; это финансовая организация, работающая с большими суммами денег. Это не означает, что каждый сброс пароля должен следовать этим этапам — в большинстве случаев это перебор — однако это хороший пример для случаев, когда безопасность — серьёзный бизнес.
Salajasus küsimuste süsteemi mugavus seisneb selles, et kui te ei ole seda kohe rakendanud, saab selle hiljem lisada, kui see on ressursi kaitsetaseme jaoks vajalik. Hea näide selle kohta on Apple, mis rakendas hiljuti seda mehhanismi. [artikkel on kirjutatud 2012. aastal]. Kui alustasin kunagi rakenduse uuendamist iPadil, nägin järgmist palvet:
Siis nägin ma ekraani, kus sai valida mitmeid saladusküsimuste ja vastuste paire, samuti päästemeili aadress:
Mis puutub PayPali, siis küsimused on eelnevalt valitud ja mõni neist on tegelikult üsna hea:
Iga kolme küsimuse ja vastuse paari puhul esindab eraldi hulk võimalikke küsimusi, seega on olemas piisavalt palju viise konto konfigureerimiseks.
Veel üks aspekt, mida tuleks arvesse võtta salajaste küsimuste vastuste osas, on ladustamine. Lihttekstina DB-s hoidmine esitab peaaegu samad ohud nagu paroolide puhul, nimelt - andmebaasi avamine paljastab kohe väärtuse ja seab ohtu mitte ainult rakenduse, vaid potentsiaalselt ka täiesti teised rakendused, mis kasutavad samu salajasi küsimusi (see on jälle ). Üks võimalus oleks turvaline hashimine (tõhus algoritm ja krüptograafiliselt juhuslik sool), kuid erinevalt enamikest parooli hoidmise juhtudest võib siin olla põhjendatud põhjus vastuse nägemiseks lihttekstitena. Tüüpiline stsenaarium on isikutuvastus elava operaatoriga telefoni teel. Loomulikult on sellisel juhul hashimine samuti rakendatav (operaator saab lihtsalt küsija vastuse sisestada), kuid kõige halvemal juhul peaks salajane vastus olema mingil tasemel krüptograafilises salvestuses, isegi kui see on lihtsalt sümmeetriline krüptimine. Kokkuvõtteks: kohtle saladusi nagu saladusi!
Viimane aspekt salajaste küsimuste ja vastuste juures on see, et need on sotsiaalse inseneritehnika suhtes haavatavamad. Proovida otse küsida kellegi konto parooli on üks asi, kuid alustada vestlust tema haridusest (populaarne salajane küsimus) on täiesti midagi muud. Tegelikult saate tõeliselt suhelda kellegagi paljusid aspekte tema elust, mis võivad olla salajane küsimus, põhjustamata kahtlust. Loomulikult on salajase küsimuse mõte see, et see on seotud kellegi elukogemustega, mistõttu see on meeles ja just sellepärast on probleem — inimesed armastavad rääkida oma elukogemustest! Sellele ei saa palju teha, kui valida selliseid salajaste küsimuste variante, et neid oleks vähem tõenäoliselt võimalik sotsiaalse inseneritehnika abil välja tuua.
[Jätkub.]
Reklaami õigustes
VDSina pakub usaldusväärseid , iga server on ühendatud 500 Megabiti Interneti-kanaliga ja tasuta kaitstud DDoS-i rünnakute eest!
Allikas: habr.com
