Recentemente am avut timp să mă gândesc din nou la modul în care ar trebui să funcționeze funcția de resetare a parolei, mai întâi când am integrat această funcționalitate în , și apoi când am ajutat pe altcineva să facă ceva similar. În al doilea caz, am vrut să-i ofer un link către o resursă canonică cu toate detaliile implementării sigure a funcției de resetare a parolei. Totuși, problema este că nu există o astfel de resursă, cel puțin nu una care să descrie tot ce mi se pare important. Așa că am hotărât să o scriu eu însumi.
Vezi tu, lumea parolelor uitate este, de fapt, destul de misterioasă. Există multe puncte de vedere diferite, absolut acceptabile, și o grămadă de opinii destul de periculoase. Există șanse mari să te fi confruntat cu fiecare dintre ele ca utilizator final; așa că voi încerca să folosesc aceste exemple pentru a arăta cine face totul bine și cine nu, precum și pe ce ar trebui să ne concentrăm pentru o implementare corectă a funcției în aplicația ta.
Stocarea parolelor: hash, criptare și (oh!) text simplu
Nu putem discuta despre ce să facem cu parolele uitate înainte de a discuta despre modul în care sunt stocate. În baza de date, parolele sunt stocate într-una dintre cele trei forme principale:
- Text simplu. Există o coloană cu parola, care este stocată în text obișnuit.
- Criptat. De obicei, folosind criptare simetrică (o singură cheie este utilizată atât pentru criptare, cât și pentru decriptare), iar parolele criptate sunt, de asemenea, stocate într-o singură coloană.
- Hashat. Un proces unidirecțional (parola poate fi hashată, dar nu poate fi dehashată); parola, ne-ar plăcea să sperăm, este însoțită de un salt, iar fiecare dintre ele se află într-o coloană proprie.
Să clarificăm de la bun început cea mai simplă întrebare: nu stocați niciodată parole în text simplu! Niciodată. O singură vulnerabilitate la , o copie de rezervă făcută fără atenție sau una dintre zecile de alte greșeli simple — și gata, jocul s-a terminat, toate parolele tale — adică, scuză-mă, parolele tuturor clienților tăi vor deveni publice. Evident, aceasta va însemna o mare probabilitate că vor deveni publice de la toate conturile lor din alte sisteme. Și aceasta va fi vina ta.
Criptarea este mai bună, dar are slăbiciunile ei. Problema criptării este decriptarea; se pot lua aceste criptări care par nebunești și transforma înapoi în text simplu, iar când asta se întâmplă, ne întoarcem la situația cu parolele lizibile. Cum se întâmplă asta? O mică eroare pătrunde în codul care se ocupă de decriptarea parolei, făcând-o accesibilă publicului — acesta este un mod. Hackerii obțin acces la mașina care stochează datele criptate — acesta este un al doilea mod. O altă metodă este, din nou, faptul că se fură o copie de rezervă a bazei de date, iar cineva primește, de asemenea, cheia de criptare, care este adesea stocată foarte nesigur.
Și aceasta ne duce la hash-ing. Ideea hash-ului este că acesta se execută într-o singură direcție; singura modalitate de a compara parola introdusă de utilizator cu versiunea sa hash-uită este prin hash-ing-ul celei introduse și compararea acestora. Pentru a preveni atacurile cu instrumente precum „tabelele rainbow”, adăugăm un element de randomizare în proces cu ajutorul unui salt (pentru o imagine completă, citiți postarea mea despre stocarea criptografică). În cele din urmă, cu o implementare corectă, putem considera cu un grad mare de încredere că parolele hash-uite nu vor mai deveni niciodată text simplu (despre avantajele diferitelor algoritmi de hash-ing voi vorbi într-o altă postare).
Un argument succint privind hash-ingul și criptarea: singurul motiv pentru care va trebui vreodată să criptati, și nu să hash-ati, o parolă este când aveți nevoie să vedeți parola în text simplu, iar acest lucru nu ar trebui să fie dorința dumneavoastră, cel puțin în situația unui site web standard. Dacă aveți nevoie de asta, cel mai probabil faceți ceva greșit!
Atenție!
Mai jos în textul postării există o parte dintr-un screenshot al unui site web pornografic, AlotPorn. Acesta a fost tăiat cu grijă, iar nu este nimic care să nu poată fi văzut pe plajă, dar dacă asta ar putea provoca probleme, atunci nu derulați pagina în jos.
Resetati întotdeauna parola, niciodată nu o reamintiți
Ați fost vreodată rugați să creați o funcție de reamintire parola? Faceți un pas înapoi și gândiți-vă la această cerere dintr-o perspectivă inversă: de ce avem nevoie de această „reamintire”? Pentru că utilizatorul a uitat parola. Ce vrem, de fapt, să facem? Să-l ajutăm să intre din nou în sistem.
Înțeleg că termenul „reamintire” este folosit (adesea) în sens colocvial, dar, de fapt, încercăm să ajutăm utilizatorul să fie din nou online în siguranță.. Deoarece ne pasă de securitate, există două motive pentru care reamintirea (adică, trimiterea parolei utilizatorului) nu este o opțiune:
- Email-ul este un canal nesigur. La fel cum nu am transmite nimic confidențial prin HTTP (am folosi HTTPS), nu ar trebui să trimitem nimic prin email, deoarece stratul de transport nu este sigur. De fapt, este mult mai rău decât simpla transmitere a informațiilor printr-un protocol de transport nesecurizat, deoarece email-urile sunt adesea stocate pe un dispozitiv, accesibile administratorilor sistemului, retrimise și distribuite, disponibile pentru malware și așa mai departe. Email-ul necriptat este un canal extrem de nesigur.
- Nu ar trebui, în niciun caz, să aveți acces la parola. Citiți din nou secțiunea precedentă despre stocare — ar trebui să aveți un hash al parolei (cu un salt bun), adică nu ar trebui să aveți în niciun fel posibilitatea să extrageți parola și să o trimiteți prin email.
Permiteți-mi să demonstrez problema cu un exemplu : Iată o pagină tipică de autentificare:
Este evident că prima problemă este că pagina de autentificare nu se încarcă prin HTTPS, dar site-ul oferă, de asemenea, opțiunea de a trimite parola („Send Password”). Poate că acesta este un exemplu al utilizării colocviale menționate mai sus, așa că haideți să facem încă un pas și să vedem ce se întâmplă:
Din nefericire, nu arată mult mai bine; iar email-ul confirmă existența problemei:
Acest lucru ne spune două aspecte importante despre usoutdoor.com:
- Site-ul nu hash-uiește parolele. În cel mai bun caz, acestea sunt criptate, dar este foarte probabil ca acestea să fie stocate în text simplu; nu vedem dovezi în sensul opus.
- Site-ul trimite o parolă pe termen lung (putem reveni și să o folosim din nou și din nou) printr-un canal nesecurizat.
După ce ne-am ocupat de asta, trebuie să verificăm dacă procesul de resetare se desfășoară în siguranță. În primul rând, trebuie să ne asigurăm că solicitantul are dreptul de a efectua resetarea. Cu alte cuvinte, avem nevoie de o verificare a identității înainte; să vedem ce se întâmplă când identitatea este confirmată fără verificarea prealabilă că solicitantul este, într-adevăr, proprietarul contului.
Enumerarea numelui de utilizator și impactul său asupra anonimității
Această problemă este mai bine ilustrată vizual. Problema:
Vedeți? Acordați atenție mesajului „There is no user registered with this email address” („Nu există utilizator înregistrat cu această adresă de email”). Problema apare evident dacă un astfel de site confirmă existența unui utilizator înregistrat cu această adresă de email. Bingo - tocmai ați descoperit fetișul porno al soțului / șefului / vecinului dvs.!
Desigur, pornografia este un exemplu destul de canonic al importanței confidențialității, însă pericolul asocierii unei identități cu un anumit site este mult mai extins decât situația potențial inconfortabilă descrisă mai sus. Unul dintre pericole este ingineria socială; dacă un atacator poate asocia o persoană cu un serviciu, acesta va avea informații pe care le poate folosi. De exemplu, ar putea contacta persoana pretinzând că este un reprezentant al site-ului și ar putea solicita informații suplimentare, încercând să comită .
Astfel de practici pot genera pericolul „enumerării numelui de utilizator”, în care se poate verifica existența pe un site a unei colecții întregi de nume de utilizator sau adrese de email prin interogări simple în grupuri și studierea răspunsurilor acestora. Aveți o listă de adrese de email pentru toți angajații și câteva minute disponibile pentru a scrie un script? Atunci vedeți în ce constă problema!
Care este alternativa? De fapt, este destul de simplă și realizată minunat la :
Aici Entropay nu dezvăluie absolut nimic despre existența adresei de email în sistemul său pentru cineva care nu deține această adresă. Dacă dumneavoastră dețineți această adresă și nu există în sistem, veți primi un e-mail de acest tip:
Desigur, există situații acceptabile în care cineva crede, că s-a înregistrat pe website. dar nu este așa, sau a făcut-o de la o altă adresă de e-mail. Exemplul de mai sus se descurcă bine în ambele situații. Evident, dacă adresa se potrivește, veți primi un e-mail care simplifică resetarea parolei.
Subtilitatea soluției Entropay alese este că verificarea identității se face prin e-mail înainte de orice verificare online. Unele site-uri cer utilizatorilor să răspundă la o întrebare secretă (mai multe despre asta mai jos) la înainte ca resetarea să poată începe; cu toate acestea, problema acestuia este că trebuie să răspundeți la întrebare, oferind în același timp o formă de identificare (e-mail sau nume de utilizator), ceea ce face aproape imposibil să răspundeți într-un mod intuitiv, fără a dezvălui existența unei conturi anonime.
Cu această abordare există o ușoară reducere a utilizabilității, deoarece în cazul în care se încearcă resetarea unui cont inexistent, nu există un feedback imediat. Desigur, acesta este întregul scop al trimiterii unui e-mail, dar din perspectiva utilizatorului final, dacă introduce o adresă greșită, va afla despre aceasta abia când primește e-mailul. Acest lucru poate provoca unele tensiuni din partea lui, dar este un preț mic de plătit pentru un proces atât de rar.
O altă observație, care se abate puțin de la subiect: funcțiile de ajutor pentru conectarea la sistem, care dezvăluie corectitudinea numelui de utilizator sau adresei de e-mail, au aceeași problemă. Întotdeauna răspundeți utilizatorului cu mesajul „Combinația numelui de utilizator și a parolei este invalidă” (Combinația utilizatorului și a parolei este invalidă), și nu confirmați explicit existența informațiilor de identificare (de exemplu, „numele de utilizator este corect, dar parola este greșită”).
Trimiterea parolei de resetare versus trimiterea URL-ului de resetare
Următoarea concept pe care trebuie să o discutăm se leagă de modul de resetare a parolei. Există două soluții populare:
- Generarea unei noi parole pe server și trimiterea acesteia prin e-mail
- Trimiterea unui e-mail cu un URL unic care simplifică procesul de resetare
Cu toate acestea, , primul punct nu ar trebui să fie niciodată folosit. Problema acestuia este că înseamnă că există o parolă stocată, la care se poate reveni și folosi din nou în orice moment; a fost transmis printr-un canal nesecurizat și rămâne în căsuțele dvs. de intrare. Există riscul ca mesajele primite să se sincronizeze cu dispozitivele mobile și clientul de e-mail, plus că ele pot fi stocate online într-un serviciu de e-mail pentru o perioadă foarte lungă de timp. Ideea este că căsuța de e-mail nu poate fi considerată un mijloc sigur pentru păstrarea pe termen lung.
Dar, pe lângă asta, primul punct mai are o problemă serioasă - acesta simplifică la maxim blocarea contului cu intenții rele. Dacă știu adresa de e-mail a celui care deține contul pe un site web, pot să-l blochez în orice moment, doar resetând parola; aceasta este un atac de tip «refuz de serviciu», servit pe un platou cu margine albastră! De aceea, resetarea ar trebui să se efectueze doar după o verificare reușită a dreptului inițiatorului de a o solicita.
Când vorbim despre URL-ul de resetare, ne referim la adresa site-ului web care este unică pentru acest proces specific de resetare. Desigur, aceasta trebuie să fie aleatorie, să nu fie ușor de ghicit și să nu conțină linkuri externe către cont, care să faciliteze resetarea. De exemplu, URL-ul de resetare nu ar trebui să fie doar un traseu de genul «Reset/?username=JohnSmith».
Vrem să creăm un token unic, care poate fi trimis prin e-mail ca URL de resetare, iar apoi să-l comparăm cu înregistrarea de pe server cu contul utilizatorului, confirmând astfel că deținătorul contului este într-adevăr aceeași persoană care încearcă să reseteze parola. De exemplu, tokenul poate arăta ca «3ce7854015cd38c862cb9e14a1ae552b» și să fie stocat într-un tabel împreună cu ID-ul utilizatorului care realizează resetarea și timpul generării tokenului (mai multe detalii despre asta mai târziu). La trimiterea e-mailului, acesta conține un URL de genul «Reset/?id=3ce7854015cd38c862cb9e14a1ae552b», iar când utilizatorul îl accesează, pagina verifică existența tokenului, apoi confirmă informațiile utilizatorului și permite schimbarea parolei.
Desigur, deoarece procesul descris mai sus (sper să) permite utilizatorului să creeze o nouă parolă, este necesar să se garanteze încărcarea URL-ului prin HTTPS. Nu, , acest URL cu token-ul trebuie să utilizeze securitatea stratului de transport, pentru a preveni atacurile asupra formularului de introducere a noii parole. și parola creată de utilizator să fie transmisă printr-o conexiune protejată.
De asemenea, pentru URL-ul de resetare, trebuie să adăugăm o limită de timp pentru token, astfel încât procesul de resetare să poată fi finalizat într-un anumit interval, de exemplu, în decurs de o oră. Acest lucru garantează că fereastra de timp pentru resetare va fi minimă, astfel încât cel care primește acest URL de resetare să poată acționa doar în această fereastră foarte mică. Desigur, un atacator poate relua procesul de resetare, dar va avea nevoie să primească un alt URL unic de resetare.
În cele din urmă, trebuie să ne asigurăm că acest proces este o singură utilizare. După finalizarea procesului de resetare, token-ul trebuie eliminat, astfel încât URL-ul de resetare să nu mai funcționeze. Punctul anterior este necesar pentru a oferi atacatorului o fereastră foarte mică de timp în care poate manipula URL-ul de resetare. În plus, desigur, după finalizarea cu succes a resetării, token-ul nu mai este necesar.
Unele dintre aceste etape pot părea excesive, dar ele nu afectează deloc ușurința de utilizare și de fapt îmbunătățesc securitatea, deși în situații care, sperăm, vor fi rare. În 99% din cazuri, utilizatorul va apela la resetare într-un interval foarte scurt de timp și nu va mai reseta parola în viitorul apropiat.
Rolul CAPTCHA
Oh, CAPTCHA, instrumentul de protecție pe care toți îl iubim să-l urâm! De fapt, CAPTCHA este un instrument nu atât de protecție, cât de identificare — ești om sau robot (sau script automatizat). Scopul său este să evite trimiterea automată a formularelor, care, desigur, poate poate fi o încercare de a sparge securitatea. În contextul resetării parolelor, CAPTCHA înseamnă că funcția de resetare nu poate fi spartă prin forță brută, pentru a spama utilizatorul sau pentru a încerca să determine existența conturilor (ceea ce, desigur, va fi imposibil, dacă ai urmat sfaturile din secțiunea despre verificarea identității).
Desigur, CAPTCHA în sine nu este perfectă; există numeroase exemple de „spargere” software și rate de succes suficient de mari (60-70%). În plus, există o soluție, prezentată în postul meu despre , unde se pot plăti oameni câțiva cenți pentru a rezolva fiecare CAPTCHA și a obține o rată de succes de 94%. Așadar, este vulnerabilă, însă (puțin) ridică bariera de intrare.
Să ne uităm la exemplul PayPal:
În acest caz, procesul de resetare nu poate începe până la rezolvarea CAPTCHA, așa că teoretic automatizarea procesului este imposibilă. Teoretic.
Cu toate acestea, pentru majoritatea aplicațiilor web, aceasta ar fi o exagerare și cu siguranță reprezintă o scădere a utilizabilității — oamenii pur și simplu nu iubesc CAPTCHA! În plus, CAPTCHA este ceva la care se poate reveni cu ușurință, dacă este necesar. Dacă serviciul începe să fie atacat (aici este util logging-ul, dar despre asta mai târziu), atunci adăugarea CAPTCHA-ului nu este deloc complicată.
Întrebări și răspunsuri secrete
În toate modurile discutate, am putut reseta parola, având doar acces la contul de e-mail. Spun „doar”, dar, desigur, obținerea ilegală a accesului la contul de e-mail al altcuiva ar trebui să fie un proces complicat. Cu toate acestea .
De fapt, linkul de mai sus despre spartul contului Sarey Palin pe Yahoo! servește două scopuri; mai întâi, ilustrează cât de ușor pot fi sparte (unele) conturi de e-mail, și, în al doilea rând, arată cum pot fi folosite rău întrebările secrete proaste. Dar vom reveni la asta mai târziu.
Problema cu resetarea parolelor care depind 100% de e-mail este că integritatea contului site-ului, parola căruia încerci să o resetezi, devine complet dependentă de integritatea contului de e-mail. Oricine are acces la e-mailul tău, are acces la orice cont care poate fi resetat pur și simplu prin primirea unui e-mail. Pentru astfel de conturi, e-mailul este „ cheia tuturor ușilor” din viața ta online.
Una dintre modalitățile de a reduce acest risc este implementarea unui model de întrebare și răspuns secret. Fără îndoială, ați văzut deja aceste întrebări: alegeți o întrebare la care doar dumneavoastră ar trebui să știți răspunsul, după care, la resetarea parolei, vi se pune acea întrebare. Aceasta adaugă un anumit nivel de siguranță că persoana care încearcă să efectueze resetarea este, într-adevăr, proprietarul contului.
Să ne întoarcem la Sarah Palin: greșeala a fost că răspunsurile la întrebarea/întrebările ei secretă erau ușor de găsit. În special, atunci când ești o figură publică atât de semnificativă, informațiile despre numele de familie al mamei, istoricul școlar sau despre unde a locuit cineva în trecut nu sunt chiar așa de secrete. De fapt, o mare parte din acestea pot fi găsite aproape de oricine. Așa s-a întâmplat și în cazul lui Sarah:
Hackerul David Kernell a accesat contul lui Palin găsind detalii despre biografia ei, cum ar fi universitatea și data nașterii, iar apoi a folosit funcția de recuperare a parolelor uitate pentru conturile Yahoo!.
În primul rând, aceasta este o greșeală de proiectare din partea Yahoo! — prin alegerea unor întrebări atât de simple, compania a sabotat practic valoarea întrebării secrete și, astfel, protecția sistemului său. Desigur, resetarea parolelor pentru un cont de e-mail este întotdeauna mai complicată, căci nu poți confirma proprietatea sa trimițând un e-mail proprietarului (fără a avea o a doua adresă), dar, din fericire, astăzi nu există atât de multe modalități de a crea un astfel de sistem.
Să ne întoarcem la întrebările secrete — există opțiunea de a oferi utilizatorului posibilitatea de a crea propriile sale întrebări. Problema este că, în acest fel, vor apărea întrebări extrem de evidente:
De ce culoare este cerul?
Întrebările care îi pun pe oameni în dificultate, atunci când pentru identificare întrebația secretă folosește o persoană (de exemplu, într-un call center):
Cu cine am avut o relație în ziua de Crăciun?
Sau întrebări complet stupide:
Cum se scrie „parola”?
Când vine vorba de întrebările secrete, utilizatorii trebuie salvați de ei înșiși! Cu alte cuvinte, întrebarea secretă ar trebui să fie determinată de site-ul însuși, și, mai bine, să pună o serie de întrebări secrete din care utilizatorul poate alege. Și nu doar să aleagă una; ideal ar fi ca utilizatorul să aleagă două sau mai multe întrebări secrete în momentul în care își crează contul, care ulterior vor fi utilizate ca a doua canal de identificare. Prezența mai multor întrebări crește gradul de încredere în procesul de verificare și oferă, de asemenea, oportunitatea de a adăuga elemente de aleatoriu (fără a afișa întotdeauna aceeași întrebare), plus asigură o oarecare redundanță în cazul în care utilizatorul real a uitat parola.
Ce ar trebui să fie o întrebare secretă bună? Acest lucru depinde de mai mulți factori:
- Ea ar trebui să fie scurtă — întrebarea trebuie să fie clară și neambiguă.
- Răspunsul trebuie să fie specific — nu avem nevoie de o întrebare la care o persoană poate răspunde diferit.
- Răspunsurile posibile ar trebui să fie variabile — întrebarea despre culoarea preferată a cuiva oferă un subset foarte mic de răspunsuri posibile.
- Căutarea răspunsului trebuie să fie dificilă — dacă răspunsul poate fi găsit cu ușurință oricine (să ne reamintim de persoanele aflate în funcții înalte), atunci este o întrebare proastă.
- Răspunsul trebuie să fie permanentă în timp — dacă întrebăm despre filmul preferat al cuiva, atunci după un an răspunsul poate fi diferit.
Se dovedește că există un site web dedicat întrebărilor bune, numit . Unele dintre întrebări par a fi destul de bune, altele nu trec parte din testele de mai sus, în special controlul "simplicității căutării".
Permiteți-mi să demonstrez cum sunt implementate întrebările secrete în PayPal și, în special, ce eforturi face site-ul pentru identificare. Mai sus am văzut pagina de început a procesului (cu CAPTCHA), iar aici vom arăta ce se întâmplă după ce introduceți adresa de email și rezolvați CAPTCHA:
Ca rezultat, utilizatorul primește un astfel de email:
Până acum totul este destul de obișnuit, dar iată ce se află în spatele acestui URL de resetare:
Așadar, intervin întrebările secrete. De fapt, PayPal permite, de asemenea, resetarea parolei prin confirmarea numărului cardului de credit, deci există un canal suplimentar, accesibil nu multor site-uri. Pur și simplu nu pot schimba parola fără a răspunde la ambele întrebări secrete (sau fără a ști numărul cardului). Chiar și dacă cineva îmi confiscă emailul, acesta nu va putea să reseteze parola contului PayPal dacă nu știe despre mine puțin mai multe informații personale. Ce informații? Iată opțiunile de întrebări secrete oferite de PayPal:
Întrebarea despre școală și spital poate fi puțin ambiguă din punctul de vedere al ușurinței de căutare, dar celelalte nu sunt atât de rele. Cu toate acestea, pentru a crește securitatea, PayPal solicită o identificare suplimentară pentru modificări răspunsurile la întrebările secrete:
PayPal este un exemplu destul de ideal de resetare a parolei în siguranță: implementează CAPTCHA pentru a diminua riscurile de atacuri prin forță brută, cere două întrebări secrete, apoi necesită un alt tip complet diferit de identificare doar pentru a schimba răspunsurile - și asta după ce utilizatorul s-a autentificat deja. Evident, exact asta ne-am așteptat de la PayPal; este o organizație financiară care lucrează cu sume mari de bani. Acest lucru nu înseamnă că fiecare resetare a parolei ar trebui să urmeze acești pași - în cele mai multe cazuri, este o exagerare - cu toate acestea, este un bun exemplu pentru situațiile în care securitatea este o afacere serioasă.
Conveniența sistemului de întrebări secrete este că, dacă nu l-ai implementat imediat, îl poți adăuga mai târziu, dacă așa impune nivelul de protecție al resursei. Un bun exemplu în acest sens este Apple, care a implementat recent acest mecanism [articol scris în 2012]. Odată ce am început să updatez aplicația pe iPad, am văzut următoarea solicitare:
Apoi am văzut un ecran în care puteam alege mai multe perechi de întrebări secrete și răspunsuri, precum și o adresă de email de recuperare:
În ceea ce privește PayPal, întrebările sunt selectate dinainte și unele dintre ele sunt de fapt destul de bune:
Fiecare dintre cele trei perechi de întrebări și răspunsuri reprezintă un set distinct de întrebări posibile, deci există suficiente modalități de configurare a contului.
Un alt aspect de luat în considerare în ceea ce privește răspunsul la întrebarea secretă este stocarea. A avea un text simplu în Bază de Date prezintă aproape aceleași amenințări ca în cazul parolei, și anume - o divulgare a bazei de date expune instantaneu valoarea și pune în pericol nu doar aplicația, ci și potențial alte aplicații care utilizează aceleași întrebări secrete (asta este din nou ). O una dintre variante este hashing-ul sigur (un algoritm rezistent și un salt criptografic aleator), însă, spre deosebire de majoritatea cazurilor de stocare a parolelor, există un motiv întemeiat pentru vizibilitatea răspunsului ca text simplu. Un scenariu tipic este verificarea identității de către un operator în direct prin telefon. Bineînțeles, și în acest caz hashing-ul este aplicabil (operatorul poate introduce pur și simplu răspunsul menționat de client), dar în cel mai rău caz, răspunsul secret ar trebui să se afle la un anumit nivel de stocare criptografică, chiar dacă este vorba doar de criptare simetrică. Să concluzionăm: tratează secretele ca secrete!
Și ultimul aspect al întrebărilor și răspunsurilor secrete – acestea sunt mai vulnerabile la ingineria socială. A încerca să obții direct parola unui alt cont este un lucru, dar a iniția o discuție despre educația sa (o întrebare secretă populară) este complet diferit. De fapt, este destul de posibil să comunici cu cineva despre multe aspecte ale vieții sale care ar putea reprezenta o întrebare secretă, fără a trezi suspiciuni. Bineînțeles, esența întrebării secrete este că aceasta este legată de experiența de viață a cuiva, așa că este memorabilă, iar tocmai aceasta este problema – oamenii iubesc să vorbească despre experiențele lor de viață! Cu asta nu se poate face prea multe, decât dacă alegi astfel de opțiuni de întrebări secrete, încât acestea să aibă o mai mică probabilitate de a fi extrase prin inginerie socială.
[Continuarea urmează.]
În numele publicității
VDSina oferă servere fiabile , fiecare server fiind conectat la un canal de internet de 500 Megabiți și protejat gratuit împotriva atacurilor DDoS!
Sursa: habr.com
