Nemrég volt időm újra elgondolkodni azon, hogyan kellene működnie a biztonságos jelszóvisszaállító funkciónak, először, amikor ezt a funkciót beépítettem a , majd amikor segítettem egy másik embernek hasonlót készíteni. A második esetben szerettem volna neki egy hivatkozást adni egy kanonikus forrásra, amelyben minden részlet található a biztonságos jelszóvisszaállítás megvalósításáról. Azonban a probléma az, hogy ilyen forrás nem létezik, legalábbis olyan, amely mindent leír, amit fontosnak tartok. Ezért úgy döntöttem, hogy én magam írom meg.
Látja, a feledésbe merült jelszavak világa valójában meglehetősen rejtélyes. Számos különböző, teljesen elfogadható nézőpont létezik, és egy csomó meglehetősen veszélyes is. Valószínű, hogy mindegyikkel többször találkoztál mint végfelhasználó; ezért megpróbálom kihasználni ezeket a példákat, hogy megmutassam, ki csinálja jól, és ki nem, és mire kell fókuszálni a funkció megfelelő megvalósításához az alkalmazásában.
Jelszavak tárolása: hashelés, titkosítás és (jaj!) sima szöveg
Nem beszélhetünk arról, hogy mit tegyünk a feledésbe merült jelszavakkal, mielőtt nem beszélünk a tárolás módjáról. Az adatbázisban a jelszavak a három fő típus egyikében vannak tárolva:
- Sima szöveg. Van egy oszlop a jelszóval, ami sima szövegként van tárolva.
- Titkosított. Általában szimmetrikus titkosítással (ugyanazt a kulcsot használják a titkosításhoz és a visszafejtéshez), a titkosított jelszavak is egy oszlopban vannak tárolva.
- Hash-elt. Egyszerű folyamat (a jelszót hash-elhetjük, de nem lehet visszafejteni); a jelszó, remélhetőleg, sóval van kiegészítve, és mindkettő saját oszlopban van.
Kezdjük azzal, hogy tisztázzuk a legegyszerűbb kérdést: soha ne tároljon jelszavakat sima szövegben! Soha. Egyetlen egy sebezhetőség a , egy meggondolatlanul végrehajtott biztonsági másolat vagy egy tucat más egyszerű hiba — és vége, game over, az összes jelszava — azaz, bocsánat, tudja, az összes ügyfelének a jelszava közkinccsé válik. Természetesen ez hatalmas kockázata lesz, hogy közkinccsé válik minden más rendszerben lévő fiókjukhoz. És ez a te felelősséged lesz.
A titkosítás jobb, de vannak gyenge pontjai. A titkosítás problémája a visszafejtés; ezeket az őrült módon kinéző titkosításokat vissza lehet alakítani sima szöveggé, és amikor ez megtörténik, újra visszatérünk a könnyen olvasható jelszavak helyzetéhez. Hogyan történik ez? Egy kis hiba behatol a jelszó visszafejtéséért felelős kódba, így az nyilvánosan hozzáférhetővé válik – ez az egyik mód. A második mód, hogy a hackerek hozzáférnek ahhoz a géphez, ahol a titkosított adatok tárolódnak. Egy másik mód pedig az, hogy ellopnak egy adatbázis biztonsági másolatot, és valaki megszerzi a titkosításhoz szükséges kulcsot, amelyeket gyakran nagyon megbízhatatlanul tárolnak.
Ez elvezet minket a hashinghez. A hashing lényege, hogy egyirányú; az egyetlen mód, hogy a felhasználó által megadott jelszót összehasonlítsuk a hash-elt változatával, az, hogy a megadott jelszót hash-eljük, és összehasonlítjuk. Az "özönlési táblák"-kal való támadások elkerülése érdekében sót adunk a folyamatba, hogy véletlenszerűséget biztosítsunk (a teljes képhez olvassa el a kriptográfiai tárolásról szóló bejegyzésemet). A lényeg az, hogy helyes megvalósítás mellett nagy valószínűséggel azt mondhatjuk, hogy a hash-elt jelszavak soha többé nem válnak sima szöveggé (a különböző hashing algoritmusok előnyeiről egy másik posztban fogok beszélni).
Rövid érvelés a hashing és titkosítás között: az egyetlen ok, amiért valaha is szükség lenne jelszót titkosítani, és nem hash-olni, az az, amikor látni szeretné a jelszót sima szöveg formájában, és ezt soha nem szabadene akarnia,legalábbis egy szokásos weboldalon. Ha erre szükség van, valószínűleg valamit rosszul csinál!
Figyelem!
A poszt szövegének alján van egy részlet a pornográf weboldalról, az AlotPornról. Szépen levágva van, és semmi ilyesmi nem látható egy strandon, de ha ez mégis problémákat okozhat, akkor ne görgessen lejjebb az oldalon.
Mindig állítsa vissza a jelszót, soha ne emlékeztesse rá.
Kértek már valaha, hogy készítsen egy emlékeztető funkciót? Jelszó? Lépjen vissza egy lépést, és gondolkodjon el ezen a kérésen az ellenkező irányból: miért van szükség erre az „emlékeztetőre”? Mert a felhasználó elfelejtette a jelszót. Mit szeretnénk valójában tenni? Segíteni neki, hogy újra belépjen a rendszerbe.
Megértem, hogy a „figyelmeztetés” szót (gyakran) a köznyelvben használják, de valójában megpróbálunk biztonságosan segíteni a felhasználónak, hogy újra online legyen. Mivel biztonságra van szükségünk, két ok van, amiért az emlékeztető (vagyis a felhasználó jelszavának elküldése) nem megfelelő:
- Az e-mail egy nem biztonságos csatorna. Ahogyan nem küldenénk bizalmas információt HTTP-n (HTTPS-t használnánk), nem szabad semmit e-mailben elküldeni, mert a szállítási réteg nem biztonságos. Valójában ez sokkal rosszabb, mint egyszerű információt küldeni egy nem védett szállítási protokollon, mert az e-mailek gyakran tárolódnak, hozzáférhetőek a rendszergazdák számára, továbbítva és terjesztve vannak, elérhetők a kártékony szoftverek számára és így tovább. A titkosítatlan e-mail rendkívül nem biztonságos csatorna.
- Önnek egyébként sem szabadna hozzáférnie a jelszóhoz. Olvassa el a korábbi részt a tárolásról – önnek jelszóméretnek (jó sóval) kell lennie, ami azt jelenti, hogy semmilyen módon nem szabadna kinyernie a jelszót és elküldenie e-mailben.
Engedje meg, hogy bemutassam a problémát egy példán keresztül : Itt van egy tipikus bejelentkezési oldal:
Nyilvánvalóan az első probléma az, hogy a bejelentkezési oldal nem HTTPS-en töltődik be, de a webhely másokat is felajánl, hogy küldjön jelszót („Send Password”). Talán ez a fent említett kifejezés köznyelvi alkalmazásának példája, ezért lépjünk egyet tovább és nézzük meg, mi történik:
Sajnos nem néz ki sokkal jobban; a jövedelmezőség pedig megerősíti a problémát:
Ez két fontos szempontot mond el nekünk a usoutdoor.com-ról:
- A webhely nem hash-eli a jelszavakat. Legjobb esetben titkosítják őket, de valószínű, hogy szöveges formában tárolják őket; bizonyítékot a fordítottjára nem látunk.
- A webhely egy tartós jelszót küld (visszatérhetünk és újra és újra használhatjuk) egy nem védett csatornán.
Miután ezzel tisztában vagyunk, ellenőriznünk kell, hogy a visszaállítási folyamat biztonságos módon történik-e. Először is meg kell győződnünk arról, hogy a kérelmező jogosult a visszaállítás elvégzésére. Más szóval, szükség van egy azonosítási ellenőrzésre; nézzük meg, mi történik, amikor a személyazonosságot megerősítik anélkül, hogy előzetesen ellenőriznénk, hogy a kérelmező valóban a fiók tulajdonosa.
A felhasználónevek felsorolása és annak hatása az anonimitásra
Ez a problémát a legjobban vizuálisan illusztrálni. Probléma:
Látja? Figyeljen a "There is no user registered with this email address" ("A megadott email címmel nincs regisztrált felhasználó.") üzenetre. A probléma nyilvánvalóan akkor merül fel, ha ilyen weboldal megerősíti létezik a megadott email címmel regisztrált felhasználó létezését. Bingo – éppen most fedezted fel a férjed/főnököd/szomszédod pornográf fétisét!
Természetesen a pornográfia egy elég klasszikus példa a magánélet fontosságára, azonban a személyazonosság és egy adott weboldal összekapcsolásának veszélye jóval szélesebb, mint a fent említett potenciálisan kellemetlen helyzet. Az egyik veszély a társadalmi manipuláció; ha a támadó képes összekapcsolni egy embert a szolgáltatással, olyan információkhoz jut, amelyeket felhasználhat. Például felveheti a kapcsolatot az illetővel, felhívva magára a weboldal képviselőjének a figyelmét, és további információt kérhet, próbálva megvalósítani a .
Az ilyen gyakorlatok lehetőséget adnak a "felhasználónevek felsorolásának" veszélyére is, ahol egyszerű csoportos lekérdezésekkel ellenőrizhető, hogy léteznek-e felhasználónevek vagy email címek egy weboldalon. Van egy email cím lista az összes alkalmazottról, és pár perced egy script írására? Akkor látod, mi a probléma!
Mi a helyettesítő megoldás? Valójában ez meglehetősen egyszerű, és remekül van kivitelezve a :
Itt az Entropay teljesen semmit nem árul el a rendszerében lévő email cím létezéséről annak, aki nem rendelkezik ezzel az email címmel.Ha te rendelkezel ha a cím nem létezik a rendszerben, akkor egy hasonló e-mailt fog kapni:
Természetesen vannak olyan elfogadható helyzetek, amikor valaki úgy gondolja, hogy regisztrált a weboldalon. de ez nem így van, vagy ezt egy másik e-mail címmel tette. A fenti példa mindkét helyzetet sikeresen kezeli. Nyilvánvaló, hogy ha az e-mail cím megegyezik, akkor egy olyan üzenetet kap, amely megkönnyíti a jelszó visszaállítását.
A választott Entropay megoldás finomsága, hogy az azonosítás ellenőrzése e-mailben történik mielőtt bármilyen online ellenőrzés megtörténne. Néhány weboldal a felhasználóktól megkérdezi a titkos kérdésre adott választ (erről lentebb részletesebben) tól azt illetően, hogy hogyan kezdődhet el a visszaállítás; azonban ennek az a problémája, hogy a kérdés megválaszolásához valamilyen típusú azonosítást (e-mail vagy felhasználónév) kell biztosítani, amiért majdnem lehetetlen intuitív módon válaszolni, anélkül, hogy felfednénk egy névtelen felhasználói fiók létezését.
Ezzel a megközelítéssel kis használhatósági csökkenés áll fenn, mivel egy nem létező fiók visszaállításának megkísérlésekor nincs azonnali visszajelzés. Nyilvánvaló, hogy ennek az üzenetnek a küldése a lényeg, de a tényleges végfelhasználó szempontjából, ha helytelen címet ad meg, akkor csak akkor értesül erről, amikor megkapja az e-mailt. Ez bizonyos feszültséget okozhat a részéről, de ez kis ár egy ilyen ritka folyamatért.
Még egy megjegyzés, ami kissé eltér a témától: a bejelentkezési segédletek, amelyek megerősítik a felhasználónév vagy e-mail cím helyességét, ugyanazzal a problémával küzdenek. Mindig reagáljon a felhasználónak az "Felhasználónév és jelszó kombinációja érvénytelen" üzenettel, ahelyett, hogy egyértelműen megerősítené az azonosító információk létezését (például "a felhasználónév helyes, de a megadott jelszó helytelen").
A jelszó visszaállítás küldése az e-mailben lévő URL küldésével szemben
A következő elképzelés, amelyet meg kell beszélnünk, a jelszó visszaállításának módjára vonatkozik. Két népszerű megoldás létezik:
- Új jelszó generálása a szerveren és annak elküldése e-mailben
- E-mail küldése egy egyedi URL-lal, amely megkönnyíti a visszaállítási folyamatot
Ahelyett, hogy , az első lépést soha nem szabad használni. A probléma az, hogy ez a lépés meglévő jelszót jelent, amelyhez bármikor vissza lehet térni és újra használni; ez egy védtelen csatornán került átadásra, és a beérkező leveleid között marad. Van esély arra, hogy a beérkező levelek szinkronizálva legyenek mobil eszközökkel és az e-mail klienssel, plusz hosszú ideig tárolhatók online az e-mail szolgáltató webes szolgáltatásában. Az a lényeg, hogy az e-mail fiók nem tekinthető megbízható eszköznek a hosszú távú tárolásra.
De ezen kívül az első lépésnek van még egy komoly problémája - ez maximálisan leegyszerűsíti a fiók szándékos blokkolását. Ha tudom annak a weboldalon lévő fióknak a tulajdonosának az e-mail címét, akkor bármikor blokkolhatom, csak annyit kell tennem, hogy visszaállítom a jelszavát; ez egy úgynevezett "szolgáltatásmegtagadási" támadás, ami tálcán kínálkozik! Ezért a visszaállítást csak akkor szabad végrehajtani, ha a kérelmező jogát sikeresen ellenőrizték.
Amikor a visszaállítási URL-ről beszélünk, akkor egy weboldalcímet értünk, amely e folyamat egyedi, konkrét esetére vonatkozik. Nyilvánvaló, hogy véletlenszerűnek kell lennie, nem szabad könnyen kitalálható jelleggel bírnia, és nem szabad külső hivatkozásokat tartalmaznia a fiókra, amelyek megkönnyítik a visszaállítást. Például a visszaállítási URL-nek nem szabad olyan egyszerűnek lennie, mint mondjuk "Reset/?username=JohnSmith".
Egy egyedi tokent szeretnénk létrehozni, amelyet e-mailben URL-ként lehet majd elküldeni a visszaállításhoz, majd ezt a tokent az adatbázisban egybevetjük a felhasználói fiókról, így megerősítve, hogy a fiók tulajdonosa valóban ugyanaz a személy, aki megpróbálja visszaállítani a jelszót. Például a token kinézhet úgy, mint "3ce7854015cd38c862cb9e14a1ae552b" és tárolható egy táblázatban a visszaállítást végző felhasználó azonosítójával és a token létrehozásának időpontjával (erről részletesebben lentebb). Az elküldött levél tartalmaz egy URL-t, mint például "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", és amikor a felhasználó betölti, az oldal ellenőrzi a token létezését, majd megerősíti a felhasználói információt és lehetővé teszi a jelszó megváltoztatását.
Természetesen, mivel a fent leírt folyamat (remélhetőleg) lehetővé teszi a felhasználó számára, hogy új jelszót hozzon létre, biztosítani kell az URL HTTPS-en keresztüli betöltését. Nem, , ennek az URL-nek a tokennel biztonságos szállítási réteget kell használnia, hogy az új jelszó beíró formot ne lehessen támadni és a felhasználó által létrehozott jelszó védett kapcsolaton keresztül kerüljön átadásra.
A visszaállító URL-hez időbeli korlátot is hozzá kell adni a tokenhez, hogy a visszaállítási folyamatot egy bizonyos időkereten belül, mondjuk egy órán belül lehessen végrehajtani. Ez biztosítja, hogy a visszaállítási időablak a lehető legkisebb legyen, így a megkapott visszaállító URL-t csak ebben az apró időkeretben lehet felhasználni. Természetesen a támadó újra elindíthatja a visszaállítási folyamatot, de szüksége lesz egy új egyedi visszaállító URL-re.
Végül, biztosítani kell, hogy ez a folyamat egyszer használatos legyen. A visszaállítási folyamat befejezése után a tokent el kell távolítani, hogy a visszaállító URL már ne működjön. Az előző pont arra szolgál, hogy a támadónak nagyon rövid időablaka legyen, amíg manipulálhatja a visszaállító URL-t. Ráadásul, természetesen, a sikeres visszaállítás befejezése után a tokenre már nincs szükség.
Néhány ezek közül a lépések közül talán túlzásnak tűnik, de teljesen nem befolyásolják a használhatóságot és valóban növelik a biztonságot, még ha olyan helyzetekben, amelyek remélhetőleg ritkák lesznek is. A felhasználók 99%-a nagyon rövid időn belül fogja a visszaállítást használni, és nem fogja a jelszót újra visszaállítani a közeljövőben.
A CAPTCHA szerepe
Ó, CAPTCHA, az a védelmi eszköz, amit mindannyian imádunk gyűlölni! A valóságban a CAPTCHA nem annyira védelem, mint inkább az azonosítás eszköze - ember vagy robot (vagy automatizált szkript) vagy. A célja, hogy megakadályozza az automatikus űrlapbeküldést, amely természetesen képes próbálkozás a védelem feltörésére. A jelszó visszaállítása során a CAPTCHA azt jelenti, hogy a visszaállítás funkciót nem lehet brute force támadással feltörni, amivel esetleg spammelni lehet a felhasználót, vagy megpróbálni meghatározni a fiókok létezését (ami természetesen lehetetlen, ha követted az azonosítási ellenőrzésről szóló tanácsokat).
Természetesen magában a CAPTCHA nem tökéletes; számos példa van a szoftveres "feltörésére" és a megfelelő sikerességi mutatók elérésére (60-70%). Ezenkívül van egy megoldás, amelyről a posztomban írtam , ahol embereknek centes részeket lehet fizetni minden egyes CAPTCHA megoldásáért, és 94%-os sikerességi mutatót lehet elérni. Vagyis védtelen, de (kissé) megemeli a belépési küszöböt.
Nézzük meg a PayPal példáját:
Ebben az esetben a jelszó visszaállítási folyamat egyszerűen nem kezdődhet el a CAPTCHA megoldása előtt, tehát elméletileg a folyamat automatizálása lehetetlen. Elméletileg.
A legtöbb webalkalmazás esetén azonban ez túlságosan drága lehet, és határozottan a használhatóság csökkenését jelenti — az emberek egyszerűen nem kedvelik a CAPTCHA-t! Ezenkívül a CAPTCHA egy olyan dolog, amire szükség esetén könnyen visszatérhetünk. Ha a szolgáltatás támadás alá kerül (itt jól jön a naplózás, de erről később), akkor a CAPTCHA hozzáadása a legegyszerűbb.
Titkos kérdések és válaszok
Az összes általunk megvizsgált módszerrel képesek voltunk jelszót visszaállítani, csak az e-mail fiókhoz való hozzáféréssel. Azt mondom, hogy "csak", de természetesen illegálisan hozzáférni más e-mail fiókjához maximálisan a kívánt pozícióhoz kellene igazodnia. nehéz folyamat lehet. Azonban .
Valójában a fenti hivatkozás Sarah Palin Yahoo! fiókjának feltöréséről két célt szolgál; egyrészt illusztrálja, mennyire egyszerű (néhány) e-mail fiók feltörése, másrészt megmutatja, hogyan lehet rosszindulatúan használni a gyenge titkos kérdéseket. De erről később visszatérünk.
A jelszavak visszaállításának problémája, amely teljes mértékben az e-mailtől függ, abban rejlik, hogy a webhely fiókjának integritása, amelyhez a jelszót próbálja visszaállítani, teljes mértékben függ az e-mail fiók integritásától. Aki hozzáfér az e-mail fiókjához, hozzáfér bármely fiókhoz, amelyet egyszerű e-mail küldéssel vissza lehet állítani. Az ilyen fiókok esetében az e-mail "kulcs minden ajtóhoz" az online életében.
Az egyik módja ennek a kockázatnak a csökkentésére a titkos kérdés és válasz mintázat megvalósítása. Kétségtelen, hogy már láttad őket: kiválasztasz egy kérdést, aminek csak te kell tudnod a válaszát, majd a jelszó visszaállításakor kérdezik. Ez növeli az önbizalmat abban, hogy az illető, aki megpróbálja visszaállítani, valóban a fiók tulajdonosa.
Térjünk vissza Sarah Palinra: a hiba az volt, hogy a titkos kérdés/rejtett válaszai könnyen megtalálhatók voltak. Különösen, ha olyan fontos közéleti személy vagy, az anyád leánykori neve, a tanulmányi előzményeid vagy az, hogy valaki hol élt a múltban, nem igazán titkos. Valójában, a nagy részük szinte bárki számára hozzáférhető. Így történt Sarah esetében is:
David Kernell hacker hozzáfért Palin fiókjához, megtalálva életrajzi részleteit, például az egyetemét és a születési dátumát, majd felhasználva a Yahoo! fiókok jelszóemlékeztető funkcióját.
Elsősorban ez a Yahoo! tervezési hibája – azzal, hogy ilyen egyszerű kérdéseket adott meg, valójában aláásta a titkos kérdés értékét, tehát a rendszer védekezését is. Természetesen a jelszó visszaállítása egy e-mail fiók esetében mindig nehezebb, hiszen nem tudod megerősíteni a birtoklását, ha nem küldesz az illetőnek e-mailt (másik cím híján), de szerencsére ma már nem sok lehetőség van ilyen rendszer létrehozására.
Térjünk vissza a titkos kérdésekhez – van lehetőség arra, hogy a felhasználó saját kérdéseket alkothasson. A probléma az, hogy ez borzasztóan nyilvánvaló kérdéseket eredményez:
Milyen színű az ég?
Azok a kérdések, amelyek kényelmetlen helyzetbe hozzák az embereket, amikor a titkos kérdés a kutatás (például a call centerben) használják:
Kivel feküdtem le karácsonykor?
Vagy nyíltan buta kérdések:
Hogyan írják, hogy "jelszó"?
Ha titkos kérdésekről van szó, meg kell menteni a felhasználókat önmaguktól! Más szóval, a titkos kérdést magának a webhelynek kell meghatároznia, és még jobb lenne, ha sorozatot titkos kérdéseket adna meg, amelyekből a felhasználó választhat. Nem csak egyet ; ideális esetben a felhasználónak két vagy több titkos kérdést kellene választaniaa fiók regisztrációja során. a fiók regisztrálásakor, amelyek második azonosítási csatornaként szolgálnak. A több kérdés megléte növeli a megerősítés megbízhatóságát, és lehetőséget ad a véletlenszerűség hozzáadására (nem mindig ugyanazt a kérdést feltenni), emellett egy kis redundanciát is biztosít, ha az igazi felhasználó elfelejti a jelszót.
Milyennek kell lennie egy jó titkos kérdésnek? Ezt több tényező befolyásolja:
- Rövidnek kell lennie — a kérdésnek világosnak és egyértelműnek kell lennie. A válasznak konkrétnak kell lennie
- — nem akarunk olyan kérdést, amelyre egy ember különböző válaszokat adhat. A lehetséges válaszoknak változatosnak kell lenniük — a kérdés valakinek a kedvenc színéről nagyon kicsi válaszhalmazt ad.
- A válasz keresésének nehéznek kell lennie — ha a választ bárki könnyen megtalálhatja (gondoljunk csak a magas rangú emberekre), akkor az nem jó. Állandónak kell lennie az időben — ha valaki kedvenc filmjéről kérdezünk, akkor egy év múlva a válasz eltérő lehet.
- Mint mindig, létezik egy weboldal, amely a jó kérdésekkel foglalkozik, és amelynek neve GoodSecurityQuestions.com . Néhány kérdés teljesen elég jónak tűnik, mások pedig nem teljesítik a fent említett teszteket, különösen a "keresés egyszerűsége" ellenőrzését. Engedje meg, hogy bemutassam, hogyan valósulnak meg a titkos kérdések a PayPal-ban, és különösen, hogy milyen erőfeszítéseket tesz a weboldal az azonosítás érdekében. Az előbb láttuk a folyamat kezdeti oldalát (CAPTCHA-val), itt pedig megmutatjuk, hogy mi történik, miután megadja az email címét és megoldja a CAPTCHA-t:
- — nem akarunk olyan kérdést, amelyre egy ember különböző válaszokat adhat. Ennek eredményeként a felhasználó egy ilyen levelet kap: Ez eddig még teljesen normális, de íme, mi rejlik ennek a jelszó-visszaállító URL-nek a hátterében:
Szóval, itt jönnek a titkos kérdések. Valójában a PayPal lehetőséget ad a jelszó visszaállítására a hitelkártya számának megerősítésével is, ezért van egy újabb csatorna, amelyhez sok weboldal nem fér hozzá. Egyszerűen nem tudom megváltoztatni a jelszót, ha nem válaszolok titkos kérdésre (vagy nem tudom a kártya számát). Még akkor is, ha valaki megszerzi az email címemet, nem tudja visszaállítani a PayPal fiók jelszavát, hacsak nem tud rólam egy kicsit több személyes információt. Milyen információról van szó? Íme a PayPal által kínált titkos kérdések lehetőségei:
Engedje meg, hogy bemutassam, hogyan valósulnak meg a titkos kérdések a PayPal-nál, és különösen, hogy milyen erőfeszítéseket tesz az oldal a felhasználó azonosítására. Az előzőekben láttuk a folyamat kezdeti oldalát (CAPTCHA-val), és itt megmutatjuk, mi történik, miután megadja az e-mail címét és megoldja a CAPTCHA-t:
Ennek eredményeként a felhasználó egy ilyen levelet kap:
Ez eddig egészen szokványos, de mi rejlik a jelszó-visszaállító URL mögött:
Tehát megjelennek a titkos kérdések. Valójában a PayPal lehetővé teszi a jelszó visszaállítását a hitelkártya számának megerősítésével is, ezért van egy további csatorna, amelyhez sok webhely nem fér hozzá. Csak nem tudom megváltoztatni a jelszót, anélkül hogy válaszolnék a mindkét titkos kérdésre (vagy ne tudnám a kártya számát). Még ha valaki el is kapja az e-mailem, nem tudja visszaállítani a PayPal-fiók jelszavát, ha nem tud rólam egy kicsit több személyes információt. Milyen információkról van szó? Íme a PayPal által kínált titkos kérdések lehetőségei:
Az iskola és a kórház kérdése kissé kérdéses lehet a keresés egyszerűsége szempontjából, de a többi nem annyira rossz. Azonban a PayPal a biztonság növelése érdekében további azonosítást kér. változások a titkos kérdések megválaszolásához:
A PayPal egy elég utópisztikus példa a biztonságos jelszó-visszaállításra: CAPTCHA-t alkalmaz a brute force támadások kockázatának csökkentésére, két titkos kérdést kér, majd egy teljesen másik azonosító formát is megkövetel csak a válaszok megváltoztatásához — és mindezek után, hogy a felhasználó már bejelentkezett. Ez éppen az, amire számítottunk. Vártuk. A PayPal tőképpen ezt várnánk egy olyan pénzügyi szervezettől, amely nagy összegekkel dolgozik. Ez nem jelenti azt, hogy minden jelszó-visszaállításnak ezen a lépésein kellene átmennie — a legtöbb esetben ez túllépés — de ez egy jó példa azokra az esetekre, amikor a biztonság komoly üzlet.
A titkos kérdések rendszere abban nyújt kényelmet, hogy ha nem vezettük be azonnal, később is hozzáadható, ha azt a védelmi szint megköveteli. Jó példa erre az Apple, amely csak nemrégiben valósította meg ezt a mechanizmust. [cikk 2012-ben készült]. Miután egyszer elkezdtem frissíteni az alkalmazást az iPaden, a következő kérdést láttam:
Ezután láttam egy képernyőt, ahol több pár titkos kérdést és választ lehetett kiválasztani, valamint egy vészhelyzeti e-mail címet:
A PayPal esetében a kérdések előre kiválasztottak, és néhányuk igazán nem is rossz:
Minden három pár kérdés és válasz különböző potenciális kérdések halmaza, így elegendő módszer létezik a fiók konfigurálására.
Egy másik szempont, amelyet figyelembe kell venni a titkos kérdés megválaszolásával kapcsolatban, a tárolás. Az egyszerű szöveges adatbázisban való tárolás szinte ugyanazokat a fenyegetéseket jelenti, mint a jelszó esetén, azaz egy adatbázis felfedése azonnal felfedi az értéket, és nemcsak az alkalmazást, hanem potenciálisan más alkalmazásokat is veszélyeztet, amelyek ugyanazokat a titkos kérdéseket használják (ez ismét ). Az egyik lehetőség a biztonságos hash-elés (tartós algoritmus és kriptográfiailag véletlenszerű só), de ellentétben a legtöbb jelszó tárolási esettel, itt lehet egy tiszteletteljes ok a válasz, mint sima szöveg történő megjelenítésére. A tipikus forgatókönyv élő operátor általi azonosítás telefonon. Természetesen ebben az esetben a hash-elés is alkalmazható (az operátor egyszerűen beírhatja a megnevezett ügyfél válaszát), de a legrosszabb esetben a titkos válasznak valamilyen kriptográfiai tárolón kell lennie, még ha ez egy egyszerű szimmetrikus titkosítás is. Összefoglalva: kezelje a titkokat titkokként!
És az utolsó aspektus a titkos kérdéseknek és válaszoknak — sokkal érzékenyebbek a szociális manipulációra. Közvetlenül próbálni kifaggatni egy másik személy fiókjának jelszavát — ez egy dolog, de beszélgetést kezdeni a végzettségéről (népszerű titkos kérdés) — teljesen más. Valójában elég kézzelfogható, hogy sok aspektusáról beszélgethet valakinek az életében, amelyek titkos kérdésként szolgálhatnak, és nem keltenek gyanút. Természetesen a titkos kérdés lényege abban rejlik, hogy kapcsolódik valakinek az élményeihez, ezért megjegyzik, és itt rejlik a probléma — az emberek szeretnek beszélni az életükről! Ezen a helyzeten nem sokat lehet tenni, kivéve, ha olyan titkos kérdéseket választunk, amelyekkel kisebb valószínűséggel lehetne kiszivárogtatni szociális manipulációval.
[Folytatás következik.]
Hirdetés
VDSina megbízható , minden szerver 500 megabites internetkapcsolattal van ellátva és ingyen védett DDoS-támadások ellen!
Forrás: habr.com
