Mul oli hiljuti aega uuesti mõelda, kuidas turvaline parooli lähtestamise funktsioon peaks töötama, esiteks siis, kui ma seda funktsiooni sisse ehitasin , ja siis, kui ta aitas teisel inimesel midagi sarnast teha. Teisel juhul tahtsin anda talle lingi kanoonilisele ressursile, kus on kõik üksikasjad lähtestamisfunktsiooni ohutu rakendamise kohta. Probleem on aga selles, et sellist ressurssi pole olemas, vähemalt mitte sellist, mis kirjeldaks kõike, mis mulle oluline tundub. Seega otsustasin selle ise kirjutada.
Näete, unustatud paroolide maailm on tegelikult üsna salapärane. On palju erinevaid, täiesti vastuvõetavaid seisukohti ja palju üsna ohtlikke. On tõenäoline, et olete lõppkasutajana igaühega neist korduvalt kokku puutunud; seega proovin nende näidete abil näidata, kes teeb seda õigesti ja kes mitte ning millele peate keskenduma, et funktsiooni oma rakenduses õigesti rakendada.
Paroolide salvestamine: räsimine, krüpteerimine ja (ahhetab!) lihttekst
Me ei saa arutada, mida teha unustatud paroolidega enne, kui arutame, kuidas neid salvestada. Paroolid on andmebaasis salvestatud ühte kolmest põhitüübist:
- Lihttekst. Seal on parooli veerg, mis salvestatakse lihttekstina.
- krüpteeritud. Tavaliselt kasutatakse sümmeetrilist krüptimist (üht võtit kasutatakse nii krüptimiseks kui ka dekrüpteerimiseks) ja samas veerus salvestatakse ka krüpteeritud paroolid.
- räsitud. Ühesuunaline protsess (parooli saab räsida, kuid seda ei saa kustutada); parool, loodetavasti, millele järgneb sool ja igaüks on oma veerus.
Läheme otse kõige lihtsama küsimuse juurde: ärge kunagi salvestage paroole lihttekstina! Mitte kunagi. Üksainus haavatavus , üks hooletult tehtud varukoopia või üks kümnetest muudest lihtsatest vigadest – ja ongi kõik, gameover, kõik teie paroolid – see tähendab, vabandust, paroolid kõigile oma klientidele saab avalikuks omandiks. Muidugi tähendaks see suurt tõenäosust kõigilt nende kontodelt teistes süsteemides. Ja see on teie süü.
Krüpteerimine on parem, kuid sellel on oma nõrkused. Krüpteerimise probleem on dekrüpteerimine; Võime võtta need pöörase välimusega šifrid ja teisendada need tagasi lihttekstiks ning kui see juhtub, oleme taas loetavate paroolidega olukorra juurde. Kuidas see juhtub? Väike viga on koodis, mis dekrüpteerib parooli, muutes selle avalikult kättesaadavaks – see on üks võimalus. Juurdepääsu masinale, kus krüptitud andmeid hoitakse, saavad häkkerid – see on teine viis. Teine võimalus on jällegi varastada andmebaasi varukoopia ja keegi saab ka krüpteerimisvõtme, mis on sageli väga ebaturvaliselt salvestatud.
Ja see viib meid räsimise juurde. Räsimise idee seisneb selles, et see on ühesuunaline; Ainus viis kasutaja sisestatud parooli ja selle räsiversiooni võrdlemiseks on sisendi räsimine ja nende võrdlemine. Et vältida rünnakuid sellistest tööriistadest nagu vikerkaarelauad, soolame protsessi juhuslikult (lugege minu krüptosalvestuse kohta). Lõppkokkuvõttes, kui neid õigesti rakendada, võime kindlalt eeldada, et räsiparoolid ei muutu enam kunagi lihttekstiks (erinevate räsimisalgoritmide eelistest räägin teises postituses).
Kiire argument räsimise ja krüptimise kohta: ainus põhjus, miks peaksite kunagi parooli räsimise asemel krüpteerima, on see, kui peate nägema parooli lihttekstina ja sa ei peaks seda kunagi tahtma, vähemalt tavalise veebisaidi olukorras. Kui vajate seda, siis tõenäoliselt teete midagi valesti!
Hoiatus!
Allpool postituse tekstis on osa pornograafilise veebisaidi AlotPorn ekraanipildist. See on korralikult kärbitud, nii et rannas pole midagi, mida te ei näe, kuid kui see siiski tõenäoliselt probleeme põhjustab, ärge kerige allapoole.
Lähtestage alati oma parool mitte kunagi ära tuleta talle meelde
Kas teil on kunagi palutud luua funktsioon? meeldetuletused parool? Astuge samm tagasi ja mõelge sellele taotlusele vastupidiselt: miks on seda "meeldetuletust" vaja? Kuna kasutaja on parooli unustanud. Mida me tegelikult teha tahame? Aidake tal uuesti sisse logida.
Ma saan aru, et sõna "meeldetuletus" kasutatakse (sageli) kõnekeeles, kuid me tegelikult üritame seda teha aidata kasutajal uuesti võrgus olla. Kuna vajame turvalisust, on meeldetuletus (st kasutajale parooli saatmine) sobimatu kahel põhjusel:
- E-post on ebaturvaline kanal. Nii nagu me ei saadaks HTTP kaudu midagi tundlikku (kasutaksime HTTPS-i), ei tohiks me saata midagi tundlikku e-posti teel, kuna selle transpordikiht on ebaturvaline. Tegelikult on see palju hullem kui lihtsalt teabe saatmine ebaturvalise transpordiprotokolli kaudu, sest kirjad salvestatakse sageli salvestusseadmesse, süsteemiadministraatoritele juurdepääsetavad, edastatakse ja levitatakse, pahavarale juurdepääsetavad jne. Krüptimata kirjad on äärmiselt ebaturvaline kanal.
- Teil ei tohiks igal juhul paroolile juurdepääsu olla. Lugege uuesti üle eelmine osa salvestamise kohta – teil peab olema parooli räsi (koos hea tugeva soolaga), mis tähendab, et teil ei ole võimalik parooli eraldada ja postiga saata.
Lubage mul näidata probleemi näitega : Siin on tüüpiline sisselogimisleht:
Ilmselgelt on esimene probleem see, et sisselogimisleht ei laadita HTTPS-i kaudu, kuid sait pakub ka parooli saatmist ("Saada parool"). Võib-olla on see näide ülalmainitud termini kõnekeelest, nii et astume sammu edasi ja vaatame, mis juhtub:
Kahjuks ei näe see palju parem välja; ja e-kiri kinnitab probleemi olemasolu:
See räägib meile veebisaidi usoutdoor.com kahest olulisest aspektist:
- Sait ei räsi paroole. Parimal juhul on need krüpteeritud, kuid on tõenäoline, et need salvestatakse lihttekstina; Me ei näe tõendeid vastupidise kohta.
- Sait saadab ebaturvalise kanali kaudu pikaajalise parooli (saame tagasi minna ja seda ikka ja jälle kasutada).
Kui see pole korras, peame kontrollima, kas lähtestamisprotsess on tehtud turvalisel viisil. Esimene samm selleks on veenduda, et taotlejal on õigus lähtestada. Teisisõnu, enne seda vajame identiteedikontrolli; vaatame, mis juhtub siis, kui identiteeti kontrollitakse, ilma et oleks eelnevalt kontrollitud, kas taotleja on tegelikult konto omanik.
Kasutajanimede loetlemine ja selle mõju anonüümsusele
Seda probleemi saab kõige paremini illustreerida visuaalselt. Probleem:
Näete? Pöörake tähelepanu sõnumile "Selle e-posti aadressiga pole registreeritud ühtegi kasutajat". Ilmselt tekib probleem, kui sarnane sait kinnitab kättesaadavus registreeritud kasutaja sellise e-posti aadressiga. Bingo – sa avastasid just oma mehe/bossi/naabri pornofetiši!
Muidugi on porno üsna kanooniline näide privaatsuse tähtsusest, kuid konkreetse veebisaidiga sobitamise oht on palju suurem kui ülalkirjeldatud potentsiaalselt piinlik olukord. Üks oht on sotsiaalne manipuleerimine; kui ründaja suudab inimese teenusega sobitada, on tal teave, mida ta saab kasutama hakata. Näiteks võib ta ühendust võtta veebisaidi esindajana esineva isikuga ja nõuda lisateavet .
Sellised tavad tõstatavad ka "kasutajanimede loendamise" ohu, mille käigus saab kontrollida kogu kasutajanimede või e-posti aadresside kogu olemasolu veebisaidil, tehes lihtsalt rühmapäringuid ja uurides neile antud vastuseid. Kas teil on kõigi töötajate e-posti aadresside loend ja mõni minut aega skripti kirjutamiseks? Siis näete, milles probleem!
Mis on alternatiiv? Tegelikult on see üsna lihtne ja seda on suurepäraselt rakendatud :
Siin ei avalda Entropay oma süsteemis e-posti aadressi olemasolu kohta üldse midagi. kellelegi, kellele see aadress ei kuulu... Kui sa oma seda aadressi ja seda süsteemis pole, siis saate sellise meili:
Muidugi võib olla vastuvõetavaid olukordi, kus keegi mõtlebmis on veebisaidil registreeritud. kuid see pole nii või tegi seda teiselt meiliaadressilt. Ülaltoodud näide käsitleb mõlemat olukorda edukalt. Kui aadress kattub, saate loomulikult meili, mis muudab parooli lähtestamise lihtsaks.
Entropay valitud lahenduse peensus seisneb selles, et identiteedi kontrolli teostab e-post enne mis tahes veebikontrolli. Mõned saidid küsivad kasutajatelt vastust turvaküsimusele (selle kohta leiate teavet allpool) kuni kuidas lähtestamine võib alata; Selle probleemiks on aga see, et küsimusele tuleb vastata, esitades samas mingisuguse identifitseerimisvormi (e-posti aadress või kasutajanimi), mis muudab intuitiivse vastamise peaaegu võimatuks ilma anonüümse kasutajakonto olemasolu paljastamata.
Selle lähenemisviisiga on olemas väike kasutatavuse vähenemine, sest olematu konto lähtestamise katse korral ei tule kohest tagasisidet. See on muidugi kogu meili saatmise mõte, aga tegeliku lõppkasutaja seisukohalt, kui ta sisestab vale aadressi, saab ta sellest esimest korda teada alles siis, kui kirja saab. See võib tekitada temas mõningaid pingeid, kuid see on nii haruldase protsessi eest väike hind.
Veel üks teemaväline märkus: sisselogimise abifunktsioonidel, mis näitavad õiget kasutajanime või e-posti aadressi, on sama probleem. Vastake kasutajale alati sõnumiga "Teie kasutajanime ja parooli kombinatsioon on kehtetu", selle asemel, et kinnitada sõnaselgelt isikuandmete olemasolu (näiteks "kasutajanimi on õige, kuid parool on vale").
Parooli lähtestamise saatmine vs lähtestamise URL-i saatmine
Järgmine kontseptsioon, mida peame arutama, on parooli lähtestamine. On kaks populaarset lahendust:
- Uue parooli genereerimine serveris ja selle saatmine meili teel
- Lähtestamisprotsessi hõlbustamiseks saatke kordumatu URL-iga meil
Vaatamata , ei tohiks esimest punkti kunagi kasutada. Tema probleem on selles, et see tähendab omamist salvestatud parool, kuhu saate igal ajal tagasi pöörduda ja uuesti kasutada; see edastati ebaturvalise kanali kaudu ja jääb teie postkasti. On võimalus, et postkastid sünkroonitakse mobiilseadmete ja meilikliendiga, lisaks saab neid veebipõhises meiliteenuses väga pikka aega võrgus hoida. Asi on selles postkasti ei saa pidada usaldusväärseks pikaajaliseks ladustamisvahendiks.
Kuid peale selle on esimesel punktil veel üks tõsine probleem – see lihtsustab nii palju kui võimalik konto blokeerimine pahatahtliku kavatsusega. Kui ma tean kellegi e-posti aadressi, kellel on veebisaidil konto, siis saan ta igal ajal blokeerida, lihtsalt lähtestades tema parooli. See on teenistusest keeldumise rünnak, mida serveeritakse hõbekandikul! Seetõttu tuleks lähtestada alles pärast taotleja õiguste edukat kontrollimist.
Kui räägime lähtestamise URL-ist, peame silmas veebisaidi aadressi, mis on ainulaadne selle lähtestamisprotsessi konkreetse juhtumi puhul. Muidugi peaks see olema juhuslik, seda ei tohiks olla lihtne ära arvata ja see ei tohiks sisaldada väliseid linke kontole, mis hõlbustaks lähtestamist. Näiteks lähtestamise URL ei tohiks olla lihtsalt tee nagu "Lähtesta/?kasutajanimi=JohnSmith".
Soovime luua kordumatu märgi, mille saab postitada lähtestatud URL-ina ja seejärel sobitada kasutaja konto serverikirjega, kinnitades nii, et konto omanik on tegelikult sama isik, kes üritab parooli lähtestada . Näiteks võib märgiks olla "3ce7854015cd38c862cb9e14a1ae552b" ja see salvestatakse tabelisse koos lähtestava kasutaja ID-ga ja loa genereerimise ajaga (sellest leiate lähemalt allpool). Meili saatmisel sisaldab see URL-i, näiteks "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b" ja kui kasutaja selle alla laadib, küsib leht märgi olemasolu, misjärel see kinnitab kasutaja teavet ja võimaldab tal muuta parool.
Muidugi, kuna ülaltoodud protsess (loodetavasti) võimaldab kasutajal luua uue parooli, peame loomulikult tagama, et URL laaditakse HTTPS-i kaudu. ei, , peab see loa URL kasutama transpordikihi turvalisust, et uut paroolivormi ei saaks rünnata ja kasutaja loodud parool edastati turvalise ühenduse kaudu.
Ka lähtestamise URL-i jaoks peate lisama loa ajalimiiti, et lähtestamisprotsess saaks teatud intervalli, näiteks tunni jooksul lõpule viia. See tagab, et lähtestamisaja aken on minimaalne, nii et lähtestamise URL-i saaja saab tegutseda ainult selles väga väikeses aknas. Loomulikult võib ründaja lähtestamisprotsessi uuesti alustada, kuid ta peab hankima uue unikaalse lähtestamise URL-i.
Lõpuks peame tagama, et see protsess on ühekordselt kasutatav. Kui lähtestamisprotsess on lõppenud, tuleb luba eemaldada, et lähtestamise URL enam ei töötaks. Eelmine punkt on vajalik tagamaks, et ründajal oleks väga väike aken, mille jooksul ta saab lähtestatud URL-iga manipuleerida. Peale selle, kui lähtestamine on edukas, pole märki enam muidugi vaja.
Mõned neist sammudest võivad tunduda üleliigsed, kuid need ei sega kasutatavust ja tegelikult parandada ohutust, kuigi olukordades, mis loodetavasti on haruldased. 99% juhtudest lubab kasutaja lähtestamise väga lühikese aja jooksul ega lähtesta parooli lähitulevikus uuesti.
CAPTCHA roll
Oh, CAPTCHA, turvafunktsioon, mida me kõik vihkame! Tegelikult pole CAPTCHA mitte niivõrd kaitsevahend, kuivõrd tuvastamise tööriist – olenemata sellest, kas olete inimene või robot (või automatiseeritud skript). Selle eesmärk on vältida vormide automaatset esitamist, mis loomulikult võib kasutada katsena turvalisust murda. Parooli lähtestamise kontekstis tähendab CAPTCHA, et lähtestamisfunktsiooni ei saa julmalt sundida kasutajale rämpsposti saatma või kontode olemasolu kindlaks tegema (mis pole muidugi võimalik, kui järgite jaotises identiteedi kontrollimine).
Muidugi pole CAPTCHA iseenesest täiuslik; selle programmiliseks "häkkimiseks" ja piisava edukuse (60-70%) saavutamiseks on palju pretsedente. Lisaks on minu postituses näidatud lahendus , kus saate maksta inimestele iga CAPTCHA lahendamise eest ja saada 94% õnnestumisprotsent inimestele. See tähendab, et see on haavatav, kuid tõstab (veidi) sisenemisbarjääri.
Vaatame PayPali näidet:
Sel juhul ei saa lähtestamisprotsess alata enne, kui CAPTCHA on lahendatud teoreetiliselt protsessi on võimatu automatiseerida. Teoorias.
Enamiku veebirakenduste puhul on see aga liialdatud ja täiesti õigus tähendab kasutatavuse vähenemist – inimestele lihtsalt ei meeldi CAPTCHA! Lisaks on CAPTCHA selline asi, mille juurde saab vajadusel lihtsalt tagasi pöörduda. Kui teenust hakatakse rünnama (logimine tuleb siin kasuks, aga sellest pikemalt hiljem), siis ei saaks CAPTCHA lisamine olla lihtsam.
Salajased küsimused ja vastused
Kõigi vaadeldud meetoditega saime parooli lähtestada, kui meil oli juurdepääs e-posti kontole. Ma ütlen "lihtsalt", aga loomulikult ebaseaduslikult kellegi teise meilikontole juurdepääsu saamine peaks olla keeruline protsess. Kuid .
Tegelikult on ülaltoodud link Sarah Palini Yahoo! teenib kahte eesmärki; esiteks illustreerib see, kui lihtne on (mõned) meilikontot häkkida, ja teiseks, kui halbu turvaküsimusi saab pahatahtlikult kasutada. Kuid me tuleme selle juurde hiljem tagasi.
XNUMX% meilist sõltuvate paroolide lähtestamise probleem seisneb selles, et lähtestatava saidi konto terviklikkus muutub XNUMX% sõltuvaks meilikonto terviklikkusest. Igaüks, kellel on juurdepääs teie e-postile on juurdepääs mis tahes kontole, mille saab lähtestada, saades lihtsalt meili. Selliste kontode jaoks on e-post teie võrguelu "kõigi uste võti".
Üks võimalus seda riski vähendada on turvaküsimuste ja vastuste mustri rakendamine. Kahtlemata olete neid juba näinud: valige küsimus, millele saate vastata ainult teie olema tead vastust, mille järel parooli lähtestamisel seda küsitakse. See lisab kindlustunnet, et lähtestamist prooviv inimene on tõepoolest konto omanik.
Tulles tagasi Sarah Palini juurde, oli viga selles, et vastuseid tema salaküsimusele/küsimustele oli lihtne leida. Eriti siis, kui olete nii suur avaliku elu tegelane, pole teave teie ema neiupõlvenime, kooliajaloo või kellegi minevikus elamise kohta sugugi nii saladus. Tegelikult võib enamiku sellest leida peaaegu igaüks. Saaraga juhtus nii:
Häkker David Kernell pääses Palini kontole juurde, leides tema taustaandmed, nagu keskkooli ja sünnikuupäeva, ning kasutades seejärel Yahoo!-i kadunud konto parooli taastamise funktsiooni.
See on peamiselt Yahoo! - Nii lihtsate küsimuste täpsustamisega saboteeris ettevõte sisuliselt salaküsimuse väärtust ja seega ka oma süsteemi kaitset. Muidugi on meilikonto paroolide lähtestamine alati keerulisem, kuna selle omandiõigust ei saa kinnitada, saates omanikule meili (ilma teist aadressi omamata), kuid õnneks pole sellisel süsteemil tänapäeval palju kasutusvõimalusi.
Tuleme tagasi turvaküsimuste juurde – on võimalus lubada kasutajal ise küsimusi koostada. Probleem on selles, et see toob kaasa kohutavalt ilmsed küsimused:
Mis värvi on taevas?
Küsimused, mis panevad inimesed ebamugavasse olukorda, kui turvaküsimuses kasutatakse tuvastamiseks salaküsimust inimene (näiteks kõnekeskuses):
Kellega ma jõulude ajal magasin?
Või ausalt öeldes rumalad küsimused:
Kuidas kirjutada "parool"?
Kui rääkida turvaküsimustest, tuleb kasutajaid enda eest päästa! Teisisõnu, turvaküsimuse peaks määrama sait ise või, mis veelgi parem, küsima seeria turvaküsimused, mille vahel kasutaja saab valida. Ja ära lihtsalt vali üks; ideaaljuhul peaks kasutaja valima kaks või enam turvaküsimust konto registreerimise ajal, mida seejärel kasutatakse teise identifitseerimiskanalina. Mitme küsimuse esitamine suurendab kindlustunnet kinnitamisprotsessi vastu ja annab ka võimaluse lisada juhuslikkust (mitte alati sama küsimust kuvada), lisaks annab veidi liiasust juhuks, kui tegelik kasutaja on parooli unustanud.
Milline peaks olema hea turvaküsimus? Seda mõjutavad mitmed tegurid:
- See peaks olema lühidalt Küsimus peaks olema selge ja ühemõtteline.
- Vastus peab olema spetsiifiline — me ei vaja küsimust, millele üks inimene saab erinevalt vastata
- Võimalikud vastused peaksid olema mitmekesine Kellegi lemmikvärvi küsimine annab väga väikese alamhulga võimalikest vastustest.
- Otsing vastus peab olema keeruline – kui vastus on kergesti leitav iga (mõelge kõrgel positsioonil olevatele inimestele), siis on ta halb
- Vastus peab olema püsiv ajas - kui küsida kellegi lemmikfilmi, siis aasta hiljem võib vastus olla teistsugune
Nagu juhtub, on headele küsimustele pühendatud veebisait nimega . Mõned küsimused tunduvad olevat üsna head, teised ebaõnnestuvad mõnes ülalkirjeldatud testis, eriti testis "lihtne leida".
Lubage mul näidata teile, kuidas turvaküsimusi PayPalis rakendatakse ja eriti seda, kui palju vaeva sait identifitseerimiseks teeb. Nägime ülal protsessi avalehte (CAPTCHA-ga) ja siin näitame, mis juhtub pärast oma e-posti aadressi sisestamist ja CAPTCHA lahendamist:
Selle tulemusena saab kasutaja järgmise meili:
Siiani on kõik normaalne, kuid selle lähtestamise URL-i taga on järgmine:
Seega tulevad mängu salaküsimused. Tegelikult võimaldab PayPal ka parooli lähtestada, kinnitades oma krediitkaardi numbri, nii et on olemas lisakanal, millele paljudel saitidel pole juurdepääsu. Ma lihtsalt ei saa oma parooli ilma vastamata muuta mõlemad salaküsimus (või kaardi numbri teadmata). Isegi kui keegi kaaperdab mu meili, ei saa ta oma PayPali konto parooli lähtestada, kui ta ei tea minu kohta veidi rohkem isiklikku teavet. Millist teavet? Siin on PayPali pakutavad turvaküsimuste võimalused:
Kooli- ja haiglaküsimus võib otsimise lihtsuse mõttes olla pisut segane, kuid teised pole väga halvad. Turvalisuse suurendamiseks nõuab PayPal aga täiendavat identifitseerimist muutused vastused turvaküsimustele:
PayPal on üsna utoopiline näide turvalisest parooli lähtestusest: see rakendab CAPTCHA-d, et vähendada jõhkrate jõurünnakute ohtu, nõuab kahte turvaküsimust ja seejärel nõuab teist tüüpi täiesti erinevat identifitseerimist lihtsalt vastuste muutmiseks – ja seda pärast kasutajat. on juba sisse loginud. Muidugi, see on täpselt see, mida me oodatud oleks PayPalist; on finantsasutus, mis tegeleb suurte rahasummadega. See ei tähenda, et iga parooli lähtestamine peab järgima neid samme – enamasti on see ülemäärane –, kuid see on hea näide juhtudel, kui turvalisus on tõsine äri.
Turvaküsimuste süsteemi mugavus seisneb selles, et kui te pole seda kohe juurutanud, saate selle hiljem lisada, kui ressursikaitse tase seda nõuab. Hea näide sellest on Apple, kes alles hiljuti selle mehhanismi juurutas [2012. aastal kirjutatud artikkel]. Kui hakkasin iPadis rakendust värskendama, nägin järgmist taotlust:
Siis nägin ekraani, kus sain valida mitu paari turvaküsimusi ja vastuseid ning pääste-e-posti aadressi:
PayPali osas on küsimused eelvalitud ja mõned neist on tegelikult üsna head:
Kõik kolm küsimuste/vastuste paari esindavad erinevat võimalike küsimuste komplekti, seega on konto seadistamiseks palju võimalusi.
Teine aspekt, mida turvaküsimusele vastamisel kaaluda, on salvestusruum. Lihtteksti andmebaasi omamine andmebaasis kujutab endast peaaegu samu ohte kui parool, nimelt paljastab andmebaasi väärtuse koheselt ja see seab ohtu mitte ainult rakenduse, vaid potentsiaalselt täiesti erinevad rakendused, mis kasutavad samu turvaküsimusi (seal jälle ). Üks võimalus on turvaline räsimine (tugev algoritm ja krüptograafiliselt juhuslik sool), kuid erinevalt enamikust paroolide salvestamise juhtudest võib vastuse ilmumisel lihttekstina olla hea põhjus. Tüüpiline stsenaarium on identiteedi kinnitamine reaalajas telefonioperaatori poolt. Muidugi on sel juhul rakendatav ka räsimine (operaator saab lihtsalt sisestada kliendi poolt nimetatud vastuse), kuid halvimal juhul peab salajane vastus olema krüptosalvestuse mingil tasemel, isegi kui tegemist on lihtsalt sümmeetrilise krüptimisega. Kokkuvõte: kohtle saladusi nagu saladusi!
Ja salaküsimuste ja vastuste viimane aspekt on see, et nad on sotsiaalse insenerluse suhtes haavatavamad. Otse kellegi teise konto parooli küsimine on üks asi, kuid tema hariduse teemal vestluse alustamine (populaarne salaküsimus) on täiesti erinev. Tegelikult on teil täiesti võimalik suhelda kellegagi tema elu paljude aspektide üle, mis võivad olla salajane küsimus, ja ilma kahtlust äratamata. Muidugi on salaküsimuse põhiolemus selles, et see on seotud kellegi elukogemusega, nii et see jääb meelde ja selles peitubki probleem - inimestele meeldib oma elukogemustest rääkida! Sellega saate teha vähe, ainult siis, kui valite sellised turvaküsimuse valikud, et need oleksid vähem Tõenäoliselt tõmbab selle välja sotsiaalne manipuleerimine.
[Jätkub.]Reklaamide õiguste kohta
VDSina pakub usaldusväärset , iga server on ühendatud 500-megabitise Interneti-kanaliga ja on tasuta kaitstud DDoS-i rünnakute eest!
Allikas: www.habr.com