Neseniai turėjau laiko dar kartą pagalvoti apie tai, kaip turėtų veikti saugaus slaptažodžio nustatymo iš naujo funkcija, pirmiausia, kai kūriau šią funkciją , o tada, kai jis padėjo kitam žmogui padaryti kažką panašaus. Antruoju atveju norėjau duoti jam nuorodą į kanoninį šaltinį su visa informacija, kaip saugiai įgyvendinti atkūrimo funkciją. Tačiau bėda ta, kad tokio šaltinio nėra, bent jau ne tokio, kuriame būtų aprašyta viskas, kas man atrodo svarbu. Taigi nusprendžiau parašyti pats.
Matote, pamirštų slaptažodžių pasaulis iš tikrųjų yra gana paslaptingas. Yra daug skirtingų, visiškai priimtinų požiūrių ir daug gana pavojingų. Tikėtina, kad su kiekvienu iš jų daug kartų susidūrėte kaip galutinis vartotojas; todėl pabandysiu naudoti šiuos pavyzdžius, kad parodyčiau, kas tai daro teisingai, kas ne ir į ką reikia sutelkti dėmesį, kad funkcija būtų tinkama jūsų programoje.
Slaptažodžio saugykla: maiša, šifravimas ir (gasp!) paprastas tekstas
Negalime aptarti, ką daryti su pamirštais slaptažodžiais, kol neaptariame, kaip juos saugoti. Slaptažodžiai duomenų bazėje saugomi vienu iš trijų pagrindinių tipų:
- Paprastas tekstas. Yra slaptažodžio stulpelis, kuris saugomas paprasto teksto forma.
- Šifruota. Paprastai naudojamas simetriškas šifravimas (vienas raktas naudojamas ir šifravimui, ir iššifravimui), o užšifruoti slaptažodžiai taip pat saugomi tame pačiame stulpelyje.
- Maiša. Vienpusis procesas (slaptažodis gali būti maišomas, bet negali būti panaikintas); Slaptažodis, Norėčiau tikėtis, po to yra druska ir kiekvienas yra savo stulpelyje.
Pereikime tiesiai prie paprasčiausio klausimo: Niekada nelaikykite slaptažodžių paprastu tekstu! Niekada. Vienintelis pažeidžiamumas , vienas neatsargus atsarginis kopijavimas arba viena iš dešimčių kitų paprastų klaidų – ir viskas, gameover, visi jūsų slaptažodžiai – tai yra, atsiprašau, visų savo klientų slaptažodžius taps viešąja nuosavybe. Žinoma, tai reikštų didžiulę tikimybę iš visų savo sąskaitų kitose sistemose. Ir tai bus jūsų kaltė.
Šifravimas yra geresnis, tačiau turi trūkumų. Šifravimo problema yra iššifravimas; galime paimti šiuos beprotiškai atrodančius šifrus ir konvertuoti juos atgal į paprastą tekstą, o kai taip atsitiks, grįšime prie žmogaus skaitomo slaptažodžio situacijos. Kaip tai atsitinka? Nedidelis trūkumas patenka į kodą, kuris iššifruoja slaptažodį ir padaro jį viešai prieinamą – tai vienas iš būdų. Įsilaužėliai gauna prieigą prie mašinos, kurioje saugomi užšifruoti duomenys – tai antras būdas. Kitas būdas vėlgi yra pavogti duomenų bazės atsarginę kopiją ir kažkas taip pat gauna šifravimo raktą, kuris dažnai yra labai nesaugiai saugomas.
Ir tai priveda prie maišos. Maišos idėja yra ta, kad ji yra vienpusė; vienintelis būdas palyginti vartotojo įvestą slaptažodį su maišos versija yra maišyti įvestį ir juos palyginti. Kad išvengtume tokių įrankių kaip vaivorykštės lentelės atakų, procesą pasūdome atsitiktinai (skaitykite mano apie kriptografinę saugyklą). Galiausiai, jei įdiegsite teisingai, galime būti tikri, kad slaptažodžiai su maiša niekada daugiau netaps paprastu tekstu (apie skirtingų maišos algoritmų naudą kalbėsiu kitame įraše).
Trumpas argumentas dėl maišos ir šifravimo: vienintelė priežastis, dėl kurios kada nors prireiktų šifruoti, o ne maišyti slaptažodį, yra tada, kai reikia matyti slaptažodį paprastu tekstu ir tu niekada neturėtum to norėti, bent jau standartinėje svetainės situacijoje. Jei jums to reikia, greičiausiai jūs darote kažką ne taip!
Dėmesio!
Žemiau įrašo tekste yra dalis pornografinės svetainės AlotPorn ekrano kopijos. Jis tvarkingai apkarpytas, todėl paplūdimyje nėra nieko, ko nepamatytumėte, bet jei vis tiek kyla problemų, neslinkite žemyn.
Visada iš naujo nustatykite slaptažodį niekada neprimink jam
Ar jūsų kada nors buvo paprašyta sukurti funkciją priminimus Slaptažodis? Ženkite žingsnį atgal ir pagalvokite apie šį prašymą atvirkščiai: kam reikalingas šis „priminimas“? Nes vartotojas pamiršo slaptažodį. Ką mes iš tikrųjų norime padaryti? Padėkite jam vėl prisijungti.
Suprantu, kad žodis „priminimas“ vartojamas (dažnai) šnekamąja prasme, bet mes iš tikrųjų stengiamės saugiai padėti vartotojui vėl prisijungti prie interneto. Kadangi mums reikia saugumo, yra dvi priežastys, kodėl priminimas (t. y. vartotojo slaptažodžio siuntimas) netinka:
- El. paštas yra nesaugus kanalas. Lygiai taip pat, kaip nesiunčiame nieko slapto per HTTP (naudotume HTTPS), neturėtume siųsti nieko jautraus el. paštu, nes jo transportavimo sluoksnis yra nesaugus. Tiesą sakant, tai yra daug blogiau, nei tiesiog siunčiant informaciją nesaugiu transportavimo protokolu, nes paštas dažnai yra saugomas atminties įrenginyje, pasiekiamas sistemos administratoriams, persiunčiamas ir platinamas, pasiekiamas kenkėjiškoms programoms ir pan. Nešifruotas el. paštas yra labai nesaugus kanalas.
- Bet kokiu atveju neturėtumėte turėti prieigos prie slaptažodžio. Dar kartą perskaitykite ankstesnį skyrių apie saugojimą – turėtumėte turėti slaptažodžio maišą (su stipria druska), tai reiškia, kad jokiu būdu negalėsite išgauti slaptažodžio ir išsiųsti jo paštu.
Leiskite man parodyti problemą pavyzdžiu : Čia yra įprastas prisijungimo puslapis:
Akivaizdu, kad pirmoji problema yra ta, kad prisijungimo puslapis neįkeliamas per HTTPS, tačiau svetainė taip pat ragina atsiųsti slaptažodį ("Siųsti slaptažodį"). Tai gali būti anksčiau minėto termino vartojimo šnekamojoje kalboje pavyzdys, todėl ženkime toliau ir pažiūrėkime, kas atsitiks:
Deja, atrodo ne ką geriau; ir el. laiškas patvirtina, kad yra problema:
Tai mums parodo du svarbius usoutdoor.com aspektus:
- Svetainėje nėra slaptažodžių maišos. Geriausiu atveju jie yra užšifruoti, tačiau tikėtina, kad jie saugomi paprastu tekstu; Nematome jokių priešingų įrodymų.
- Svetainė nesaugiu kanalu siunčia ilgalaikį slaptažodį (galime grįžti ir naudoti jį vėl ir vėl).
To nepadarius, turime patikrinti, ar atkūrimo procesas atliekamas saugiai. Pirmiausia reikia įsitikinti, kad užklausos teikėjas turi teisę atlikti atstatymą. Kitaip tariant, prieš tai mums reikia patikrinti tapatybę; pažiūrėkime, kas nutinka, kai tapatybė patvirtinama prieš tai nepatikrinus, kad užklausos pateikėjas iš tikrųjų yra paskyros savininkas.
Vartotojų vardų sąrašas ir jo įtaka anonimiškumui
Šią problemą geriausiai iliustruoja vizualiai. Problema:
Matote? Atkreipkite dėmesį į pranešimą „Šiuo el. pašto adresu nėra užsiregistravusio vartotojo“. Akivaizdu, kad problema kyla, jei tokia svetainė patvirtina prieinamumas tokiu el. pašto adresu užsiregistravęs naudotojas. Bingo – ką tik atradote savo vyro/boso/kaimyno pornografinį fetišą!
Žinoma, pornografija yra gana ikoniškas privatumo svarbos pavyzdys, tačiau pavojai, kylantys susiejant asmenį su konkrečia svetaine, yra daug platesni nei anksčiau aprašyta galimai nepatogi situacija. Vienas pavojus yra socialinė inžinerija; Jei užpuolikas gali suderinti asmenį su paslauga, jis turės informacijos, kurią galės pradėti naudoti. Pavyzdžiui, jis gali susisiekti su asmeniu, kuris prisistato svetainės atstovu, ir paprašyti papildomos informacijos, bandydamas įsipareigoti. .
Tokia praktika taip pat kelia „naudotojų vardų sąrašo“ pavojų, kai galima patikrinti, ar svetainėje yra visa vartotojų vardų ar el. pašto adresų kolekcija, tiesiog atliekant grupines užklausas ir išnagrinėjus atsakymus į juos. Ar turite visų darbuotojų el. pašto adresų sąrašą ir kelias minutes scenarijui parašyti? Tada pamatysite, kokia yra problema!
Kokia alternatyva? Tiesą sakant, tai gana paprasta ir puikiai įgyvendinta :
Čia Entropay visiškai nieko neatskleidžia apie el. pašto adreso egzistavimą savo sistemoje asmeniui, kuriam šis adresas nepriklauso... Jei tu savo šis adresas ir jo nėra sistemoje, tada gausite tokį el. laišką:
Žinoma, gali būti priimtinų situacijų, kai kas nors manokad užsiregistravote svetainėje. bet taip nėra arba aš tai padariau iš kito el. pašto adreso. Aukščiau pateiktas pavyzdys puikiai tinka abiem situacijoms. Akivaizdu, kad jei adresas sutaps, gausite el. laišką, kad būtų lengviau iš naujo nustatyti slaptažodį.
Entropay pasirinkto sprendimo subtilumas yra tas, kad identifikavimo patikrinimas atliekamas pagal laišką prieš bet kokį patikrinimą internetu. Kai kurios svetainės prašo vartotojų atsakyti į saugos klausimą (daugiau apie tai toliau) į kaip gali prasidėti atstatymas; tačiau problema yra ta, kad jūs turite atsakyti į klausimą kartu pateikdami tam tikrą identifikavimo formą (el. pašto adresą arba vartotojo vardą), todėl beveik neįmanoma atsakyti intuityviai, neatskleidžiant anoniminio vartotojo abonemento.
Su šiuo požiūriu yra mažas sumažėjęs naudojimo patogumas, nes jei bandysite iš naujo nustatyti neegzistuojančią paskyrą, iš karto negausite atsiliepimų. Žinoma, visa tai yra el. laiško siuntimo esmė, bet iš tikro galutinio vartotojo perspektyvos, jei jie įves neteisingą adresą, pirmą kartą sužinos tik gavę el. laišką. Tai gali sukelti tam tikrą įtampą iš jo pusės, tačiau tai yra nedidelė kaina už tokį retą procesą.
Kita pastaba, šiek tiek ne į temą: prisijungimo pagalbos funkcijos, atskleidžiančios, ar teisingas vartotojo vardas arba el. pašto adresas, turi tą pačią problemą. Visada atsakykite vartotojui pranešimu „Jūsų vartotojo vardo ir slaptažodžio derinys netinkamas“, o ne aiškiai patvirtindami kredencialų egzistavimą (pavyzdžiui, „vartotojo vardas teisingas, bet slaptažodis neteisingas“).
Slaptažodžio nustatymo iš naujo siuntimas ir atkūrimo URL siuntimas
Kita koncepcija, kurią turime aptarti, yra tai, kaip iš naujo nustatyti slaptažodį. Yra du populiarūs sprendimai:
- Naujo slaptažodžio generavimas serveryje ir išsiuntimas el
- Išsiųskite el. laišką su unikaliu URL, kad palengvintumėte nustatymo iš naujo procesą
Nepaisant , pirmasis taškas niekada neturėtų būti naudojamas. Problema ta, kad tai reiškia, kad yra išsaugotas slaptažodis, prie kurio galite grįžti ir vėl naudoti bet kuriuo metu; jis išsiųstas nesaugiu kanalu ir lieka gautuosiuose. Gali būti, kad gautieji yra sinchronizuojami mobiliuosiuose įrenginiuose ir el. pašto programoje, be to, jie gali būti saugomi internete žiniatinklio el. pašto tarnyboje labai ilgą laiką. Esmė ta pašto dėžutė negali būti laikoma patikima ilgalaikio saugojimo priemone.
Bet be to, pirmasis punktas turi dar vieną rimtą problemą – tai kiek įmanoma supaprastina paskyros blokavimas piktybiniais tikslais. Jei žinau asmens, kuriam priklauso paskyra svetainėje, el. pašto adresą, galiu bet kada jį užblokuoti tiesiog iš naujo nustatydamas slaptažodį; Tai atsisakymo teikti paslaugas ataka, patiekta ant sidabrinės lėkštės! Štai kodėl atkūrimas turėtų būti atliktas tik sėkmingai patikrinus prašytojo teises į jį.
Kai kalbame apie URL iš naujo nustatymą, turime omenyje svetainės adresą unikalus šiuo konkrečiu atkūrimo proceso atveju. Žinoma, ji turėtų būti atsitiktinė, nelengva atspėti ir jame neturėtų būti jokių išorinių nuorodų į paskyrą, kurios palengvintų nustatymą iš naujo. Pavyzdžiui, iš naujo nustatytas URL neturėtų būti tiesiog kelias, pvz., „Reset/?username=JohnSmith“.
Norime sukurti unikalų prieigos raktą, kuris gali būti išsiųstas kaip iš naujo nustatytas URL, o tada suderintas su vartotojo paskyros serverio įrašu, taip patvirtinant, kad paskyros savininkas iš tikrųjų yra tas pats asmuo, kuris bando iš naujo nustatyti slaptažodį . Pavyzdžiui, prieigos raktas gali būti „3ce7854015cd38c862cb9e14a1ae552b“ ir saugomas lentelėje kartu su atkūrimą atliekančio vartotojo ID ir prieigos rakto generavimo laiku (daugiau apie tai toliau). Kai siunčiamas el. laiškas, jame yra URL, pvz., „Reset/?id=3ce7854015cd38c862cb9e14a1ae552b“, o kai vartotojas jį atsisiunčia, puslapis paragina, ar yra prieigos raktas, o po to patvirtinama vartotojo informacija ir leidžiama pakeisti Slaptažodis.
Žinoma, kadangi aukščiau aprašytas procesas (tikiuosi) leidžia vartotojui sukurti naują slaptažodį, turime užtikrinti, kad URL būtų įkeltas per HTTPS. ne, , šis prieigos rakto URL turi naudoti transporto sluoksnio apsaugą, kad naujojo slaptažodžio forma nebūtų užpulta o vartotojo sukurtas slaptažodis buvo perduotas saugiu ryšiu.
Taip pat prie iš naujo nustatyto URL turite pridėti prieigos rakto laiko limitą, kad atstatymo procesą būtų galima užbaigti per tam tikrą intervalą, tarkime, per valandą. Taip užtikrinama, kad atkūrimo laiko langas būtų kuo trumpesnis, kad iš naujo nustatyto URL gavėjas galėtų veikti tik per tą labai mažą langą. Žinoma, užpuolikas gali vėl pradėti nustatymo iš naujo procesą, tačiau jam reikės gauti kitą unikalų iš naujo nustatymo URL.
Galiausiai turime užtikrinti, kad šis procesas būtų vienkartinis. Baigus nustatymo iš naujo procesą, prieigos raktas turi būti pašalintas, kad iš naujo nustatytas URL nebeveiktų. Ankstesnis punktas yra būtinas siekiant užtikrinti, kad užpuolikas turėtų labai mažą langą, per kurį jis galėtų manipuliuoti iš naujo nustatytu URL. Be to, žinoma, kai sėkmingas nustatymas iš naujo, prieigos raktas nebereikalingas.
Kai kurie iš šių veiksmų gali atrodyti pernelyg nereikalingi, tačiau jie netrukdo naudoti ir iš tikrųjų pagerinti saugumą, nors ir situacijose, kurių, tikimės, pasitaikys retai. 99% atvejų vartotojas įjungs atstatymą per labai trumpą laiką ir artimiausiu metu slaptažodžio iš naujo nenustatys.
CAPTCHA vaidmuo
O, CAPTCHA, saugos funkcija, kurios mes visi mėgstame nekenčiami! Tiesą sakant, CAPTCHA yra ne tiek apsaugos priemonė, kiek identifikavimo priemonė – nesvarbu, ar esate asmuo, ar robotas (ar automatizuotas scenarijus). Jos tikslas yra išvengti automatinio formų pateikimo, kuris, žinoma, galima būti naudojamas kaip bandymas pažeisti saugumą. Slaptažodžio nustatymo iš naujo kontekste CAPTCHA reiškia, kad nustatymo iš naujo funkcija negali būti žiauriai priversta siųsti vartotojui šlamšto arba bandyti nustatyti paskyrų egzistavimą (tai, žinoma, nebus įmanoma, jei laikysitės patarimo skyriuje apie tapatybės tikrinimas).
Žinoma, pati CAPTCHA nėra tobula; Yra daug precedentų dėl programinės įrangos „nulaužimo“ ir pakankamo sėkmės rodiklio (60–70%). Be to, yra sprendimas, parodytas mano įraše apie , kur galite sumokėti žmonėms cento dalis, kad išspręstumėte kiekvieną CAPTCHA ir pasiektumėte 94% sėkmės rodiklį. Tai yra, jis yra pažeidžiamas, bet (šiek tiek) padidina įėjimo barjerą.
Pažvelkime į PayPal pavyzdį:
Tokiu atveju atstatymo procesas tiesiog negali prasidėti, kol nebus išspręstas CAPTCHA teoriškai neįmanoma automatizuoti proceso. Teoriškai.
Tačiau daugumai žiniatinklio programų tai bus per daug visiškai teisus reiškia naudojimo patogumo sumažėjimą – žmonėms tiesiog nepatinka CAPTCHA! Be to, prireikus galite lengvai grįžti prie CAPTCHA. Jei paslauga pradeda būti užpulta (čia praverčia registracija, bet apie tai vėliau), pridėti CAPTCHA negali būti lengviau.
Slapti klausimai ir atsakymai
Naudodami visus svarstytus metodus, galėjome iš naujo nustatyti slaptažodį tiesiog turėdami prieigą prie el. pašto paskyros. Sakau „tiesiog“, bet, žinoma, prieiti prie kito asmens el. pašto paskyros yra neteisėta. turi būti sudėtingas procesas. Tačiau .
Tiesą sakant, aukščiau pateikta nuoroda apie įsilaužimą į Sarah Palin Yahoo! tarnauja dviem tikslams; pirma, tai iliustruoja, kaip lengva nulaužti (kai kurias) el. pašto paskyras, ir, antra, parodo, kaip blogi saugumo klausimai gali būti naudojami turint piktų kėslų. Bet prie to grįšime vėliau.
100 % slaptažodžio nustatymo el. paštu problema yra ta, kad svetainės, kurią bandote nustatyti iš naujo, paskyros vientisumas 100 % priklauso nuo el. pašto paskyros vientisumo. Visi, kurie turi prieigą prie jūsų el turi prieigą prie bet kurios paskyros, kurią galima iš naujo nustatyti tiesiog gavus el. laišką. Tokiose paskyrose el. paštas yra jūsų internetinio gyvenimo „raktas į visas duris“.
Vienas iš būdų sumažinti šią riziką – įdiegti saugos klausimų ir atsakymų šabloną. Be jokios abejonės, jūs juos jau matėte: pasirinkite klausimą, į kurį galite atsakyti tik jūs turėti žinosite atsakymą ir tada, kai iš naujo nustatysite slaptažodį, jūsų bus paprašyta jį įvesti. Tai padidina pasitikėjimą, kad asmuo, bandantis nustatyti iš naujo, iš tikrųjų yra paskyros savininkas.
Grįžti prie Saros Palin: klaida buvo ta, kad atsakymus į jos saugos klausimą/klausimus buvo galima lengvai rasti. Ypač kai esate toks reikšmingas visuomenės veikėjas, informacija apie savo motinos mergautinę pavardę, išsilavinimo istoriją arba apie tai, kur kas nors galėjo gyventi praeityje, nėra tokia paslaptis. Tiesą sakant, daugumą jo gali rasti beveik kiekvienas. Štai kas nutiko Sarai:
Įsilaužėlis Davidas Kernellas gavo prieigą prie Palin paskyros suradęs išsamią informaciją apie jos kilmę, pvz., universitetą ir gimimo datą, ir pasinaudojęs „Yahoo!“ pamiršto slaptažodžio atkūrimo funkcija.
Visų pirma, tai yra „Yahoo“ dizaino klaida! — nurodydama tokius paprastus klausimus, įmonė iš esmės sabotavo saugumo klausimo vertę, taigi ir savo sistemos apsaugą. Žinoma, iš naujo nustatyti el. pašto paskyros slaptažodžius visada yra sunkiau, nes negalite įrodyti nuosavybės teisės išsiųsdami savininkui el. laišką (neturėdami antro adreso), bet, laimei, šiandien tokios sistemos kūrimui nėra daug galimybių.
Grįžkime prie saugumo klausimų – yra galimybė leisti vartotojui susikurti savo klausimus. Problema ta, kad tai sukels siaubingai akivaizdžius klausimus:
Kokios spalvos yra dangus?
Klausimai, dėl kurių žmonės jaučiasi nepatogūs, kai tapatybei nustatyti naudojamas saugos klausimas asmuo (pavyzdžiui, skambučių centre):
Su kuo aš miegojau per Kalėdas?
Arba atvirai kvaili klausimai:
Kaip rašote žodį "slaptažodis"?
Kalbant apie saugumo klausimus, vartotojai turi būti apsaugoti nuo savęs! Kitaip tariant, saugumo klausimą turėtų nustatyti pati svetainė arba, dar geriau, užduoti serijos saugumo klausimai, iš kurių vartotojas gali pasirinkti. O išsirinkti nėra lengva vienas; idealiu atveju vartotojas turėtų pasirinkti du ar daugiau saugos klausimų sąskaitos registracijos metu, kuris vėliau bus naudojamas kaip antrasis identifikavimo kanalas. Keli klausimai padidina pasitikėjimą tikrinimo procesu, taip pat suteikia galimybę pridėti atsitiktinumo (ne visada rodomas tas pats klausimas), be to, suteikiama šiek tiek pertekliaus, jei tikrasis vartotojas pamirštų slaptažodį.
Kas yra geras saugumo klausimas? Tam įtakos turi keli veiksniai:
- Jis turi būti trumpai — klausimas turi būti aiškus ir nedviprasmiškas.
- Atsakymas turi būti specifinis – mums nereikia klausimo, į kurį vienas žmogus galėtų atsakyti skirtingai
- Galimi atsakymai turėtų būti įvairus - paklausus kieno nors mėgstamos spalvos, gaunamas labai mažas galimų atsakymų poaibis
- Paieška atsakymas turi būti sudėtingas – jei atsakymą galima lengvai rasti bet koks (prisimink aukštas pareigas einančius žmones), tada jis blogas
- Atsakymas turi būti nuolatinis laiku - jei paklausite kieno nors mėgstamo filmo, po metų atsakymas gali būti kitoks
Taip atsitinka, yra svetainė, skirta užduoti gerus klausimus . Kai kurie klausimai atrodo gana geri, kiti neišlaiko kai kurių aukščiau aprašytų testų, ypač „paieškos lengvumo“ testo.
Leiskite man parodyti, kaip PayPal įgyvendina saugos klausimus ir ypač pastangas, kurias svetainė įdeda autentifikavimui. Viršuje matėme puslapį, kad pradėtumėte procesą (su CAPTCHA), o čia parodysime, kas nutinka įvedus el. pašto adresą ir išsprendus CAPTCHA:
Dėl to vartotojas gauna tokį laišką:
Kol kas viskas yra gana įprasta, bet štai kas slepiasi po šiuo iš naujo nustatytu URL:
Taigi, iškyla saugumo klausimai. Tiesą sakant, „PayPal“ taip pat leidžia iš naujo nustatyti slaptažodį patvirtinant kredito kortelės numerį, todėl yra papildomas kanalas, prie kurio daugelis svetainių neturi prieigos. Tiesiog negaliu pakeisti slaptažodžio neatsakęs abu saugumo klausimas (arba kortelės numerio nežinojimas). Net jei kas nors užgrobtų mano el. paštą, negalėtų iš naujo nustatyti mano „PayPal“ paskyros slaptažodžio, nebent žinotų šiek tiek daugiau asmeninės informacijos apie mane. Kokia informacija? Štai „PayPal“ siūlomos saugos klausimų parinktys:
Klausimas apie mokyklą ir ligoninę gali būti šiek tiek sudėtingas dėl paieškos lengvumo, bet kiti nėra labai blogi. Tačiau norint padidinti saugumą, PayPal reikalauja papildomos tapatybės nustatymo pokyčiai atsakymai į saugumo klausimus:
„PayPal“ yra gana utopinis saugaus slaptažodžio nustatymo iš naujo pavyzdys: jis įdiegia CAPTCHA, kad sumažintų žiaurios jėgos atakų pavojų, reikalauja dviejų saugos klausimų, o tada reikalauja visiškai kitokio identifikavimo, kad tik pakeistų atsakymus – ir tai po to, kai vartotojas jau prisijungė. Žinoma, būtent tai mes tikimasi iš PayPal; yra finansų įstaiga, prekiaujanti didelėmis pinigų sumomis. Tai nereiškia, kad kiekvieną kartą nustatant slaptažodį iš naujo reikia atlikti šiuos veiksmus (dažniausiai tai yra per daug), tačiau tai yra geras pavyzdys tais atvejais, kai saugumas yra rimtas reikalas.
Saugos klausimų sistemos patogumas yra tas, kad jei jos neįdiegėte iš karto, galite ją pridėti vėliau, jei to reikalauja išteklių apsaugos lygis. Puikus to pavyzdys yra Apple, kuri tik neseniai įdiegė šį mechanizmą [straipsnis parašytas 2012 m.]. Kai pradėjau atnaujinti programą savo iPad, pamačiau šią užklausą:
Tada pamačiau ekraną, kuriame galėjau pasirinkti kelias saugos klausimų ir atsakymų poras, taip pat gelbėjimo el. pašto adresą:
Kalbant apie PayPal, klausimai yra iš anksto pasirinkti ir kai kurie iš jų yra gana geri:
Kiekviena iš trijų klausimų ir atsakymų porų atspindi skirtingą galimų klausimų rinkinį, todėl yra daug būdų, kaip sukonfigūruoti paskyrą.
Kitas aspektas, į kurį reikia atsižvelgti atsakant į saugos klausimą, yra saugojimas. Paprasto teksto duomenų bazės turėjimas duomenų bazėje kelia beveik tokias pačias grėsmes kaip ir slaptažodis, būtent, kad atskleidžiant duomenų bazę akimirksniu atskleidžiama jos vertė ir kyla pavojus ne tik programai, bet ir potencialiai visiškai skirtingoms programoms, naudojančioms tuos pačius saugos klausimus (vėl ). Viena iš parinkčių yra saugus maišymas (stiprus algoritmas ir kriptografiškai atsitiktinė druska), tačiau, skirtingai nei dauguma slaptažodžių saugojimo atvejų, atsakymas gali būti matomas kaip paprastas tekstas. Įprastas scenarijus yra tapatybės patvirtinimas, kurį atlieka tiesioginis telefono operatorius. Žinoma, šiuo atveju taikoma ir maiša (operatorius gali tiesiog įvesti kliento įvardytą atsakymą), tačiau blogiausiu atveju slaptas atsakymas turi būti tam tikrame kriptografinės saugyklos lygyje, net jei tai tik simetriškas šifravimas. . Apibendrinti: elkis su paslaptimis kaip su paslaptimis!
Paskutinis saugumo klausimų ir atsakymų aspektas yra tai, kad jie yra labiau pažeidžiami socialinės inžinerijos. Bandymas tiesiogiai išgauti slaptažodį kažkieno paskyroje yra vienas dalykas, tačiau pradėti pokalbį apie jo formavimą (populiarus saugumo klausimas) yra visiškai kas kita. Tiesą sakant, jūs galite labai gerai bendrauti su kuo nors apie daugelį jo gyvenimo aspektų, kurie gali sukelti slaptą klausimą, nesukeldami įtarimo. Žinoma, pati saugumo klausimo esmė yra ta, kad jis yra susijęs su kažkieno gyvenimo patirtimi, todėl yra įsimintinas, ir čia slypi problema. žmonės mėgsta kalbėti apie savo gyvenimo patirtį! Mažai ką galite padaryti, tik jei pasirinksite tokias saugumo klausimų parinktis, kad jos būtų tokios mažiau tikriausiai galėtų būti ištrauktas naudojant socialinę inžineriją.
[Tęsinys.]Dėl reklamos teisių
VDSina siūlo patikimus , kiekvienas serveris yra prijungtas prie 500 megabitų interneto kanalo ir yra apsaugotas nuo DDoS atakų nemokamai!
Šaltinis: www.habr.com